There are two fundamentally different approaches to system testing.
In the first case, system requirements are used to develop tests, for example, a test is written for each requirement in order to check whether this system requirement is met. This approach is especially widely used in the development of military and scientific systems, when the customer is fully aware of what functionality he needs, and specifies a complete set of formal requirements. In this case, the tester only checks whether the developed system corresponds to this set. This approach involves extensive and expensive requirement collection, performed before the project actually starts. In this case, to determine the requirements, a prototype of the future system is usually developed.
Specialists of software test company examine a software product being built to make sure that it is free from bugs and ready for commercial release.
In the second case, the basis for developing tests is the idea of how to use the product and the tasks that it solves. On the basis of a more or less formal user model, system use cases are created, which are then used to construct test cases themselves. The use case describes how the subject uses the system to perform a particular task. Subjects or actors can perform different roles while working with the system. Use cases can be described at different level of abstraction. Use cases do not necessarily cover every requirement. It is possible to specify use cases and expand them into sets of more specific use cases (step-by-step description of the use case). In the context of a specific use case, one or more scenarios can be identified. The scenario represents a specific instance of the use case – the path in the step-by-step description of a use case. Each path (scenario) of use case should be tested.
The input data for each scenario should be selected as follows:
Both approaches can be used when constructing test cases, and when performing tasks, it is necessary to proceed as follows: