If you’re not a tester and you’ve been asked to plan and run a User Acceptance Testing (UAT) phase, you need to know what to do. Perhaps you’re a project manager who knows you need to have some UAT, or perhaps you’re a product owner who’s been asked to do some. This post is for you!
Work out what it is you’re trying to prove
- Decide whether it’s about User testing, or Acceptance testing, or whether we’re just talking about project acceptance which may or may not involve additional testing.
- Work out what it is you need to see in order to be confident the system supports your business processes.
Get involved early, before the code is written
- UAT should be as much about preventing bugs from being written / misunderstandings from happening as it is about finding bugs.
- Any UAT must be consistent with the requirements. Therefore whoever is going to be doing UAT must have been involved in the requirements gathering. I like to think of this as Requirements Acceptance Testing (RAT!)
- Attend showcases and spend time looking at early versions of the software, accepting that it will be incomplete and buggy because it’s still being functionally tested.
- By having early conversations and agreements about UAT, you can probably avoid having to generate test documentation that no-one will ever read.
Work with the functional testers. They are your friends
- Understand the testers’ skills, limitations and motivations.
- Have them explain what their tests are doing and understand the test coverage they are providing.
- Explain what you’re looking for in your acceptance tests, and see whether they are already doing similar tests. (If testers know what UAT you are planning, they will want to do these tests themselves first so that when they hand it over they know it will work.)
- Get the testers to spend some time with the users so they get a better idea of how the software will be used.
- There’s no value whatsoever in UAT repeating tests that have already been run by functional testers. Now read this bullet again.
- Do your acceptance testing in the company of a tester. He will be very interested in watching you and making sure his functional test scripts are updated to include tests that you are doing that he hasn’t covered.
- Make sure that functional tests are updated to cover any UAT bugs you find.
- Testers have expertise in raising defects, getting them across to developers and managing the defect life cycle. Let them do it.
Happy / unhappy paths
There are more than two paths and they all need to be considered.
- Perfect path – The ideal, no errors route through the journey. This never happens in real life.
- Typical path – The user will make some errors and hunt around for a bit for stuff before completing the task
- Unhappy path – The user gets confused, lost, abandons and re-starts journeys, makes the same mistake repeatedly, etc.
- Evil path – User is maliciously trying to break / hack the system. This person is probably does testing for a living. If he doesn’t he should.
Use the users
In my experience most of the embarrassing bugs that elude testers and UATers are discovered in Production within 24 hours of the system going live. Many are found in the first few hours. Get the people who typically find these bugs to do whatever it is they plan to do in the first 24 hours after go live in prod, to do in the test environment before it goes live. This is really the crux of UAT.
Don’t bother writing UAT scripts
- Writing good test scripts is a specialist skill. Even most professional testers are not very good at it. UATers are even worse.
- If your requirements and acceptance criteria are good, they should also serve as your tests.
- If you think of things you want to UAT that don’t feature in your requirements, then your requirements aren’t good enough. Expecting features to be present that don’t appear in your requirements is to believe in magic.