Is 2 tests per UAT script enough?

Recently a customer asked me if 2 tests per User Acceptance Test (UAT) Script are enough.

This is a good question, UAT testing is key to successful Ivanti HEAT implementations and rollouts of major features/functionality.

How many UAT Tests should be performed per Test Case?

As many as it takes for you and your team to feel comfortable that you can perform your day-to-day job function.

Recommendation and Best Practice is a minimum of 5 tests per UAT Test Script.  Anything less is a risk that the client need to evaluate. Some detailed, complex, and high impact UAT Test Scripts may require at least a dozen of tests for the various scenarios that you have identified. It is better to test more than less, that’s for sure. Perform as many tests as it takes for you and your team to feel comfortable that you can perform your day-to-day job function.

Experience dictates that if UAT (validation of business requirements) isn’t thorough then the likelihood of post-implementation issues, gaps, and problems is much much higher, and can take more time and effort to address than during UAT.   

Intangibles like morale and perception of the new Ivanti HEAT Service Manager system/features can also be negatively impacted.

Also note that you are not bug hunting, so you don’t need to test every single feature and menu item, however you are testing that you can perform your daily job function, so test all the features related to the use case (business process) that apply.

It’s not unlike ordering a fleet of vehicles simply by kicking tires and doing a lap around the parking lot versus more extensive test-drives tailored to the company wide business needs. Sure, everything “might” appear fine, and “might” go fine upon delivery. But those are huge risks to take for a high dollar, high impact, high exposure item that ultimately could lead to work slow down or stoppage.

No matter how detailed your UAT Test Scripts, you need to have a good range of test case scenarios (sample input data) for every test script. Sample input data should be real data, from your existing system, whether it’s a database, excel sheet, or paper forms. For example tickets from your old HEAT Classic system, Paper Forms from a manual system, if you’re going digital, sample rows from an Excel sheet if that’s what you’re replacing. Bottom line, use real data that represents the typical type of data to expect and the UAT Team members can relate to. Tip: Ask yourself if the data could be used for training purposes. If it can, then include it as an artifact for training documentation. If it can’t, then ask yourself if the sample data is a good representation of a typical day in the life of the end user.

The time and effort required is usually negligible. Minutes per test.

A great amount of time and effort has gone into the Ivanti HEAT project, and UAT is a critical milestone in the Software Development Life Cycle (SDLC). So make it count and be thorough on your validation of business requirements, UAT that is.

ivanti-best-practices-SDLC-software-development-life-cycle-a19-consulting-ivanti-professional-services-best-practice-systems

What is UAT Testing?

  • The purpose of User Acceptance Testing (UAT) is to test use cases, that is specific day-to-day operations in the life of an end-user and their required tasks to perform their job function
  • UAT Testing differs from System Testing in that System Testing is focused on software functionality.   UAT Testing is focused on job function, that is day to day operations can be performed.  Therefor access to Ivanti Service Manager (powered by HEAT) is not needed to build UAT Test cases, in fact it is discouraged to use HEAT as your focus should be on building use cases about day to day operations, operating procedures, such as Logging an Incident, searching for customers, assigning 2nd level support, and so on.
ivanti-best-practices-regression-testing-a19-consulting-ivanti-professional-services-best-practice-systems
  • Regression testing refers to testing of existing functionality to ensure that recent changes do not adversely affect existing features.  For example, when implementing Asset Management, the existing Incident functionality is tested to test use cases such as creating an incident, creating a task, updating incidents, closing tasks, incidents, etc. In addition to UAT Test Scripts, you will want to do a comparison of existing workspaces, existing functionality, and existing features, to ensure existing functionality has not been impacted.

If you’re looking for sample UAT Test Scripts, be sure to contact us!