Mastering Test Case Design: Principles, Standards, and Best Practices

1 Introduction

The purpose of this document is to guide software test design, ensuring orderly and rational test case creation, improving test coverage and quality, and promoting standardized testing practices.

Applicable scope: test personnel use this as a reference for designing, maintaining, and executing test cases based on requirements.

2 Test Case Writing Plan and Conventions

2.1 Writing Principles

Adopt the "one point, multiple cases" principle: create several test cases for each test point or feature to cover multiple aspects.

Unit tests are performed by developers, who may decide whether to write unit test cases.

Each test case event flow should include at least one test requirement, derived from functional descriptions in the requirements specification.

Test item description: briefly explain the items and characteristics involved in the test case, referencing relevant documents such as requirement, design, user, or operation manuals.

Input description: specify required inputs, including values (with allowable error), constants, or transaction files.

Output description: define expected outputs and characteristics, such as response time.

Provide correct values for each output or characteristic.

Design test cases with execution in mind, using findings and experience to refine designs.

2.2 Quality Standards for Test Case Design

Measurability: all steps are concrete and executable.

Verifiability: each verification point is specific and observable.

Comprehensiveness: test data preparation is considered during design to achieve high coverage.

2.3 Test Case Management

Manage and maintain test cases using CPaaS tools, covering writing, review, planning, execution, reporting, and overall case management.

2.4 Mapping Between Test Cases and Development Phases

Test cases correspond to development stages: requirements analysis (acceptance/system testing cases), high‑level design (integration testing cases), detailed design (unit testing cases), etc.

2.5 Test Case Types

Define functional, performance, integration, security, UI, installation/uninstallation test cases with associated coverage expectations.

2.6 Relationship Between Test Phases, Types, and Roles

Unit testing involves developers; integration, system, and acceptance testing involve testers, product, and business stakeholders as appropriate.

3 Test Case Design Specification

3.1 Purpose

Guide orderly test execution and provide traceable data.

Ensure system functionality matches customer expectations.

Facilitate reuse across versions.

Track test progress and focus.

Provide metrics for evaluating test results.

Enhance software trustworthiness.

Standardize defect analysis.

3.2 Admission Criteria

Requirement specifications have passed review.

Requirement change notices have passed review.

Unit, integration, and system tests have passed.

3.3 Design Basis

Requirement specifications.

System design documents.

Interface documentation.

Test requirement specifications.

Test plans and test strategies.

3.4 Test Case Format

Test item ID (required).

Test item description (required, linked to test requirement).

Test design (required).

Test case ID (required).

Case title (required, format: [System][Module][Sub‑module] brief description [Positive]/[Negative]).

Requirement source (product, R&D, test, operations, management, other).

Test type (functional, performance, security, compatibility, UI, reliability).

Case status (normal, new, changed, deleted, retired).

Priority level (1 highest, 4 lowest).

Pre‑conditions (optional).

Steps (required, detailed with expected results).

Expected results (required for each step).

3.5 Test Design Steps

Process: test requirement analysis → business process analysis → test case design → test case review → test case refinement.

Test requirement analysis: extract test requirements from requirement documents.

Business process analysis: understand product and system workflows, document main and alternative flows, data flows, decision points, and related modules.

Test case design: determine case types (functional, boundary, exception, performance, stress) and consider edge conditions.

Test case review: involve product managers, test leads, project managers, developers, and other stakeholders.

Test case refinement: continuously update cases as features change, defects are found, or feedback is received.

3.6 Test Case Level Classification

P0: Must‑execute cases covering core system functionality; failure blocks further testing.

P1: High‑priority cases covering important functions and frequent usage scenarios.

P2: Medium priority cases covering general functions, lower usage frequency.

P3: Low priority cases covering rarely used or niche features.

3.7 Test Case Design Methods

Equivalence partitioning (valid and invalid classes).

Boundary value analysis.

Error guessing.

Cause‑effect graphing.

Orthogonal array testing.

Scenario‑based testing (normal flow vs. alternative flow).

White‑box techniques (statement, decision, condition, path coverage).

3.8 Test Case Review

After writing, the author initiates a review, which may be internal to the test team or cross‑functional involving project managers, product owners, architects, developers, and testers.

Check clarity and reasonableness of structure.

Validate priority assignment.

Ensure coverage of all functional points.

Confirm executability (pre‑conditions, steps, inputs, expected results).

Identify redundant or missing cases.

Include negative (anti‑example) cases.

Assess user‑level scenario coverage.

Promote simplicity and reusability.

3.9 Exit Criteria

Reviewed cases are updated per feedback, re‑reviewed if necessary, and considered complete when they meet the agreed standards.

3.10 Test Case Execution

Process: write case → review → execute approved case → record results.

Develop test cases after requirement review, documenting them in Excel.

Execute reviewed cases, marking pass/fail, logging bugs for failures, and noting blockers with reasons.

Perform regression testing, re‑executing blocked or failed cases and updating statuses.

3.11 Test Case Maintenance

Maintain a library of generic, reusable cases not tied to a specific product, such as common control tests.

4 Test Case Identification

4.1 Test Project ID

PTI_TMS_FUNT01_001 – PTI denotes test design phase, TMS is the software identifier, FUNT indicates functional testing, and the numeric parts represent feature and item numbers.

4.2 Test Case ID

PTI_TMS_FUNT01_001_001 – Extends the project ID with a unique case sequence.

4.3 Software Abbreviation

WMS

CRM

4.4 Requirement Source

Originates from product, R&D, test, operations, management, or other stakeholders.

4.5 Test Case Status

Possible states: normal, new, changed, deleted, retired.

5 Test Risk Analysis

Test cases without formal requirements – enforce documented requirements.

Case writing lagging behind project schedule – prioritize P0 and P1 cases.

Inadequate or superficial case reviews – define clear review outcomes and follow‑up actions.

Uncommunicated requirement changes – ensure timely notification.

Late‑joining testers lacking domain knowledge – provide training on requirements and business processes.

Incomplete case execution – track execution status and investigate gaps.

Missing test cases – conduct thorough requirement reviews to identify coverage gaps.

Untimely case maintenance – make maintenance a regular task and include it in performance evaluations.