Skip to end of banner
Go to start of banner

User Acceptance Testing

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

FAQs

  1. What is User Acceptance Testing (UAT)? "User acceptance testing (UAT) consists of a process of verifying that a solution works for the user. It is not system testing (ensuring software does not crash and meets documented requirements), but rather ensures that the solution will work for the user (i.e., tests that the user accepts the solution); software vendors often refer to this as "Beta testing". This testing should be undertaken by a subject-matter expert (SME), preferably the owner or client of the solution under test, and provide a summary of the findings for confirmation to proceed after trial or review. In software development, UAT as one of the final stages of a project often occurs before a client or customer accepts the new system. Users of the system perform tests in line with what would occur in real-life scenarios." (https://en.wikipedia.org/wiki/Acceptance_testing#User_acceptance_testing)
  2. Why is it important to conduct User Acceptance Testing? It is important to conduct a UAT to ensure that features developed meet users' expectations. It is extremely important to conduct such testing often as requirements and needs do change. 
  3. Who should participate in a UAT?  SMEs. Folks whose jobs/roles will require using this feature. Recruiting for participants should occur 1.) at SIG meetings, 2. via SIG listserv, or 3. SIG slack channel. 
  4. How many participants should I aim for the UAT? Goal should be 7-10 so that you can review feedback and take action on the feedback quickly. 
  5. Who should conduct UAT? Product Owners
  6. How often should a Product Owner conduct UATs? At least once a quarter and/or a key milestone in development. POs should give themselves time to capture feedback to update requirements slated for the next quarter and to include critical items in that upcoming quarter. 
  7. Where can I find UAT examples? https://drive.google.com/drive/folders/1gQV2MxiPUiH-6pYeZe3vckVQ-LLL3uWb (please review the UATs that use Google Form) 
  8. What format would you recommend? Google Forms have been well-received by users and POs. If not comfortable using Google Forms, then use Google Spreadsheet. Examples of both are available via #7 link.
  9. Where should I store UATs? Store UATs in your SIG Google Docs folder. Create a subfolder called UAT. 
  10. Any more tips? Why yes, check out the below checklist. OR add a FAQ if you have a tip.

UAT Checklist (feel free to add/revise) 

  • Define a goal of the UAT.

  • Define a target audience. (e.g. SMEs/Folks who will use the feature to be tested.) Announce 

  • Determine testing approach (Exploratory? Structured w/ tasks?)

  • Keep the UAT short and simple. 45 minutes should be the maximum time spent testing.    

  • Test with stable build. Make dev team and folks managing builds aware of UAT time frame. Agree on a timeframe to not deploy additional updates to the testing build OR to maintain test data. 

  • Test your test! And communicate known issues with the build to UAT participants. .

  • Track browser/OS/device used (if applicable). Helps to identify browser/OS/device specific issues.

  • Capture feedback. Provide a document or form for participants to enter UAT feedback.
  • Set a deadline for feedback. Ideally 2 weeks is a plenty of time to gather feedback.
  • Communicate value. Inform participants how feedback will be used.  
  • Add to the backlog. Include applicable feedback in future iterations/sprints.
  • Present findings to the SIG(s).



  • No labels