Author: Haroon Khalil

Non-functional requirements describe attributes of a system’s functional behavior—i.e., how “well” a system or component should fulfill its function. Its implementation strongly influences customer/user satisfaction and therefore also how well liked the system is. According to [ISO 25010], such characteristics include user satisfaction and efficiency. From the manufacturer’s viewpoint, flexibility and portability are important aspects…

Functional testing includes all test techniques and methods that are used to test the observable input/output behavior of a test object. Functional test cases are built using the “black-box” technique described in section 5.1. The functional requirements are the test basis for the planned system behavior. Functional requirements and functional suitability Functional requirements13 specify the behavior expected…

The previous sections detailed the test levels that you need to cover during software development. The focus and objectives of these tests vary from level to level, so different types of test have to be performed with varying thoroughness. We differentiate between the following basic types:

Terminology Once integration testing is complete, the next test level is system testing. This level checks that the complete, integrated system actually fulfills its specified requirements. Here too, you might ask yourself why this step is necessary following successful component and integration testing. Reasons are: Reasons for system testing Case Study: VSR-II system testing For…

Terminology Integration testing is the next level that follows on from component testing. Integration testing assume that the test objects handed over to this level are already component tested and that any component-internal defects have been corrected as far as possible. Integration Developers, testers, and specialized integration teams then assemble groups of these components into…

Terminology Component testing involves systematically checking the lowest-level components in a system’s architecture. Depending on the programming language used to create them, these components have various names, such as “units”, “modules” or (in the case of object-oriented programming) “classes”. The corresponding tests are therefore called “module tests”, “unit tests”, or “class tests”. Components and component…

A software system is usually composed of a number of subsystems, which in turn are made up of multiple components often referred to as units or modules. The resulting system structure is also called the systems “software architecture” or “architecture”. Designing an architecture that perfectly supports the system’s requirements is a critical part of the…

The requirements for planning and traceability of development and testing vary according to the context. Likewise, the appropriateness of a particular lifecycle model for the development of a specific product also depends on the contexts within which it is developed and used. The following project-and product-based factors play a role in deciding which model to…

Iterative development The basic idea behind iterative development is that the development team can use the experience they gain from previous development stages along with real-world and customer feedback from earlier system versions to improve the product in future iterations. Such improvements can take the form of fault corrections or the alteration, extension or addition…

The V-model is an extension of the waterfall model (see [Boehm 79], [ISO/IEC 12207]). The advent of this model made a huge and lasting difference to the way testing is viewed within the development process. Every tester and every developer should learn the V-model and learn about how it integrates the testing process. Even if…