One of the most critical objectives of quality engineering is to provide clear advice on quality and risk in a manner that instills confidence in all parties involved. To accomplish this, we must collect information about the system's behavior. This includes, but is not limited to, system requirements, functional design, user manuals, and/or administrative procedures. This activity, known to us as test design, is the process of developing, writing, and updating test cases in response to new or changing requirements. The goal of test design is to make testing more systematic and responsive to change. It should enable rigorous testing that fits within the same cycle, same sprint, while still allowing stakeholders—from business analysts to developers and testers—to remain aligned and flexible.
There are numerous test design techniques. To assist in determining which techniques to employ in a given situation, TMAP defines four so-called coverage groups . Each of these groups can be assigned to a particular test design technique. Additionally, TMAP strongly encourages to always combine coverage- and experience-based testing (such as exploratory testing).
Developing the appropriate set of test cases is critical for connecting the test strategy and its implementation - the tests that are executed. A test case is used to determine whether the system behaves as expected under specified conditions. It must therefore contain all of the components necessary to generate that system's behavior and determine whether it is correct. A well-known way to describe system behavior is
‘Input → Processing → Output’.
The following diagram illustrates the relationship between the terms used in test design: