User Acceptance Tests (UAT) is the typically one the last steps when developing a particular feature. The application is used by people from the intended target audience in scenarios which will be typical to the real world usage (or as close as possible). The users will record and note any defects which are discovered. It gives end users the chance to interact with the application and find out if everything works as was intended. This process should help discover aspects of features which may have been overlooked, miscommunicated, or are defective etc.
In my current organisation, the responsibility of User Acceptance Testing (UAT) is the responsibility of the end users (along with guidance from development team).
Automated User Acceptance Tests (UAT) are something that very few end users and quality assurance (QA) teams actually do.
Why don’t more teams automate acceptance tests?
One main reason I have experienced that more teams don’t automate acceptance tests is because of:
- Lack of knowledge or skills to implement
- Not allocating enough resources
Why should we try to automated our User Acceptance Tests:
- Reproducible - Repeat what was done if audited years into future
- Traceable - Map tests to requirements
- Evidenced - Developer and user testing
Medicines and Healthcare products Regulatory Agency (MHRA)
Good Clinical Practice (GCP)
- Appropriate controls of the system are in place throughout the systems lifetime
- The system is fit for purpose and performs reliably and consistently as intended
- Computer Systems should be periodically evaluations to confirm that they remain in a valid state and are compliant. This should include:
- Current range of functionality
- Deviations records
- Upgrade history
References [14.5.1 Validation Principles. MHRA Grey Guide]
[EudraLex The Rules Governing Medicinal Products in the European Union Volume 4 Good Manufacturing Practice Medicinal Products for Human and Veterinary Use Annex 11: Computerised Systems – Equivalent to FDA 21CFR11]
How should test be conducted:
- Arrange (Setup)
- Act (Perform Actions)
- Assert (Check Expected Result)
- User Requirements Specification
- Functional Spec (Implementation + Risk)
- Test Scripts based on risk (Collaborative)
- Dev - local (laptops/work stations)
- Test - unstable code, seeding data
- Stage - pre-production
You can download the presentation slides here [PDF] AutomatedUserAcceptanceTests
If you would like to read more about the background to this work, it was conducted as part of system development of the Clinical Imaging Review System.
If you have any questions or comments you can contact me.