Okay, by a show of hands, how many of you have worked IT projects that are cruising along on schedule and on budget, only to get blown up during Acceptance Testing? Hmm, quite a few, as I suspected.
Most IT projects go through several phases of testing, with the focus gradually shifting from technical to business, and the scope getting increasing broader. The most common types of testing are Unit Testing, System Testing and Acceptance Testing, which generally align with Low Level Design, System Requirements and Business Requirements. These phases are often represented in a V Model to depict the relationships and flows between the project phases:
Unit and System Testing are usually performed by members of the project team, and are often automated via scripting. But during Acceptance Testing, the intended audience (business users) are expected to validate that the new solution provides the intended functionality as defined in the business requirements, often within the context of a new business process. Users validating and accepting change? Easier said than done.
There are several situations that can arise during Acceptance Testing that will delay and potentially derail an otherwise well managed IT project. Most of these situations can be avoided by following these common sense guidelines to properly set expectations for the project team as well as the users performing UAT.
- Assign 1-2 business analysts from the project team to perform acceptance testing to help the team with requirements questions.
- Assign non-project users from the business to perform acceptance testing. Ensure each project stakeholder is represented on the Acceptance Testing team.
- Provide the Acceptance Testing team with project documentation such as key requirements that need to be validated, project scope and objectives, and updated user guides.
- Do not allow testing defects from Unit Testing or System Testing to carry forward into Acceptance Testing, assuming they can be dealt with before production release.
- Remind the Acceptance Testing team to focus on validating business requirements. Other feedback regarding look & feel and the overall user experience can be captured and documented for future consideration.
Acceptance Testing is not the time to question approved requirements, challenge design decisions or argue usability, despite how tempting it is to change that check box to a button and adjust the color scheme of the user interface. Keep the focus on validating requirements, get the solution into production and save the extra feedback for the next iteration.