As a recurring feature, project management veteran Tom Mochal will respond to member questions and discuss issues Developer Republic members have raised. This is a great way to learn about the problems and questions others are having and to get valuable advice on the issues developers face every day.
I have a question about acceptance testing. I have the impression that during the system test, we will already cover the things that acceptance testing should verify. If we wait until the acceptance test to find errors, the project will be hard-pressed to go live on its scheduled deadline. I would like to get your clarification on this.
This is a good question, Vlad. The amount of emphasis to place on the user acceptance tests depends on the level of customer involvement in system testing. If your customer was very involved in usability testing, performance testing, and requirement testing, then it’s true that they should already have extensive experience on the system. You may need to place more emphasis on acceptance testing if your customers were not actively engaged in earlier testing.
However, it’s never a good idea to skip acceptance testing altogether. You should implement a formal user acceptance test in all cases for the following reasons:
- System testing is a time when you want to shake the application, and the chances are, you will find problems. If you are finding problems and correcting them, then the customer never gets a full chance to see the application run in an error-free environment. Acceptance testing provides that chance.
- The system tests provide a slice of what the application looks like, but they may not provide a holistic view. For instance, requirements testing focuses on features and functions, and usability testing focuses on the ease of use and human factors. System testing may not provide any opportunity to see the application work from beginning to end. Again, acceptance testing provides that chance.
- The system testing is all done from an IT perspective. It does not test from a customer perspective. The system tests are designed to take different aspects of the application and test them to make sure they perform as expected. The customers can contribute to these tests, but, again, they are not necessarily designed to show what the application will look like to the customers on a day-to-day basis.
- Ultimately, the IT organization is delivering an application that the customer will live with for the foreseeable future. If there are problems, it is the customer’s business processes that are affected. They are the ones who will be fielding complaints or dealing with the aftermath of errors. So it’s important that they accept ownership for the application and that they validate as best they can that the application will fulfill their business needs. If the customer doesn’t do acceptance testing, it’s too easy to come back and blame the IT team. So, after the IT team does their best testing during the system test, the customer must also validate that the application meets their business needs through a thorough user acceptance test.
If there are more errors, it’s better to find them now
You also mentioned that if there were major errors discovered during acceptance testing, it would be hard for the project to go live. You are absolutely right. First, if the customer were involved with a thorough set of system tests, you wouldn’t expect major problems to arise from the acceptance test. If you find major problems, this points out some type of flaw in your prior testing processes.
On the other hand, the purpose of the acceptance test is to ensure that the application is ready to go live. If the customer signs off on the acceptance test, then you move to implementation. If the client finds major problems, it’s a sign that you don’t want to go live. Even though it will take time to correct the errors, it’s still better to find them now rather than after the application is moved to production.
Project management veteran Tom Mochal is director of internal development at a software company in Atlanta. Most recently, he worked for the Coca-Cola Company, where he was responsible for deploying, training, and coaching the IS division on project management and life-cycle skills. He's also worked for Eastman Kodak and Cap Gemini America and has developed a project management methodology called TenStep.