Categories: Risk Management
This article continues from my notes on acceptance testing in my region. The acceptance report or UAT Report as is typically known, is outlined here —
A UAT Report may be progressive such that it presents the summary of acceptance tests that are in progress at any time a report is needed, or a summary of concluded acceptance tests. It records the aggregation and or finality of test results, observations, discrepancies/deviations from the RTM, and resolutions if any that were made during the course of testing. 💯
The report may include out of scope testing such as tests or retests brought forward from a previous UAT regime. Or mention of (significant) outcomes from testing beyond formal test cases.
The final report is usually signed-off by the parties involved. The document may serve as a binding document that the planned tests are conducted, and present plans i.e agreement for completing whatever else that may be outstanding after the tests.
A UAT Report may comprise contents e.g.
|
(Suggested) Contents of UAT Report |
|
A UAT Report in essence-
- Presents a consolidated view of what has transpired. A historical record on the build (where possible); especially when things were made on the fly and lacking as-built documentation.
- Is applicable to everyone- and produced by anyone- with vested interest in the testing or project. Anyone authorized can contribute to the construction of the report.
- Emphasizes the terms to close a project phase (stage or work component) and move on to the next. The terms may include newly negotiated terms to deal with doubly unknowns uncovered during testing.
- Plan it as the end goal in testing. Exploit it as preparation, but to publicize structures and processes leading to the conclusion of testing.
How do we create an acceptable UAT Report?
- Gather evidence of work outcomes as project progresses e.g. to ease documentation.
- Build upon a template that everyone is agreeable with. An approach visible to everyone is to evolve the report, editable by authorized users on a shared repository.
- Involve stakeholders that matters in crafting and reviewing the report, both formally and informally. As the saying goes, engage stakeholders early on in testing ('the project'), and bring onboard influencers in completing the testing.
References & past notes on the same topic:
- User Acceptance Tests
- User Acceptance Tests (documentation issues)
- Notes on Documenting Acceptance Tests
- Doomed from the start: the importance of developing a sound test plan (2001)
.
