Successful Acceptance Testing in 8 Short Steps
Article by our guest publisher: Ulf Eriksson
(CEO of ReqTest & many more test-oriented consultancy and training companies based in Sweden)
Acceptance testing is the final phase of software testing 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, as well as any implicit or expected requirements.
This article provides you 8 specific actions or steps you can regard as a checklist for success in acceptance testing.
Step-1: 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.The process needs to cover how you intend to handle the requirements changes that are bound to appear during software testing. Affirm the changes, and see them as lessons learned rather than failures. After all, requirements are what the acceptance test is intended to approve.
Step-2: Staff to test
Unless you�re aiming for failure, software testing cannot wait until the end of the project � it needs to begin as early as the procurement process. The cost of finding and fixing problems when they�re on the drawing board is negligible, compared with shoehorning in requirements discovered when the system is ready for deployment.
Depending on the size of the project, you�ll need at least one experienced person on the team whose focus is on reviewing and testing, so as to ensure that quality never takes a back seat to other needs. You probably already have system test managers and system testers, but acceptance test managers and acceptance testers are just as important.
Step-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, embodied in a 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 them before they spread.
Step-4: Make time to test
All too often, employees are expected to test a system in parallel with their regular duties. Validating functionality and testing new work-flows take time, so it�s important that employees involved in acceptance testing understand the process and set aside sufficient blocks of their schedule.
You can set up a special software testing room to keep testers from being distracted by other tasks, as well as boost testers� focus and motivation by explaining why testing is important and training them in effective testing techniques, specifically within the framework of the project.
Long before software testing starts, the developer and client should agree on the preconditions for acceptance testing, so as to ensure that employees don�t waste time testing without the proper processes and tools in place.
Step-5: 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 they�ve been corrected, the testers need to monitor and retest the problem spots, 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.
Step-6: 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 software testing has a unique purpose and acceptance testing focuses on usage of the system.
You need to describe the expected results in the test cases; without knowing what the results are supposed to be, it’s difficult to determine if the output is accurate. Re-testing is easier if you can use the same data again, and a testing tool makes it easier to both maintain and use test cases.
Step-7: A separate test environment
If you expect software testing to provide accurate results, you need to set up a test environment that�s identical to � but separate from � the production environment. Pay a little now or a lot later; that is the case for a separate and independent test environment.
Investing in two sets of hardware and licenses can seem expensive, and make it tempting to install and test directly in a live environment, or even to skip acceptance testing altogether. However, such shortsightedness can cause users to lose confidence in the system and ultimately drive the cost much higher.
Step-8: “Typical” is not always realistic — Take time to create test data
Test managers often expect “typical” testers to be able to provide “typical” data that�s representative of the real world. In our experience, this approach works in simple contexts, but in complex situations — where complex transactions and dependencies need to be managed and measured — realistic test data doesn�t come from typical cases.
You�ll benefit enormously from a test data strategy that includes an anonymized test database that you use and update throughout testing. Extract selected parts as needed and use them as much as possible during acceptance testing.
You should even take the time to create procedures that restore the test data back to its initial state. In complex systems, obtaining relevant test data can be a project in and of itself, and you should plan more than adequate time to do the job right.
About the Author: Ulf Eriksson is a guest publisher of the article & is solely responsible for the ownership of its contents.
Ulf Eriksson runs a number of companies in Sweden, one of which is a test-oriented consultancy and training company, while the other is ReQtest, an on-the-cloud test management software with an extremely dynamic pricing plan. He is the author of 2 books about the practice of software testing and how to do it efficiently. Ulf is extremely interested in organizational development, testing, and requirements management. Ulf is based in Stockholm.