[ISTQB] 4.1 The Test Development Process (K3)

Test design is essential for:
- establishing a clear roadmap of all test activities to perform.
- ensure traceability on how the requirements of a system/component have been analysed and tested. 

Design could be informal/formal: it depends upon context (system criticality, processes in place, organisation, maturity, time constraints) and people involved to write them.

For formal documentation: test basis should be identified for designing relevant test deliverables (see list below in LO-4.1.1). The objective is to clarify what should we be testing.

LO-4.1.1 Differentiate between a test design specification, test case specification and test procedure specification (K2) 

• test design specification: is a document specifying:
• the test conditions (coverage items) for a test item.
• the detailed test approach and identifying the associated high level test cases. 

From a test plan which is the first test deliverable in the hierarchy in the standard IEEE829, there could be several test design specification which identify features to be tested, test approach to respect and specific techniques to use, plus references to the test case and test procedure specification.

• test case specification: is a document specifying:
• a set of test cases (objective, inputs, test actions, expected results and execution pre conditions) for a test item. 
• There could be one or many test case specification related to one single test design specification.

• test procedure specification: is a document specifying:
• a sequence of actions for the execution of a test (test script or manual test scripts).
• They are included in test execution schedule in their context and in the order in which they are to be executed. Purpose, special requirements and procedure steps are part of this document.

LO-4.1.2 Compare the terms test condition, test case and test procedure (K2) 

Test conditions results from test basis analysis and risk analysis which determine level of detail and approach to adopt. According to the ISTQB definition, they are "an item or event that could be verified by one or more test cases". 

Test conditions can be met or not (status passed or failed) and could be: 

• component test conditions: demonstrate that a data is archived in the right format previously specified.
• component integration test conditions: demonstrate that a data passed between two components in the right format expected by both systems.
• system test conditions: are designed for attesting that a functional requirement is respected by the system/functionality.
• system integration test conditions: demonstrate that the interface and interaction requirements are met in terms of data exchanged and content between 2 systems.
• acceptance test condition: is focused on final user requirement to ensure that what is expected by the final user from the software is achieved.
• non functional test condition: is designed from non-functional testable requirement like performance, usability...

Test conditions associated to test basis should be determined for stating the purpose of each test. 

Moreover, that combination could help us to determine when changes are requested, which test is impacted and what do we have to check again (requirement test coverage).

Test cases are part of the implementation test process, they have to be able to be repeated and executed by the tester in conformance or regression testing. They include test items, input values, execution preconditions, expected results (system outputs and outcomes defined in advance), changes to data and execution post-conditions for verifying any aspect of a test conditions. 

Appropriate test techniques to use and environmental needs are identified in test case specification. 

LO-4.1.3 Evaluate the quality of test cases in terms of clear traceability to the requirements and expected results (K2) 

Horizontal traceability ensure that there is relevant relation from requirements to test conditions, to test cases and test procedures. If a test condition change (due to a new or modification of requirement), test cases and procedures impacted are consequently easily identified.

Test cases have to describe precisely expected results which should be extracted from the software/system deliverables (used as a test basis). They have to be anticipated and prepared earlier to make sure that this documentation exist or if there is a need of "requirement investigation". 

LO-4.1.4 Translate test cases into a well-structured test procedure specification at a level of detail relevant to the knowledge of the testers (K3) 

Test cases defined have to be selected, prioritised and ordered in the right sequence for the test execution : test procedure. They can be manually performed (manual test script) or using a test execution tool which is based on a automated test script.

Test execution schedule detail who, when, how long and how test procedures (manual or automated) will be executed. This also contributes to be sure that all dependencies and constraints (time, technical, test criticality) have been logically defined, so tests will be carried out on new functionalities, faults fixes and regression. 

It is clear that changes and unforeseen risks could impact the test priority and consequently test execution schedule has to be updated regarding to the situation.