• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

A Business Analyst’s Checklist for User Acceptance Testing

UAT Checklist

UAT Checklist

A while ago, Joy wrote a post about how to prep for a UAT (User Acceptance Testing). I would like to add to that, with my own experience, for what is needed in order to prep for a UAT.

 

I had a client once who was building an internal software product, failed their UAT, went back to fix the issues (some of which were UI related), and needed to repeat UAT in order to proceed with beta testing and ultimately a release. In order to prepare for UAT and ensure its success, the team created a checklist which was updated throughout the process through the knowledge of what worked and what didn’t work.

 

The columns:

Is the task required? What’s the task status? (eg. Not Started, In Progress, Completed) What’s the target completion date? What’s the activity?

 

The tasks:

1. Identify UAT business stakeholder
2. Business stakeholder IDs UAT testers
3. BA creates training materials to help the business users when testing the system. These will be updating during testing
4. QA writes test scripts
5. BA reviews test scripts with QA to ensure they are correct and written appropriately
6. BA completes master data to test
7. BA assigns test scripts to business testers
8. BA reviews test scripts with business testers to ensure users are capable of executing test scripts
9. BA works with IT to ensure the system on which UAT will be conducted is clean and has no existing data or tests from QA
10. BA creates Roles & Responsibilites Matrix, including all business testers. This will show what the business tester will be capable of testing and his permissions within the system
11. BA creates testing schedule and allocates days/times when business testers will be needed to test
12. BA reviews the testing schedule with the buiness stakeholder and it is approved
13. BA creates manual for how to use the defect management system and explains what is a defect (this will reduce the “System doesn’t work” type of defect)
14. BA ensures business users have access to defect management system
15. BA works with each business tester to ensure the defect management system is on their computer and they can login
16. BA reserves UAT room and completes room logistics (network access, projector access, etc)
17. BA communicates with business testers where the UAT room is located
18. Buy snacks for the business testers
19. Plan End of UAT party
20. Plan Go/No-Go Meeting, which determines whether UAT passed and if the application will proceed to release, alpha testing, etc

 

The time frame of completion for each task is dependent on the size of the project and how long it will take to complete each task. For the project I was on, I had roughly about 50 testers and touched every department of a F500 company. The timeline considers the magnitude of the project. If your project will have 5 testers and is fairly simple, you’ll clearly have a very different timeline than what I had.

 

Try this checklist on your next UAT and post the results!

 

 

 

4 Responses to A Business Analyst’s Checklist for User Acceptance Testing

  1. Andrea March 31, 2017 at 9:52 am #

    The IT team should never write the test cases for Business UAT. QA writes their functional tests and executes according to requirement. The Business or UAT should run the application as it functions in Production. If you don’t follow this standard practice, you will never get real world scenarios tested until Production and your users are logging issues. It doesn’t make sense either to have QA write “test scripts” for the users to execute. Do you also have QA run the Unit test cases???? I wonder how successful you’ve been using this practice. Do you catch defects in UAT with them executing tests from the IT perspective?

  2. Joy Beatty August 16, 2017 at 12:16 pm #

    Actually in general I agree that developers and testers shouldn’t be writing UAT scripts. That said, often business analysts, product owners, and product managers can write them to represent the business/user point of view – just like these same roles can represent them in writing requirements. Sometimes these roles live within IT, so that’s why I wouldn’t rule out someone in “IT” writing them. We have found this is actually far more successful than the business writing themselves because they aren’t as methodical typically. That said, they are going to perform UAT under the guidance of one of these other roles.

  3. Phil Coen-Pesch September 11, 2018 at 10:03 am #

    Whenever possible there should be a dedicated UAT Lead who understands testing and the real world business scenarios–they should write the scripts and run the UAT. In this way, the business builds a level of understanding about the software its using and positions itself to better understand what it wants and needs next. Frankly, BA’s have enough to do without also managing the the UAT process. It’s best if they’re contributors or resources, but not the leads. I know that flies in the face of convention and many BA’s would disagree, but I think there’s greater value in shifting the UAT experience into the business and supporting the development of that knowledge base and expertise in their space.

Trackbacks/Pingbacks

  1. User Acceptance Testing (UAT) | Types And Examples - July 20, 2019

    […] details like entry and exit criteria for UAT, approach for the test scenario and test cases, UAT workflow checklist, […]

Leave a Reply

Your email address will not be published. Required fields are marked *