functional-test-case-standard

Generate and evaluate functional test cases following standardized quality dimensions. Use when creating test cases, reviewing test case documents, analyzing test case quality, scoring test cases, or when the user mentions test case templates, test case evaluation, test case standards, or test case quality assessment. Supports Markdown and XMind mindmap output formats with version management.

Overview

This skill provides standardized guidelines for writing high-quality functional test cases and an 8-dimension evaluation framework for assessing test case quality.

Core Features:

• ✅ Standardized test case design with 15+ design methods
• ✅ 8-dimension quality evaluation framework with scoring
• ✅ Deep requirement analysis using 5 analysis methods
• ✅ Dual output formats: Markdown (default) and XMind mindmap
• ✅ Two export modes: Review dimension and Execution dimension
• ✅ Timestamp-based version management for traceability

Requirement Analysis Methodology

Before designing test cases, perform deep requirement analysis using these 5 methods to extract all test details:

1. Sentence-by-Sentence Analysis Method

Analyze each sentence in the requirement document to identify:

• Condition words: if, when, unless, only if, etc.
• Action words: click, input, select, submit, delete, etc.
• State words: display, hide, enable, disable, active, inactive, etc.
• Data words: create, read, update, delete, calculate, validate, etc.

Output: Each identified element becomes a verification item.

Example:

• Requirement: "When user clicks Submit button, if all required fields are filled, display success message and redirect to order list."
• Extracted verifications:
  • Condition: all required fields filled → test with valid/invalid combinations
  • Action: click Submit button → verify button is clickable and responsive
  • State: display success message → verify exact message text
  • Data: redirect to order list → verify correct page navigation

2. Business Process Analysis Method

Identify the complete business flow from start to end:

• Process nodes: Each step in the workflow
• Decision branches: All if-else or switch conditions
• Exception exits: Error handling, timeout, cancel, rollback
• Parallel flows: Concurrent processes or independent branches

Output: Each node and branch becomes a test scenario.

Example (Order Flow):

• Node 1: Create order → test with valid/invalid products
• Node 2: Payment → test successful payment, payment failure, timeout
• Node 3: Ship → test shipping with/without inventory
• Branch: Payment failure → test retry, cancel, refund flows

3. Data Flow Analysis Method

Trace data through its complete lifecycle:

• Data acquisition: Where does data come from? (user input, API, database, third-party)
• Data processing: How is data transformed? (calculation, validation, formatting)
• Data storage: Where is data saved? (database, cache, file, session)
• Data display: How is data presented? (UI, report, export, notification)

Output: Each data transformation point becomes a verification item.

Example (User Registration):

• Acquisition: user enters username, email, password
• Processing: validate format, encrypt password, check uniqueness
• Storage: insert into users table, send to CRM system
• Display: show success message, send confirmation email

4. State Transition Analysis Method

Model the system as a finite state machine:

• Identify all states: Draft, Pending, Approved, Rejected, Completed, Cancelled, etc.
• Identify transition conditions: What triggers state changes?
• Identify valid transitions: Allowed state changes
• Identify invalid transitions: Disallowed state changes (should show error)
• Identify self-transitions: Staying in the same state after action

Output: Each valid and invalid transition becomes a test case.

Example (Order Status):

• Valid: Draft → Pending (submit), Pending → Approved (approve), Approved → Shipped (ship)
• Invalid: Draft → Shipped (skip states), Shipped → Pending (reverse), Rejected → Approved (without revision)

5. User Scenario Analysis Method

Analyze from different user perspectives:

• Different roles: Admin, Manager, Regular User, Guest, etc.
• Normal scenarios: Happy path, typical usage
• Exception scenarios: Error handling, edge cases, abnormal conditions
• Extreme scenarios: High concurrency, large data volume, network failure, system timeout

Output: Each role-scenario combination becomes a test case.

Example (File Upload):

• Admin + Normal: upload valid file within size limit
• User + Exception: upload oversized file, wrong format
• Guest + Extreme: upload during network timeout, concurrent uploads

Requirement Analysis Workflow

1. Read requirement document thoroughly (do not skip any section)
2. Apply all 5 analysis methods to extract test details
3. Organize results into:
   • Functional module inventory
   • Business rule inventory
   • Exception scenario inventory
   • Test data inventory
4. Map to test cases using design methods from Test Design Methodology section

Output Format Selection

This skill supports two output formats with user-selectable options:

Format Mode

