5 Tips to Avoid Critical User Acceptance Testing (UAT) Pitfalls
Latest posts by Rick Gilley (see all)
- 3 Reasons You Shouldn’t Be Afraid to Use Your Sandbox Instance - April 2, 2019
- 5 Tips to Avoid Critical User Acceptance Testing (UAT) Pitfalls - February 12, 2019
Your company has just purchased some major software that’s going to make your life a whole lot easier.
You start out excited! Who wouldn’t be? You can feel the weight lifting off your shoulders already.
But then you hear that the software won’t be implemented immediately. You and the vendor have to go through several phases of testing to set this software up.
Your team and the vendor’s team work hard, and you’re all finally at the last phase: User Acceptance Testing.
You’re probably wondering why you still need to test your software this late in implementation.
You might also be wondering how exactly this final phase will work.
In this blog post, I’ll discuss what User Acceptance Testing involves and why it’s important. I will also give you 5 tips to help your UAT phase go smoothly.
What is User Acceptance Testing?
Usersnap defines User Acceptance Testing as “the process of verifying that a created solution/software works for ‘the user.’
Generally, User Acceptance Testing (UAT) is the final phase of the software testing process.
UAT occurs immediately after you receive the final version of your software. The final version normally includes all the changes that were requested with any earlier bugs or issues fixed.
Why is User Acceptance Testing important?
User Acceptance Testing is important to ensure your software will work correctly.
User Acceptance Testing (UAT) is vitally important to the successful implementation of any application. This is because of the ‘mystery factor.’ No matter how many functional tests are performed, there will always be the difficulty of integrating a new piece of software into the operational pattern of any organization. Operational stresses that cannot be accounted for in earlier testing can only be found during the user acceptance phase.
You may run into difficulties because a change made in one area of the software inadvertently affected another area. This sometimes happens when we are implementing eQuip!
For example, if a field is made globally mandatory in eQuip! it not only applies to the field in Utilize Forms Designer but in all workflows as well. This can lead to issues if you want the field to be mandatory in one workflow but not all.
The UAT phase gives the implementation team time to fix these issues so your software can work exactly as you need it to.
User Acceptance Testing also gives you an opportunity to learn the software. The version you use during this testing phase will be very similar to what you’ll be using once implementation is complete. This means anything you learn how to do now, you’ll be able to do later on.
UAT ensures your software works properly and gives testers the chance to learn how to use the final version.
1) Maintain two separate environments
This is a basic UAT best practice. It will likely be handled by the Development Team, but it’s important for everyone involved to understand.
You should maintain:
- The Demo environment
- This is where changes will be made initially.
- All changes will be reviewed and approved here before being applied to the UAT environment.
- The UAT environment
- This is where you will get to test the software to identify any issues that were not discovered in the Demo environment.
- Issues will be identified and fixed before the software goes live.
2) Take your time
You may be eager to finish testing sooner rather than later, so you can finally use the software “for real.”
But we urge you to be patient during this phase. Trying to fit testing into only a few days may result in missed details that cause problems for you later on.
We recommend you set aside at least one week to complete the testing.
You should also make sure that you have the right resources available for the testing:
- The Development Team (such as our Onboarding Team)
- The Development Team will help in case any issues are identified.
- Your IT department
- Your IT Department has permissions that allow them to access places the Development Team may not be able to.
3) Document possible issues
Any issues that you encounter should be documented for review.
I recommend you create a spreadsheet that includes:
- The date the issue was encountered
- This gives a frame of reference so you can get an idea of how long it might take to resolve such issues.
- Where the issue was encountered
- Did the issue occur in a search, in a workflow, etc?
- A description of the issue
- Use as much detail as possible (screenshots are especially helpful).
- Expected resolution date
- A realistic estimate for the time it will take development to resolve the issue.
Communicate with the Development Team about these issues so they can be fixed as soon as possible.
4) Track data
The asset data that you will create for UAT testing is as important as the changes that were made.
For example, when implementing eQuip! we encourage test users to:
Include all asset field requirements, such as:
- Fields required to have a value
- Fields with a default value
- Fields that are read-only
This enables our Development Team to set up asset fields quickly and easily. If you do not include these details you run the risk of introducing incomplete and inaccurate data into your database when data is imported.
Include any new data fields and populate the data for those fields
It’s important that you be explicit when detailing anything you want to add to the software.
For example, when implementing eQuip! we may run into problems if the client wants to add a new asset field but did not tell us what kind of data should go in those fields.
Failure to include new fields when importing your test data will result in that data not populating for the assets in the application.
That’s why it’s important to include any new data fields and the data for those fields in your communication with the Development Team. If you’re not sure how to do this, they’ll be happy to give you examples.
5) Do your homework
It is crucial that you follow the business requirements documents closely. You should also test all aspects of every change request that was included in them.
Doing your homework by reading these business requirements before starting the UAT process can prevent countless headaches and save valuable time.
It is important to take a holistic approach when planning/executing this testing. Every part of the UAT process will lead to successful implementation. This ultimately means your software will work exactly as you need it to and your time investment will be worthwhile.
If your test cases are complete and are followed to the letter during testing, you can be confident that you have done your best to prevent issues before the final version goes live.