As consultants, we get asked the same two questions when UAT rolls around:
1.How do I perform UAT
- Plan, plan, plan! Create a plan. Think of the who, where, how. Who will be your testing team, where will they test (in a room together, individually on their own time) and how will they test (testing scripts, ad-hoc)
- Design test cases.These cases should cover all the real life scenarios of the business. My suggestion is to gather all the scenarios and then perform them, writing out every step and detail in as a step by step checklist that the tester can check off the step as pass/fail.
- Select your testing team: You have your plan and your test cases but who is going to carry out your plan and run through your test cases? The team should consist of real world users- who is going to have to use this product.
- Remediation: Log every failure, and every bug. Share that with the consultant or engineer responsible for the build work. Have them actively put in patches and changes and keep testing until it completely passes. If you are unable to get a pass due to a system constraint, document it so that you can come up with an alternative.
- Acceptance: You tested, you worked out the bugs, now you have to fully accept the changes and accept your final product.
2. Do you have any test cases already written that we can use?
My answer to this is almost always “not really”. Why? Well, let’s think about the purpose of UAT: to have the end users test the software to make sure it can support their everyday tasks and duties. No one knows your business better than your users, and they are going to be the best ones to create those test cases. Of course we as consultants create a mental checklist of things we need to check for when testing our work, but we are just testing the technical functionality. Your users will need to tell you the real life scenarios that this software will be expected to support, and then you create those test cases from there. A Lot of the things to test for can also come from your requirements. Those may help you think of some cases. For example, if one of the requirements was a track my time button, think back on why it was created. Was it created so that an analyst can log how long an activity takes? What activity was it? now write out how they would use that button and BAM you got yourself a test case.
When it comes to UAT always come up with a plan, test cases, and then a team to carry it out. And remember, no one will be a better test case writer than yourselves.
-Krystina Hodge, Consultant | Project Manager
Contact the consulting team at consultants@dataseti.com
Find us on dataseti.com or read us on dataseti.blog.
Follow us on LinkedIn, Facebook and Twitter!