Format	Trigger	Description
Markdown (default)	User does not specify format	Generate standard Markdown test case document
XMind Mindmap	User explicitly requests "mindmap format", "XMind format", or "both md and xmind"	Additionally generate XMind mindmap file for visual review

Export Dimension

Dimension	Use Case	Structure	When to Use
Review Dimension (default)	Quality evaluation, peer review, requirement coverage analysis	Organized by: Module → Feature → Test Point → Verification Items (focus on completeness and coverage)	When stakeholders need to review test case coverage, during requirement review meetings, for quality audits
Execution Dimension	Test execution, automation, step-by-step testing	Organized by: Module → Test Case → Steps → Expected Results (focus on executability and traceability)	When testers execute test cases, for automation script generation, during test execution phase

User Selection Guide

Ask user before generation:

1. "Which output format do you prefer? (Markdown only / Markdown + XMind mindmap)"
2. "Which export dimension? (Review dimension for coverage analysis / Execution dimension for test execution)"

Default behavior: If user does not specify, generate Markdown format with Review dimension.

XMind Mindmap Structure

Review Dimension Structure:

text

Product Requirement Name
├── I. Module Name
│   ├── 1.1 Sub-feature Name
│   │   ├── 1.1.1 Function Point
│   │   │   ├── Test Point: Condition Verification
│   │   │   │   ├── [ ] Verification Item 1
│   │   │   │   ├── [ ] Verification Item 2
│   │   │   │   └── [ ] Verification Item 3
│   │   │   └── Test Point: Business Rule Verification
│   │   │       ├── [ ] Verification Item 1
│   │   │       └── [ ] Verification Item 2

Execution Dimension Structure:

text

Product Requirement Name
├── I. Module Name
│   ├── 1.1 Sub-feature Name
│   │   ├── TC-001: [Module][Platform] Feature - Condition - Validation
│   │   │   ├── Precondition: ...
│   │   │   ├── Steps
│   │   │   │   ├── 1. ...
│   │   │   │   ├── 2. ...
│   │   │   │   └── 3. ...
│   │   │   ├── Expected Result
│   │   │   │   ├── 1. ...
│   │   │   │   ├── 2. ...
│   │   │   │   └── 3. ...
│   │   │   └── Priority: P0/P1/P2

Version Management

Timestamp-Based Versioning

Every test case generation creates a versioned file to enable traceability and historical comparison.

File Naming Convention:

text

{requirement-name}-v{MMdd_HHmmss}.md
{requirement-name}-v{MMdd_HHmmss}.xmind

Timestamp Format:

• Format: MMdd_HHmmss (MonthDay_HourMinuteSecond)
• Example: 0318_143052 means March 18, 14:30:52

Example:

• Requirement: "User Registration Enhancement"
• Generated files:
  • user-registration-enhancement-v0318_143052.md
  • user-registration-enhancement-v0318_143052.xmind (if XMind requested)

Version Management Benefits:

• ✅ All historical versions are preserved
• ✅ Easy comparison between different generations
• ✅ Trace test case evolution over time
• ✅ Support rollback to previous versions if needed

Version Comparison: When user requests comparison between versions:

1. List all available versions with timestamps
2. Show differences in: test case count, coverage changes, priority adjustments
3. Highlight added/modified/removed test cases

Design Principles

Functional Item as Unit

Design test cases by functional item. Group related functional points by business or operation type into "functional items" — each item contains one or more similar functional points. For a given functional item, input a specific set of data or operation sequence, and verify the unique output result for each functional point within that item.

Core Principles

1. Operation Granularity: Each case focuses on one group of similar functional items. Steps must be clear and the target explicit.
2. Input-Output One-to-One Mapping: Define a unique input set for the functional item, and strictly verify the corresponding output result. Ensure both test coverage and result judgment are unambiguous.
3. Clear Boundaries: Functional item boundaries are well-defined. Do not cross-item test. Avoid redundancy and duplicate operations.
4. Case Independence: Design each case to be self-contained with no inter-case dependencies. Clear boundaries between functional items minimize redundancy and maximize maintainability.

Layered Testing Strategy (Test Pyramid)

Understand test layering to avoid over-reliance on a single test type. The pyramid guides resource allocation and test design focus for functional testing.

text

        /\
       /  \     E2E Tests (fewer, slower, high maintenance)
      /----\    ————————————————————————————————————————
     /      \   API / Integration Tests (moderate count, faster)
    /--------\  ————————————————————————————————————————
   /          \ Unit / Component Tests (most, fastest, cheapest)
  /------------\

