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.
ITSM/ITAM/ESM Blog 
You must be logged in to post a comment.