The truth is, User Acceptance Testing is a kind of system and company objective validation, performed by the end-users, and also company objective sign off from the job owner.
The objective of User Acceptance Testing would be to test use cases, in other words, particular day-to-day operations in the life span of an end-user and their required activities to perform their job function according to Standard operating procedures (SOPs).
UAT Test Cases typically closely align to your Standard Operating Procedures (SOPs) and have subject matter experts (SMEs), functioning procedure steps, input, and anticipated outcomes.
Think of UAT Test Cases as cooking recipes. Imagine you're a cook preparing a meal, and your objective is to prepare a grilled cheese sandwich. The use case describes a series of written measures on how the cook goes about preparing a sandwich.
The cook would be the major subject matter specialist. The system components are a skillet, a cooking apparatus, bread, butter, cheese, and a spatula. The use cases would be the system general operating procedures to make the grilled cheese sandwich, broken down into instances and measures. Bite-size balls in the event that you will. Like I) constructing the sandwich, ii) preparing the cooking device, iii) operating the frying pan, etc. The final step will be eating the sandwich. That is certainly my favourite, with tomato soup.
For instance, with Ivanti Service Manager, an enterprise software system employed by Service Desks, the SME would be the Service Desk Analyst, the operating procedure taking service desk support calls, and use cases I) to appear & record caller information, ii) enter signs, iii) lookup applicable knowledge articles, iv) assign to 2nd or 3rd level support, v) resolve the call, and so on.
As you can see, UAT Test Cases should be easy, higher level, and system access is not required to work with cases. In fact, the best practice would be to discourage system accessibility when writing UAT Test Cases. After all, a fantastic cook does not require a frying pan and a couple of pieces of toast to compose a recipe. A good cook can write recipes (ingredients and steps) with his/her eyes shut.
You need to consult Subject Matter Experts (SMEs) and the end-users, to ensure you have covered all of the possible scenarios. In this case, this could be the chef, kitchen manager, kitchen staff. In the Actual world, for example, with the Ivanti ITSM Service Desk applications, this could be the Service Desk Manager, Service Desk Analyst Lead, Storage Techs for Asset Scanning and Storage Management, Procurement Lead for Purchase Order related instances, and so on.
Last but not least, your focus must be on Test Case Scenarios, not attributes, functionality, or software. That is System testing. We're not testing the recipe or stove's each button and dial. And we certainly are not trying to split the frying pan or cooker. As much fun as that is, that's stress testing. I know bug hunts are fun too, but sorry, that is not UAT.
We're constructing high-level use cases and scenarios of daily operations which can be used as Test Scripts by UAT Testers who will be grading the outcomes as either Pass, Pass with Comment, or Fail.
The Most Typical User Acceptance Testing Mistakes...and How to Overcome Them
Most System Implementations fall short when it comes to appropriate UAT Testing, be it due to a lack of funds, time, or budget, however more often than not because of a shortcoming of appropriate UAT Action Plan, UAT Test Cases & Scripts, too little Best Practices, Strategy, Coordination, and Planning.
Comments