Layer	Scope	Speed	Maintenance	When to Design Cases Here
Unit	Single function/class	<100ms	Low	Complex business logic, calculation rules, state machines
Integration	Module interactions	<1s	Medium	Database operations, message queues, third-party service calls
API	Interface contracts	<1s	Medium	Parameter validation, response structure, error codes, auth
E2E	Full user workflow	Seconds~minutes	High	Cross-module business flows, user-facing critical paths

Guidelines:

• Push tests as low in the pyramid as possible.
• E2E cases should cover only cross-module critical paths and user journeys.
• API cases should validate all parameter combinations and error responses.
• Unit tests should cover all branches and boundary conditions of business logic.

Test Case Granularity

Default adoption: Level 2 granularity.

Level	Definition	Characteristics	When to Use
Level 1	Validates a single, independent, indivisible functional point. The smallest functional verification unit with clear input and expected output.	Finest granularity; each case tests one boundary or rule.	When boundary values and independent rules need precise isolation.
Level 2 (Default)	Groups and merges multiple Level-1 points of the same type or related functional points into a small category.	Integrates similar points for systematic organization; easier management and maintenance.	Default choice for functional test cases. Balances coverage and maintainability.
Level 3	Further integrates Level-2 cases of the same type or business relation into a large category.	Broader business scenario focus; higher-level test perspective; lower maintenance cost.	When a high-level overview of module coverage is needed.

Level 2 Granularity Example

Requirement: Username restriction: length 6-20, lowercase English letters and digits only.

Level 2 case:

• Name: [User Management][WEB] User Registration - Username Length Validation
• Steps:
  1. Enter username with length below 6 characters
  2. Enter username with length above 20 characters
• Expected Results:
  1. Display error: "Username must be between 6-20 characters"
  2. Display error: "Username must be between 6-20 characters"

For detailed granularity examples, see reference.md.

Naming Convention

Unified format: [Module][Platform] Feature - Condition - Validation Point

• Module: The business module name (e.g., User Management, Order Processing)
• Platform: WEB / APP / H5 / API
• Feature: The functional item under test
• Condition: The specific input condition or rule
• Validation Point: The verification point or operation being tested

Naming principles:

• Use the functional item's input condition as the naming description. Keep it concise.
• Specific inputs should be included; expected results are optional to avoid overly long names.
• Avoid vague words like "verify" or "test".

Examples:

• [Feedback][APP] Feedback Creation - Content - Length Validation
• [Promotion][WEB] Red Packet Campaign - Manual Stop - Impact Validation
• [OOH Management][WEB] OOH File Import - Template - Sales Region3 Required Field

Case ID

Format: primary_module_secondary_module_sequence_number

• Example: user_reg_001, order_create_014, product_import_005
• Must be unique within the project
• Should reflect module hierarchy for easy location

Required Fields

Field	Required	Description
Case Name	Yes	Follow naming convention; concise input-condition-based description
Case ID	Yes	primary_module_secondary_module_sequence_number
Precondition	No	Prerequisites, specific inputs, and materials needed for the test
Test Steps	Yes	Clear, executable operation steps with specific UI elements
Expected Result	Yes	Unique, clear output result for the functional item, including state changes
Case Type	Yes	Functional / Smoke / Main-Flow / Single-API / API-Flow
Priority	Yes	P0(blocking/high) / P1(core/medium) / P2(normal/low)
Project	Yes	The project this case belongs to
Version	Yes	The version this case belongs to
Module	Yes	The module this case belongs to
Postcondition	No	Impact scope; fill when requirements change

Case Type Definitions

Type	Description
Functional Test Case	Precisely designed for specific functional points with clear input and output. Example: verify username length limits, covering max, min, and empty boundary cases.
Smoke Test Case	Selected P0 cases from the test suite. Quickly validates whether critical main functions are available to determine if deeper testing can proceed.
Main-Flow Business Case	Designed according to business processes, covering the full lifecycle from start to end. Example: User A creates an order -> B processes it -> C approves -> D completes payment.
Single-API Case	Validates interface input parameters: required fields, empty values, wrong types, length overflow, etc.
API Business Flow Case	Uses interface operations to flow through the entire business process from start to end, validating business process integrity.

Test Design Methodology

Design methods are categorized into 5 groups. Select methods based on the functional item's characteristics.

