User Acceptance Tests (documentation)
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.
A UAT Report in essence-
How do we create an acceptable UAT Report?
References & past notes on the same topic:
Notes on Documenting Acceptance Tests
This blog extends my previous notes on what may constitute a document for acceptance tests. The points are brief, and may not reflect what is practiced in your region or project.
Typical information required:
The acceptance test document may include appendices to conclude the test:
There was an incident where the external auditor of the customer, questioned the unfilled frames and scribbles outside of fill-in frames on hardcopy test forms. This occurred despite the testers having been briefed on protocols. The problem here is that incomplete filling and off-witted remarks on a formal test document can cast doubt or uncertainty on the test outcome.
As such I would emphasize the inclusion of a chapter or section on procedures for completing test cases, i.e. specifically on executing specified tests and filling-up test case forms. Regardless of whether the forms are hardcopies or digital (such as using a purpose driven app on a tablet). I would place this as the first section of the test procedures. It should define information e.g. as follows –
See also my notes for training on –
Notes on Handling Over & Taking Over
The Handover and Takeover process (HOTO as is known affectionately in my circles) i.e. handling-over and taking-over of works affects all of us. These are notes on HOTO for my team newbies :-P
HOTO happens when:
IMO the most problematic aspect of HOTO is taking over a project; for that matter even taking over an ongoing project activity. The reason being the outgoing incumbent is in the know, whereas the incoming manager is in the unknown. And is unlikely that everything will be made known. The brief below, focuses on the taking over process.
The following steps generalize what should occur when taking over a project, particularly:
Similarly, when handling over a project, work with whoever is coming onboard to agree on the status of project, complete all outstanding tasks, and update all project documents. That way you’ll mitigate whatever work you have done in the past from coming back to haunt you.
As with all guidelines, you will have to adapt recommendations of best practices, past experiences, and lessons learned to craft your own processes and procedures. The table below exemplifies common tasks which should be completed throughout the HOTO period:
Exemplify typical tasks before, during, after HOTO
When a project transitions to operations, the project team may have to supply operations or supporting documents (click here) to facilitate smooth operations.
My Activity Is Delayed
There are two scenarios which can get us caught unawares when a project task or activity is delayed. It is either ① we failed to manage and monitor the activity, or ② there isn’t one or an adequate risk response plan for that activity. Taking over an activity that is delayed is to firefight - the implications are on the project team, the organization.
If we failed to track progress of the activity, then it could be construed as negligence; perhaps due to incompetence or ignorance e.g. that there is no succession planning (known unknown) or no certified professionals doing the job (unknown known). If we don’t have a risk response plan preferably in writing or in our heads or have some clues, then we would have totally failed to implement risk management.
Granted that events can happen unexpectedly – we should nevertheless have been on top of things. To begin with - there should be some form of risk management plan as the project kicks off.
Here’s my summary - when a risk event occurs, broadly:
Here are some principles to follow:
PMBOK® Guide – Sixth Edition (2017)
User Acceptance Tests (documentation issues)
This article continues from my notes on acceptance testing in my region. A broad view on documenting acceptance tests.
There are different ways to manage documents when testing for compliance to contracted terms (specifically with reference to the RTM). Given that at the end of the project, there could many test documents whether digital files and-or in hardcopies, generated for review, reference and filing. One common approach is to log everything as a single file, and the other is to use multiple files.
Generally, there are two parts that need validation from stakeholders, particularly the customer – on the test procedures, and thereafter on the results from executing the test procedures. Hence a test document, would comprise minimally the test procedures and the means for recording the results. Taking it further, there may be a section to ratify the test results, and other sections for whatever else that may be included.
Logging everything into a single file may apply for the entire project (complex or otherwise)! Or may apply for a cluster of project components – let’s say. As hardcopies it would produce a single document with a single index that could span across multiple physical folders. And there would be hand writings and signatures on the hardcopies.
Logging multiple files is straightforward, i.e. one test document for each component or part. These may go into a single physical folder or span across multiple physical folders. Or each test in its own folder. The difference here is that information such as on test procedures is generally replicated, and each file will have its own file index.
Logging acceptance tests as digital files is similar as to logging hardcopies. For certain, there are better perks in logging digitally. Details on logging digitally in another blog.
Sounds straightforward ya. But what if for whatever the reasons may be, someone decided that the test procedures and test results should be filed separately. And (worse) there should be a file for each component or part. What could happen?
Here's a list of possible outcomes, from my recent and past experiences:
My take on documentation; including test documents —