How to Build a Comprehensive Test Strategy Using the Four‑Step Method

1 Start

When a new development project (Project A) begins, the software test architect must first collect basic project information such as scope, manpower, and historical data before creating a test strategy.

2 First Use of the “Four‑Step Test Strategy Formulation Method”

After gathering initial information, the architect applies the four‑step method (see Figure 2).

2.1 Product Quality Levels

The product quality evaluation model defines four quality grades from the end‑user perspective:

Level 1 – Fully commercial: features fully meet user needs with few or no residual issues.

Level 2 – Restricted commercial: some scenarios are unmet, but workarounds exist.

Level 3 – Test/demo or limited trial: features partially meet needs; serious residual issues exist, limiting use to beta or demo.

Level 4 – Unusable: features cannot meet user needs and cause critical failures.

These grades describe the desired quality at product release, not during testing (see Figure 3).

2.2 Determining Quality Grades for Each Feature

The architect, together with requirements engineers and development managers, assigns a product‑quality grade to each feature (Table 1), assuming feature definitions are complete.

2.3 Project‑Level Risk Analysis

Using the risk‑assessment checklist from Section 7.1, the architect evaluates overall project risks and records mitigation activities in the quality‑grade table (see Table 1 and Figure 4).

2.4 Structuring the Test Strategy

The four‑step method yields a three‑layer test strategy:

Overall test strategy : defines product quality goals, overall risk, test focus, depth, and breadth.

Phase test strategy : breaks down quality goals for each development phase and sets entry criteria.

Test execution strategy : specifies test objectives, contents, and entry criteria for each version.

Figures 5 and 6 illustrate the relationships among these layers.

2.5 Preliminary Test Layering

Adopting the classic V‑model, the architect maps test layers to the development process (Figure 6).

2.6 Review

At this point the architect has:

Defined feature quality grades and aligned them with the core team.

Performed project‑level risk analysis and drafted quality‑assurance activities.

Established the overall, phase, and execution test‑strategy structure.

Created an initial test‑layering framework.

One iteration of the four‑step method is insufficient; the method must be revisited at later project stages (Figure 7) and its four steps are inter‑connected rather than strictly linear (Figure 8).

3 Formulating the Overall Test Strategy

Using the four‑step method again, the architect decomposes product quality goals (Figure 9) and further breaks them down by quality grade (Figure 10). The process includes:

3.1 Decomposing Product Quality Goals

Based on the determined quality grades, quantitative indicators are defined (Table 2) and a “Feature‑Quality‑Grade” table is created (Table 3).

3.2 Applying the Legacy‑Feature Analysis Method

The architect classifies features as new, inherited, or heavily changed, and records the classification in a table (Table 5).

3.3 Determining Test Depth and Breadth

Test depth is set using the product‑quality model (Table 6) and refined with legacy‑feature analysis (Table 7). Test breadth aims for 100 % requirement coverage, but low‑risk or unchanged features may be scoped down.

3.4 Defining Test Priorities

Priorities are scored based on quality grade, feature novelty, and change magnitude (Tables 8, 9, 10). The resulting priority guides test‑effort allocation.

3.5 Establishing the Overall Test Framework

The framework consists of three layers: strategy (brain), activity (body), and assurance (senses). The complete framework is visualized in Figure 11.

3.6 Review

Progress includes decomposed quality goals, risk‑based feature classification, defined test depth/breadth, priority scoring, and a three‑layer test framework.

4 Formulating Phase Test Strategies

Phase strategies inherit from the overall strategy and guide analysis and design. They cover:

4.1 Test Design Strategy

Test depth is translated into concrete test cases using a “Test Analysis Design” suite composed of three tables: preparation, type analysis, and functional‑interaction analysis (Figures 14‑18).

4.2 Integration Test Strategy

A fictional “Tetris‑Heart” project illustrates integration development (Figures 20‑23). Integration testing validates that newly integrated features work correctly at the system level (black‑box) and that existing functionality remains unaffected.

4.3 System Test Strategy

System testing follows integration testing, focusing on overall functional correctness and non‑functional quality. Entry criteria combine integration‑test exit criteria with test‑readiness; test‑case selection reuses relevant cases with appropriate levels.

4.4 Acceptance Test Strategy

Acceptance testing (Alpha and Beta) confirms that the product meets user requirements and is ready for release. Alpha testing is performed by internal staff simulating users; Beta testing involves actual users providing feedback before final release.

4.5 Review

The architect has now defined design, integration, system, and acceptance test strategies, completed the “Test Analysis Design” tables, and assigned test‑case levels.