1. Input Domain Methods

• Equivalence Class Partitioning: Divide input domain into valid and invalid equivalence classes. Test one representative from each class.
• Boundary Value Analysis: Test values at boundaries (min, max, min-1, max+1, typical values, empty/null).

Best for: Form fields, numeric ranges, length limits, date ranges, enum values.

2. Combination Methods

• Decision Table: Use when multiple conditions interact to produce different actions. List all condition combinations.
• Cause-Effect Graphing: Map causes to effects with constraint relationships (AND, OR, NOT, M, O, R, I).
• Orthogonal Testing: Use orthogonal arrays to reduce N-dimensional combination explosion to representative subsets.
• Pairwise Testing: Test all possible pairs of parameter values (Pairwise / n-wise).

Best for: Multi-field forms, configuration combinations, filter combinations, permission matrices.

3. Flow & State Methods

• Scenario-Based Testing: Design test scenarios based on business processes (normal flow, alternative flows, exception flows).
• State Transition Testing: Model system as a finite state machine. Test all valid transitions, invalid transitions, and self-transitions.
• Business Process Diagram Method: Derive test paths from business process diagrams (BPMN).

Best for: Approval workflows, order lifecycles, stateful entities, multi-step operations.

4. Experience-Based Methods

• Error Guessing: Based on past defect data and experience, predict likely failure points and design targeted test cases.

Best for: Complex legacy systems, areas with high historical defect density, regression testing of fixed defects.

5. Modern Methods

• Risk-Based Testing: Assign risk score = Impact × Probability. Prioritize test effort by risk. Use FMEA for systematic analysis.
• Data-Driven Testing: Separate test logic from test data. Store data in CSV/Excel/DB. Same case runs with multiple data sets.
• Keyword-Driven Testing: Abstract operations as reusable keywords (e.g., "Login", "Search", "Verify").
• Model-Based Testing: Generate tests from state machines, decision trees, or AI models.
• Fuzzing: Design test cases using random, malformed, or unexpected inputs as test data to cover edge cases.
• Property-Based Testing: Design invariant properties (e.g., "sorting output must be ordered") and generate test data to verify them.

Best for: Regression test case design, complex stateful system test design.

Method Selection Guide

Functional Item Characteristic	Recommended Methods
Input forms with multiple fields	Equivalence class + Boundary value + Decision table
Business workflows with approvals	Scenario + State transition + Error guessing
Configuration / permission matrix	Pairwise + Decision table
API parameter validation	Boundary value + Equivalence class + Error guessing
Complex calculation logic	Equivalence class + Boundary value + Property testing
Unknown / new features	Risk-based testing + Error guessing

Field Rules

Precondition

• Not required if none. Only fill when prerequisites are necessary.
• Must include: account role, permissions, system data state, or specific test data.
• If the case cannot execute without certain conditions, they must be documented.

Test Steps

• Number sequentially: 1. 2. 3.
• Be specific to button names, menu paths, field names.
• Input data must specify exact values.
• For Level 2 granularity: each step tests one boundary/condition within the same functional item.
• Keep 2-5 steps per case; split if exceeding 7 steps.

Expected Result

• Must be specific, observable, and verifiable.
• Each step has a corresponding expected result.
• Include state changes during the operation.
• Avoid vague phrases like "display correctly" or "function normally".
• For errors: include exact error message text.
• Must be independently judgeable as pass/fail.

Priority Assignment

• P0 / High: Core business paths, blocking issues, main workflows
• P1 / Medium: Important features, frequently used functions
• P2 / Low: General features, secondary functions, edge scenarios
• Never assign all cases to a single priority level

Test Data Strategy

Data-Driven Testing

Separate test logic from test data. Store data in external files (CSV, Excel, JSON, DB). The same test case executes with multiple data sets.

When to use: Login with multiple account types, form submission with various valid/invalid inputs, bulk import with different file formats.

Template:

text

| Data Set | Input | Expected Result |
|----------|-------|-----------------|
| Valid-1  | "user01" | Success |
| Valid-2  | "user123456" | Success |
| Invalid-1| "" | Error: username required |
| Invalid-2| "ab" | Error: min length 6 |

Parameterization Design

For cases that differ only in input values, design one case with parameters:

• Use placeholders like {username}, {password}, {amount}
• Record parameter constraints in the "Test Data" field
• Specify value ranges and boundary values

Mock / Stub Strategy

When dependencies are unavailable or unstable during test design:

