Test Planning

Organizing Test Suites

A well-organized test suite is navigable, maintainable, and maps clearly to the product's feature areas. Structure test suites by feature area, not by test type. A developer working on checkout should find all checkout tests in one place, whether they are smoke tests, regression tests, or edge case tests.

Test Suite Structure

Organize by Feature Area

Test Suites/
  Authentication/
    Login/
      TC-101: Login with valid credentials
      TC-102: Login with invalid password
      TC-103: Login with 2FA enabled
      TC-104: Login with expired session redirect
      TC-105: Login with social provider (Google, GitHub)
    Registration/
      TC-201: Register with valid data
      TC-202: Register with duplicate email
      TC-203: Register with weak password
      TC-204: Email verification flow
    Password Reset/
      TC-251: Request password reset
      TC-252: Reset with expired link
      TC-253: Reset with used link
  Checkout/
    Cart/
      TC-301: Add item to cart
      TC-302: Remove item from cart
      TC-303: Update quantity
      TC-304: Cart persists across sessions
    Payment/
      TC-401: Pay with credit card
      TC-402: Pay with PayPal
      TC-403: Apply valid coupon
      TC-404: Apply expired coupon (error handling)
      TC-405: Insufficient funds handling

Why Not Organize by Test Type?

# BAD: Organized by test type
Test Suites/
  Smoke Tests/
    Login smoke
    Checkout smoke
    Search smoke
  Regression Tests/
    Login regression
    Checkout regression
    Search regression
  Edge Cases/
    Login edge cases
    Checkout edge cases

This structure forces you to jump between folders when working on a single feature. It also makes it hard to answer "what tests cover checkout?" because they are scattered across three folders.

Test Case Anatomy

A well-written test case is self-contained and unambiguous. Anyone on the team should be able to execute it without additional context.

Minimal Test Case

Field	Content
ID	TC-401
Title	Pay with credit card
Preconditions	User is logged in. Cart has at least one item.
Steps	1. Navigate to checkout. 2. Select "Credit Card." 3. Enter valid card details. 4. Click "Pay Now."
Expected Result	Order confirmation page displayed with order number. Payment charged. Confirmation email sent.
Priority	High
Labels	checkout, payment, smoke

Enhanced Test Case (With Parameters)

Field	Content
ID	TC-401
Title	Pay with credit card
Preconditions	User is logged in. Cart has at least one item.
Test Data	Card: 4111-1111-1111-1111, Exp: 12/25, CVV: 123
Steps	1. Navigate to checkout. 2. Select "Credit Card." 3. Enter card number `{card_number}`. 4. Enter expiry `{expiry}`. 5. Enter CVV `{cvv}`. 6. Click "Pay Now."
Expected Result	Order confirmation page displayed. Amount matches cart total.
Automation Status	Automated (checkout.spec.ts:45)
Links	REQ-003, SHOP-456

Test Cycles and Test Plans

Test Cycles

A test cycle is a single execution of a set of test cases. You create a new cycle for each sprint, release, or regression run.

Sprint 23 Test Cycle
  Status: In Progress
  Start: 2024-01-15
  End: 2024-01-26
  Assigned: QA Team
  Test Cases: 145 total
    Passed: 98
    Failed: 12
    Blocked: 3
    Not Executed: 32

Test Plans

A test plan groups multiple test cycles for a release. It provides the big-picture view of test execution across sprints.

Release 2.4.0 Test Plan
  ├── Sprint 22 Cycle (Complete: 142/142 passed)
  ├── Sprint 23 Cycle (In Progress: 98/145 passed)
  ├── Regression Cycle (Not Started)
  └── Performance Cycle (Scheduled)

  Overall Progress: 240/432 (55.6%)
  Blockers: 3 (SHOP-789, SHOP-801, SHOP-812)

Test Execution Workflows

Status Transitions

Status	Meaning	Next Steps
Not Executed	Test has not been run yet	Execute the test
In Progress	Tester is currently executing	Complete and set final status
Passed	All expected results verified	No action needed
Failed	Actual result differs from expected	File a bug, link to test
Blocked	Cannot execute due to dependency	Document blocker, notify team
Skipped	Intentionally not executed this cycle	Document reason (e.g., feature not deployed)

Execution Best Practices

Execute in priority order: Run smoke tests and critical path tests first. If those fail, investigate before running the full suite.
Document failures immediately: Do not batch failure documentation for the end of the day. File the bug while the context is fresh.
Link failures to defects: Every failed test should have a linked bug ticket. This creates traceability.
Re-execute after fixes: When a bug is fixed, re-run the failed test and update its status.
Update blockers daily: Blocked tests should be reviewed in standup. Do not let them sit blocked for the entire sprint.

Maintaining Test Suites

Test suites require ongoing maintenance. Without it, they become stale and untrustworthy.

Regular Maintenance Tasks

Task	Frequency	Why
Review and update test cases for changed features	Every sprint	Features evolve; tests must keep up
Remove obsolete test cases	Monthly	Dead tests clutter the suite and waste execution time
Update test data and preconditions	As environments change	Stale test data causes false failures
Review automation status	Every sprint	Identify manual tests that should be automated
Consolidate duplicate test cases	Quarterly	Duplicates waste execution effort

Version Control for Test Cases

If your test management platform supports versioning, use it. If not, document significant changes in the test case's history or comments. You should be able to answer: "What was this test case like when we tested release 2.3.0?"

Hands-On Exercise

Audit your current test suite structure. Is it organized by feature area or by test type?
Pick one feature area and list all test cases that cover it. Are there gaps?
Create a test cycle for your current sprint and execute 10 test cases, documenting results
Identify 5 test cases that are outdated and update them
Find duplicate test cases and consolidate them
Create a test plan for your next release with multiple test cycles