2. Test Case Management

QA Process

Test case management ensures that testing is structured, traceable, reusable, and properly documented.

A. Writing Test Cases

1. Write Functional Test Cases

Functional test cases are written to validate whether the application behaves according to business requirements.

These test cases cover:

Happy paths
Negative scenarios
Validation rules
Boundary conditions
User permissions
Workflow behaviour

Each test case clearly defines:

Preconditions
Test steps
Expected result
Test data
Priority

The objective is to ensure that every feature behaves correctly under expected and unexpected conditions.

2. Write Non-Functional Test Cases

Non-functional testing validates aspects beyond core functionality.

These test cases include:

Performance validations
Accessibility checks
SEO validations
Security considerations
Responsiveness testing
Browser compatibility

This ensures the application performs reliably and provides a good user experience.

3. Write Edge & Corner Cases

Edge cases are written to test unusual or extreme conditions that users or systems may encounter.

Examples include:

Empty fields
Maximum limits
Zero values
Large datasets
Session expiration
Network interruption
Concurrent user activity

Testing edge cases helps identify hidden defects that normal flows may not expose.

4. Write Regression Test Cases

Regression test cases are created to ensure that new changes do not break existing functionality.

These cases cover:

Previously fixed defects
Shared components
Critical workflows
Existing modules affected by recent changes

Regression coverage is continuously expanded as the application evolves.

5. Write Smoke Test Suite

A smoke suite is a small but critical set of test cases executed after every deployment.

Smoke testing verifies:

Application accessibility
Login functionality
Core navigation
Critical workflows
Basic API connectivity

The purpose is to quickly confirm whether the build is stable enough for deeper testing.

6. Write Sanity Test Cases

Sanity testing focuses on validating specific fixes or targeted changes.

Instead of running full regression, sanity testing validates:

The affected module
Closely related functionality
Core behaviour after the fix

This helps confirm whether a particular issue has been resolved without introducing immediate side effects.

7. Peer Review Test Cases

Before execution begins, test cases are reviewed by another QA engineer or developer.

The review process checks:

Completeness
Clarity
Requirement coverage
Missing scenarios
Technical accuracy

Peer reviews improve test quality and reduce missed scenarios.

B. Maintaining Test Cases

1. Update Cases When Requirements Change

Requirements often evolve during development.

Whenever changes occur:

Existing test cases are reviewed
Impacted scenarios are updated
Obsolete validations are removed
New conditions are added

Keeping test cases updated ensures execution accuracy.

2. Retire Obsolete Cases

Test cases related to deprecated or removed features are archived or removed.

Obsolete test cases:

Waste execution time
Create confusion
Reduce suite maintainability

Regular cleanup helps keep the test repository relevant and efficient.

3. Version Test Cases with Releases

Test cases are tagged according to:

Sprint
Release version
Feature version
Milestone

This helps maintain historical traceability and simplifies regression planning.

4. Map Cases to Requirements

Every test case should map back to:

User stories
PRD requirements
Acceptance criteria

This traceability ensures:

Complete requirement coverage
Easier audit tracking
Better release visibility
Faster impact analysis during changes