Before the UAT
Most UATs that go wrong, go wrong here: unclear scope, scripts nobody checked, testers without a working account.
Scope
- Agree which processes and user stories are in the UAT, and write down what is not.
- Name an owner from the business for each process: the person who signs off.
- Agree what Critical, High, Medium and Low mean before the first issue is logged.
Test cases
- Write one test case per business scenario, in the words of the people who test it.
- Give every step an action and an expected result, and test data where it matters.
- Mark each test case Must, Should or Could, so the important ones are tested first.
- Add the unhappy paths: a wrong value, a missing field, a user without the right role.
- Check that every user story in scope has at least one test case.
- Let a key user from the business review the scripts before the test days.
Testers
- Choose testers who do the work every day, from every team that uses the system.
- Give each tester a group and their own scripts.
- Block the test days in their calendars and free them from their daily work.
- Brief them in half an hour: how to record a result and how to log an issue.
Environment and test data
- Prepare a test environment that looks like production: configuration, integrations and data.
- Create a test account for every role, and check that each one can sign in.
- Load the test data: customers, products, price lists and open records.
- Use test data instead of customer data wherever you can.
- Agree when fixes are deployed to the test environment during the test days.
Schedule
- Plan the test days in blocks, with a fixed time for the triage every day.
- Keep time for a retest round after the fixes.
- Set the date of the go/no-go meeting, and invite the steering committee now.
- Check the release calendar of Salesforce or Dynamics 365: a platform release in the middle of your UAT changes what you test.
Entry criteria
- The system test is done, and no Critical defect from it is still open.
- The test environment, the test accounts and the test data are ready.
- The business has reviewed the test cases.
- Every tester has been invited and has signed in once.
During the UAT
Keep the days short and the information in one place, so problems are found, decided and fixed on the same day.
Daily stand-up
- Start each day with fifteen minutes: what was tested, what blocks, what is planned today.
- Compare progress per group with the plan, and move testers where they are needed.
Logging issues
- Log one issue per problem, with the step, what you expected and what happened instead.
- Add a screenshot and the link to the record.
- Look for an existing issue first, so the same problem is not logged twice.
- Make sure every failed step has an issue, or a reason why not.
Triage
- Hold the triage every day, with the business and the development team together.
- Give each new issue a severity, a priority and someone who fixes it.
- Decide for each one: fix it, reject it, or turn it into a change request.
- Put change requests on the backlog, not into this release.
Retests
- Let the tester who found the issue retest it once the fix is deployed.
- Write down which release and build each retest was done on.
- Start a new round after a large fix, and test the processes around the fix again.
Closing the UAT
The UAT ends with a decision. Make it on facts, and write down who decided what.
Exit criteria
- Every Must test case has passed.
- No Critical issue is open.
- Every open High issue has a workaround or a date for the fix that the business accepts.
- Every test case in scope has a result.
Sign-off
- Ask the owner of each process to sign off: accepted, accepted with conditions, or rejected.
- Write down every condition, with who does it and by when.
Go/no-go
- Hold the go/no-go meeting with the figures on the screen, not from memory.
- Record the decision, the conditions and who took it.
The report
- Say what was in scope, and what was not tested.
- Show the results per group and per priority, and the release and build that were tested.
- List the open issues by severity, with the decision on each one.
- Add the sign-offs, with their conditions.
- Name the known risks and workarounds for the first weeks after go-live.
After the go-live
- Keep the test cases: they are the regression test for the next CRM release.
- Write down what to do differently in the next UAT, while it is fresh.
The same checklist, without the spreadsheet
UAT Studio does most of this list for you. The readiness check shows what is missing before the test day, testers sign in with a code and see only their own scripts, a failed step becomes an issue with a screenshot, the triage runs on a shared screen, and the go/no-go report is ready when the last result is in. Try it on your own project with a free 14-day pilot.
Testing a Salesforce or Dynamics 365 release? See Salesforce UAT and Dynamics 365 UAT.
