An edit of this article originally appeared on Konsultbolag1
Acceptance testing is the final phase in any systems development project and its purpose is to check that the requirements are met. Acceptance testing comes after the provider has developed the system and hopefully tested it thoroughly. At this point, it’s up to the client to verify that the system lives up to the agreed-upon specifications.
This article will give you 5 specific actions you can regard as a checklist for success in acceptance testing.
1. Prepare for changing requirements
Formulate a strategy and establish a process for dealing with changing requirements. The process needs to help you capture, organize, prioritize, and manage many versions of new and changing requirements. How do you intend to handle the requirements changes that will appear during testing?
Most importantly, see the changes as lessons learned rather than failures; requirements are what the acceptance test is intended to approve.
2. Start early
Unless you’re aiming for failure, testing cannot wait until the end of the project – it needs to begin as early as the procurement process.
It’s much cheaper to change things on the drawing board than trying to include requirements discovered when the system is ready for deployment. You’ll need at least one experienced person on the team whose focus is on reviewing and testing, depending on project size. You probably have system test managers and system testers. Acceptance test managers and acceptance testers are just as important.
3. Put usability into acceptance testing
Acceptance testers are helpful to have in system testing, since they’re good at spotting usability gaps and user interface improvements. However they can start usability testing much earlier, almost as soon as there is a user interface to look at.
The interface can be as basic as a workflow, a single system module or a form, simple sketch or an advanced prototype. It’s nearly impossible to fix logical errors in workflow when they’ve been implemented throughout the system, so bring in your acceptance testers early to catch these errors before they spread.
4. Establish law and order with a shared test management tool
Testing isn’t about randomly kicking tires – it’s about working against a discrete list of identified risks and priorities, and tackling them in a logical order, one by one. Testers document identified defects and deviations and report them to the person tasked with correcting them. After these defects are corrected, the testers need to monitor and test the problem spots again, individually and in context.
If the project involves several people, they need a shared data structure, and should coordinate their work with a test management tool right from the start. Ideally, the tool should be able to handle the entire chain from requirements through test cases to bug reporting, and provide summary statistics and metrics. Both client and developer should use the same tool.
5. Create new test cases
Developing test cases as soon as requirements are developed is great for emphasizing the importance of testing, but those initial cases are seldom sufficient; they need to be supplemented throughout the project.
It’s tempting to reuse test cases from previous testing levels in acceptance testing, but each level of testing has a unique purpose and acceptance testing focuses on usage of the system. A testing tool makes it easier to both maintain and use test cases.