Software Testing Phases

BAs need to understand the testing process

Even if not responsible for planning and executing tests, every BA should understand the common testing phases and practices. When a project’s solution is in the testing phase, the BA should be closely involved. As tests are executed and defects found, the BA is a great resource to help determine the cause of the defects and to help with ideas for correcting them. Some of the problems found will require business stakeholders to make decisions, and the BA can help with these. The BA should also be watching for errors that were caused by poor requirements. BAs can significantly improve their elicitation and analysis skills by learning from prior mistakes. Look upon these mistakes as lessons learned.

Software testing approaches are based on the V model. There are many variations of the V model, but the fundamental concept of this model is that software testing should begin as soon as a project is initiated. The V model recommends that the software testing team be independent from the development team. This independence fosters more thorough and unbiased evaluation of product quality (Kooman and Pol, 1999). During each phase of the software development life cycle, there is a corresponding phase of software testing. These phases are called unit testing, integration testing, systems testing, and user acceptance testing. See Figure 5.5 for one version of the V model.

Figure 5.5: Sample V Model for Software Testing

Unit Testing

Unit testing is usually the first level of testing and is performed by the developer. A unit is a small piece of the software that can be tested individually. The objective of unit testing is to find problems in the smallest component of a system before testing the system in its entirety. BAs may assist developers by identifying test cases and reviewing unit test results.

Integration Testing

The next level or phase of testing is referred to as integration testing. Integration testing requires the individually tested units to be integrated and tested as a larger unit or subsystem. The objective of integration testing is to find problems in how components of a system work together. These tests validate the software architecture design. The development team or quality assurance team performs integration testing. BAs may assist by identifying test cases and reviewing test results. Inadequate integration testing, often due to waiting too late in the development process, is one of the main causes of project failure.

System Testing

The next level or phase of testing is called system testing. System testing is the last chance for a project team to verify a product before turning it over to users for their review. The objective of system testing is to find problems in how the software meets the users’ needs. These tests validate that the software meets the original requirements. BAs are involved with system testing by making sure that the software meets the business requirements.

There are several types of tests that may be performed as a part of system testing. Table 5.4 provides some examples.

Table 5.4: System-Level Tests
Test Type	Purpose
Requirements validation	Makes sure that system logic supports the business and functional requirements
Performance testing	Measures the speed of response
Stress testing	Pushes the software to its limits in terms of number of users and rate of input
Volume testing	Uses high-volume transactions to verify that the software will handle all growth projections
Security testing	Makes sure that unauthorized users cannot gain access to confidential data and that authorized users can effectively complete their required tasks
Installation testing	Important for software that will be shipped to users and requires local installation
Configuration testing	Determines how the software will perform on various types of hard-ware, operating system, networks, and in conjunction with other soft-ware packages running on the same system
Usability testing	Verifies that the software has been designed for the users within the principles of usability