During all the stages of the software development process unit and integration testing of the modules can occur. The goal of these test is to verify the quality of implementation and it is the developers’ responsibility. However, some kind of tests require development to have achieved a stage where the system can be exercised according to its final functionality. When this happens, it is possible to test the system from the point of view of its intended use. These tests will verify whether it will function properly once it is deployed and they are driven either by the requirements specification or the system users. In the latter case the tests’ goal is to validate the system, whereas in the former case it is its verification. During this stage both the functional and non-functional properties of the system should be tested. The testing is based on the system usage scenarios, emphasizing those that are expected to be more common, which should be captured by the definition of profiles of usage. For instance, in an academic system there are at least three distinct profiles of usage: student profile, faculty profile, and administrative staff profile. The detail with each profile is tested depends on its frequency and business value. For instance, although it is possible to accept a short interruption of service for the student profile it should be avoided for the administrative staff profile during office hours. Note that exercising the final functionality of a system does not require it to be completed implemented because the use of test doubles may allow the test of not completely implemented functionalities.
The scenarios of test can be explicitly captured by describing system interactions. This can be done using models like use cases or sequence diagrams. These scenarios can be used for both functionality testing, where each scenario is executed, and non-functionality testing, where scenarios are executed under different contexts. For instance, a large number of scenarios can be simultaneously executed in order to stress the system and detect situations that are only revealed if the system is overloaded.
Developers, a quality assurance team, or end-users can test the whole system. Developers test combinations of functionalities to verify whether there isn’t any combination that breaks the system, system testing. The quality assurance team test combinations of functionalities to verify whether it provides the intended business value, release testing. Finally end-users test the system to verify whether it performs according to their expectations, user testing. Note that user testing may include the use of the system in their final environment, beta testing. When the user testing goal is to decide if they accept the system, it is called acceptance testing. Developers follow a white-box testing strategy of the system, but focus on the specification such that tests do not unnecessarily depend on the implementation, while the quality team and end-users follow a black-box strategy.