• Document which external systems are mocked
• Specify mock response data for positive and negative scenarios

Case Lifecycle

text

Create -> Review -> Maintain -> Archive

Stage	Key Activities	Decision Criteria
Create	Write case following standard; self-review before submission	Completeness of fields, design rationale clear
Review	Peer review or group review; focus on coverage gaps and design clarity	Coverage ≥ 90% of requirements; no empty fields; steps clear and specific
Maintain	Update case when requirements change; add cases for new defects	Review within 1 sprint of requirement change
Archive	Archive obsolete cases; do not delete (for audit trace)	Case no longer applicable for 2+ versions

Maintenance Triggers

• Requirement changes (functional or UI)
• Defect found in production not covered by existing cases
• Test data or environment changes
• Process optimization (merge/split cases)

Common Word Constraints

Use consistent terminology across the team:

Preferred	Alternatives to Avoid
Create	Add, New, Insert
Query	Filter, Search
Edit	Modify, Update
Delete	Remove, Clear
Submit	Save, Confirm
Import	Upload (file scenarios only)
Export	Download (file scenarios only)

8-Dimension Quality Evaluation Framework

Evaluate each test case author across these 8 dimensions (0-10 scale):

1. Naming Convention

• 9-10: >90% follow [Module][Platform] Feature - Condition - Validation Point format
• 7-8: 60-90% follow format, some inconsistency
• 5-6: 30-60% follow format, mixed styles
• 3-4: <30% follow format, mostly free-form
• 0-2: No format consistency, names unclear

2. Structural Integrity

• 9-10: All cases have steps + expected result with substance; preconditions filled when needed
• 7-8: >80% complete, minor omissions
• 5-6: 50-80% complete, noticeable gaps
• 3-4: <50% complete, many empty fields
• 0-2: Mostly template shells without content

3. Step Executability

• 9-10: Steps specific to buttons/fields/menus, directly executable by anyone
• 7-8: Mostly specific, some vague descriptions
• 5-6: Mix of specific and vague steps
• 3-4: Mostly vague, hard to execute consistently
• 0-2: Steps are empty or meaningless

4. Expected Result Verifiability

• 9-10: Each step has specific, quantifiable, observable expected result
• 7-8: Most have substance, some are vague
• 5-6: About half are specific, half vague or empty
• 3-4: Mostly vague like "display correctly"
• 0-2: Expected results empty or missing

5. Test Design Method Diversity

• 9-10: Uses 4+ methods from the 5 categories above
• 7-8: Uses 3 methods with good coverage
• 5-6: Uses 2 methods
• 3-4: Uses 1 method primarily
• 0-2: No discernible design method

6. Positive/Negative Coverage

• 9-10: Balanced ratio (1:1 to 3:1), good exception coverage
• 7-8: Ratio 3:1 to 5:1, some exception coverage
• 5-6: Ratio 5:1 to 10:1, limited exceptions
• 3-4: Mostly positive cases, rare negatives
• 0-2: Almost exclusively positive cases

7. Priority Rationality

• 9-10: Well-distributed across P0/P1/P2 or High/Medium/Low
• 7-8: Mostly reasonable, minor imbalances
• 5-6: Noticeable imbalance (e.g., 70%+ in one level)
• 3-4: Severe imbalance (e.g., 90%+ in one level)
• 0-2: All cases same priority, no differentiation

8. Test Data Specificity

• 9-10: >50% cases include specific input values
• 7-8: 30-50% include specific values
• 5-6: 10-30% include specific values
• 3-4: <10% include specific values
• 0-2: No specific test data, all vague descriptions

Scoring Formula

Composite Score = round(average of 8 dimensions, 1)

Grade Mapping:

• 8.0-10.0: Excellent (Benchmark)
• 6.0-7.9: Good
• 4.0-5.9: Needs Improvement
• 0-3.9: Poor

Generation Workflow

When generating test cases from requirements:

1. Ask User Preferences:

   • Output format: Markdown or Markdown + XMind?
   • Export dimension: Review or Execution?

2. Perform Requirement Analysis:

   • Apply all 5 analysis methods (Sentence-by-Sentence, Business Process, Data Flow, State Transition, User Scenario)
   • Extract: functional modules, business rules, exception scenarios, test data

3. Design Test Cases:

   • Select appropriate design methods from Test Design Methodology section
   • Follow Level 2 granularity by default
   • Apply naming convention and field rules

