Project: A Test Plan from an SRS

Project: A Test Plan from an SRS

Throughout this tutorial you have studied verification and validation, test levels, requirements-based test cases, design techniques, UAT, the Requirements Traceability Matrix, defect management, non-functional testing, and quality gates. This final lesson brings those skills together in a single, realistic exercise: deriving a complete test plan and representative test cases directly from a sample Software Requirements Specification (SRS).

The scenario is a Clinic Patient Portal — an online system that lets patients book appointments, view medical records, and receive automated reminders. The SRS excerpt below is deliberately representative of real project documentation: some requirements are crisp and testable, others need a moment of analyst thought before test conditions emerge. You will walk through the full analyst workflow from SRS to test plan.

Step 1 — Read the SRS Extract

The following extract is drawn from a fictional but realistic SRS for the Clinic Patient Portal (CPP). Study it before reading further — your test plan derives exclusively from these statements.

Step 2 — Structure the Test Plan

A test plan is the governing document for a testing effort. It does not contain every test case — it defines scope, approach, responsibilities, schedule, and entry/exit criteria. A lean but complete test plan for CPP v1.0 looks like this:

Step 3 — Derive Representative Test Cases

With the test plan in place, you now write test cases for a representative sample of requirements. A complete suite for CPP would contain 80-120 test cases; the six cases below are the analyst-designed anchors — one per functional requirement — from which the QA team extends coverage.

Step 4 — Map to a Requirements Traceability Matrix (RTM)

Once test cases are written, you map them into the RTM to confirm every requirement has at least one test case and every test case traces to at least one requirement. Below is the RTM for CPP v1.0 (condensed to show coverage rather than every extended test case).

Step 5 — Identify the UAT Scenarios

Alongside the formal test case suite, the analyst writes end-to-end UAT scenarios that real stakeholders will execute. UAT scenarios differ from test cases: they describe complete business journeys, not isolated conditions. For CPP v1.0, three UAT scenarios cover the main user workflows:

• UAT-01 "New Patient Journey": A new patient registers, searches for a cardiologist, books a slot, receives a confirmation email, and then views the appointment in their history. Acceptance owner: Patient representative.
• UAT-02 "Cancellation and Rebooking": A patient cancels a valid appointment (within the 2-hour window), confirms the slot is freed in search results, and immediately rebooks a different slot. Acceptance owner: Clinic receptionist.
• UAT-03 "Security Lockout Recovery": A patient enters the wrong password 5 times, waits 30 minutes (simulated with test data), and successfully recovers access with the correct password. Acceptance owner: Clinic IT administrator.

Analyst Takeaways

Stepping back from the CPP project, the workflow you have just applied is repeatable on any system of any size:

1. Tag requirements by type before writing a single test case — type determines technique and owner.
2. Write the test plan first — scope, entry/exit criteria, and responsibilities before individual test cases.
3. Derive test cases from requirement conditions — decompose each requirement into testable predicates; each predicate becomes a positive or negative test case.
4. Apply BVA at every numeric boundary — the 8-character password, the 2-hour cancellation window, the 12-month history limit, the 60-second email deadline — all are explicit boundaries the SRS handed you.
5. Complete the RTM — it is the evidence of coverage, not just a bureaucratic artifact.
6. Separate UAT scenarios from system test cases — UAT validates business journeys; system tests verify individual requirements.