Creating & Maintaining Test Cases from Requirements—and Dealing with Unclear Specs

Creating and Maintaining Test Cases

1. Requirement Analysis

User story: Identify who (role) does what, when, and why.

Feature points: List the concrete functions to implement.

Business rules: Record constraints, calculation logic, and state transitions.

Input & output: Define expected inputs and resulting outputs.

Non‑functional requirements: Note performance, security, compatibility, etc.

2. Test Case Design

Basic elements of a test case:

Case ID (e.g., TC_Login_001)

Title – concise description of purpose.

Pre‑conditions – e.g., "User is registered".

Test steps – clear, actionable instructions.

Expected result – outcome for each step or overall.

Actual result – filled during execution.

Priority – high/medium/low based on importance.

Test type – functional, UI, compatibility, etc.

Common design methods:

Equivalence classes – valid: 18, 30, 60; invalid: 17, 61, "abc".

Boundary values – 17, 18, 19, 59, 60, 61.

Scenario method – simulate real user flows (e.g., add‑to‑cart → checkout → pay).

Error‑guessing – anticipate likely failure points such as network interruption or duplicate submissions.

3. Test Case Review

Confirm alignment with requirements.

Identify omissions or design errors.

Help developers understand testing focus and encourage self‑testing.

4. Test Case Maintenance

When to maintain:

After a version release – update cases for new or changed features.

When defects reveal uncovered scenarios – add new cases.

When requirements change – synchronize affected cases.

Maintenance actions:

Deprecate or archive outdated cases.

Modify steps or expected results of existing cases.

Add new cases for new functionality or scenarios.

Case Study: Online Education Platform – “Course Review” Feature

Original (unclear) Requirement

Users can comment on purchased courses. Comments may contain text and stars. Other users can see these comments.

Clarified Requirements (PM feedback)

Star rating is an integer 1‑5, mandatory, default 5.

Comment length 2‑500 characters, supports common emojis, no images or links.

Strict verification of purchase status – front‑end hide alone is insufficient (risk of API abuse).

Users can edit or delete their comment within 24 hours after posting.

Comments displayed newest first; add filters for "latest", "most popular", "good (4‑5 stars)", "bad (1‑2 stars)".

Test Case Example (after clarification)

Case ID: TC_Review_001 Title: Verify that a purchased‑course user can successfully post a comment with valid content

Priority: High

Pre‑conditions: 1. User is logged in; 2. User has purchased the course.

Test Steps:

Open the course detail page.

Click the "Add comment" box.

Enter a normal comment of 300 characters.

Select "4 stars".

Click the "Submit" button.

Observe the system response.

Expected Result:

System shows "Comment posted successfully".

The comment appears at the top of the comment list.

The displayed star rating is 4.

"Edit" and "Delete" buttons are visible under the comment.

Maintenance after V2.0 Change

Update TC_Review_001 expected results to reflect the new rule: comment can be edited within 1 hour and deleted within 24 hours.

Add a new case to verify the scenario "editable after 1 hour but not deletable".