4. Generate Output Files:

   • Create timestamp-based filename: {name}-v{MMdd_HHmmss}.md
   • If XMind requested: also generate {name}-v{MMdd_HHmmss}.xmind
   • Structure according to selected dimension (Review or Execution)

5. Self-Review:

   • Run through Writing Checklist
   • Verify 8-dimension quality criteria
   • Ensure requirement coverage ≥ 95%

Evaluation Workflow

When evaluating test cases:

1. Read the test case file and identify all authors
2. Analyze per author across the 8 dimensions using quantitative metrics
3. Score each dimension 0-10 with evidence
4. Calculate composite score
5. Write evaluation report with:
   • Score table per author
   • Strengths per author
   • Improvement suggestions per author
   • Team-wide common issues
   • Actionable recommendations

Case Template

text

| Field | Value |
|-------|-------|
| Case ID | order_create_014 |
| Case Name | [Order Management][WEB] Order Creation - Product Quantity - Boundary Validation |
| Project | E-Commerce Platform |
| Version | V2.3.0 |
| Module | Order Processing |
| Case Type | Functional Test Case |
| Priority | P1 |
| Precondition | 1. User logged in with valid credentials<br>2. Products available in inventory |
| Test Steps | 1. Navigate to Order Management > Create Order<br>2. Select product and enter quantity as 0<br>3. Click Submit button<br>4. Enter quantity as 999<br>5. Click Submit button |
| Expected Result | 1. Order creation page loads successfully<br>2. Display error: "Quantity must be at least 1"<br>3. Display error: "Maximum order quantity is 100" |
| Postcondition | None |

Writing Checklist

Before submitting test cases, verify:

Pre-Generation Questions

• Confirm output format with user: Markdown only or Markdown + XMind?
• Confirm export dimension: Review dimension or Execution dimension?
• Apply all 5 requirement analysis methods before designing cases

Basic Completeness

• Naming follows [Module][Platform] Feature - Condition - Validation Point format
• Case ID follows primary_module_secondary_module_sequence_number format
• Precondition filled as needed (don't blindly write "None")
• Each step specifies button/field/menu names
• Each step has a corresponding expected result
• Expected results are specific and verifiable (no "correctly"/"normally")
• Priority distribution is reasonable (not all same level)
• Both positive and negative cases are covered
• Specific test data values are provided
• Cases are independent (running order does not affect results)
• Default Level 2 granularity (2-5 steps per case)
• Use consistent terminology (Create/Query/Edit/Delete/Submit)

Design Quality

• At least one design method is consciously applied (equivalence, boundary, scenario, etc.)
• Input-output mapping is one-to-one (no ambiguous expected results)
• Boundary values are covered for numeric/length/date fields
• Empty/null/whitespace inputs are tested for text fields
• Cross-field validation is covered (e.g., start date > end date)
• Error messages include exact text, not just "error prompt"
• State changes are documented (before/after states)
• Data persistence is verified (create -> query -> update -> delete cycle)

Layering & Types

• Test pyramid is considered during design (not all cases are E2E-level design)
• API cases cover all parameter combinations and error codes
• UI cases cover only cross-module critical paths
• Smoke cases are marked as P0 and cover main workflows

Maintainability

• Case is traceable to a requirement ID
• Postcondition records impact scope when applicable
• Test data can be reproduced (not dependent on random production data)
• Case does not contain hard-coded values that change per environment

Review Checklist (For Peer Review)

Reviewers use this checklist to verify case quality:

text

Review Item                              Pass  Fail  Notes
─────────────────────────────────────────────────────────
Naming follows standard format            □    □
ID is unique and reflects module hierarchy □    □
Preconditions adequately described        □    □
Steps executable (specific to UI elements) □    □
Expected results verifiable (specific)     □    □
Priority reasonably assigned               □    □
Granularity appropriate (Level 2 default)  □    □
Positive/negative coverage balanced        □    □
Test data specific                         □    □
Design method identifiable                 □    □
Traceable to requirements                  □    □
─────────────────────────────────────────────────────────
Review Conclusion: Pass / Needs Revision / Fail
Reviewer: __________  Date: __________

Additional Resources

• For detailed scoring rubrics per dimension, see reference.md
• For example evaluations of real test cases, see examples.md
• For XMind format specifications and version management guidelines, see reference.md sections: XMind Format Specification, Version Management
• For requirement analysis examples, see reference.md section: Deep Requirement Analysis Examples