Skip to content

5. Test Case Design & ITCR
What QA authors the test plan and new test cases for the sprint's work, then has them reviewed and approved by Development in an Internal Test Case Review (ITCR) before the build reaches QA.
Owner QA authors the cases, runs the review, and owns the JIRA test plan ticket. Development reviews and approves; Management attends.
Triggers After sprint planning. Authoring runs in parallel with Development; the ITCR and the developer approval complete before Build & Release Freeze.

Summary

Because QA sits in sprint planning, it knows what is being built before a line of code is written. Right after planning, QA starts its impact analysis and creates a JIRA test plan ticket that captures the categorized test cases it will run for the sprint. Where new functionality is not covered by existing cases, QA writes new ones, working in parallel with Development. When the cases are ready, QA holds the Internal Test Case Review (ITCR): a short meeting with the developer(s) and Management where QA walks through the plan and the new cases. The developers, who understand the feature best, confirm the coverage or call out gaps and ask for more cases. The cycle ends when the responsible developer formally approves the test plan on the JIRA ticket. Only an approved test plan feeds the execution work in QA & Testing.

The point of the phase is to catch coverage gaps before testing starts, not after. A feature that ships with an untested path is far cheaper to prevent here, while the developer still has the design fresh, than to discover as an escaped defect later.

Full detail

QA in planning

QA is a participant in Planning & Estimation, so it enters the sprint already knowing the committed stories and their acceptance criteria. This is what makes parallel test design possible: QA does not wait for a build to start thinking about coverage.

Authoring the test plan

After planning, QA does two things in parallel with Development:

  1. Impact analysis. QA assesses what each change touches, the same components/functional/technical lens used later in QA & Testing. This directs where new test cases are most needed.
  2. The JIRA test plan ticket. QA creates a dedicated test plan ticket for the sprint and records its test cases there, categorized (for example by feature, by suite, or by component). This ticket is the living artifact that is approved here, executed in QA & Testing, and linked in the release go-ahead.

Existing cases are reused where they still apply. Where a story adds functionality that current cases do not cover, QA writes new test cases for it. Authoring happens while Development is building the feature or fixing the bug, so the two streams progress together rather than in sequence.

The Internal Test Case Review (ITCR)

When the cases for a feature are ready, QA holds the ITCR meeting.

  • Participants: QA (presents), the developer(s) who built or are building the feature (review), and Management (present).
  • What happens: QA presents the test plan and, for each new case, the rationale ("this path was not covered by existing cases, so I added these"). The developers confirm the coverage is right, or correct it: pointing out a path QA missed and asking for a new case, or a scenario that needs a different assertion. They can equally confirm the set is complete as written.
  • Outcome: an agreed, complete set of cases. Any gaps the developers raise are written up as additional cases, which loops back through review until the set is agreed.

The developer approval gate

The review is not closed verbally. QA records the agreed cases on the JIRA test plan ticket and requests approval. The responsible developer comments on the ticket to approve it, confirming the cases will exercise the feature accurately and that the coverage is complete. That approval comment is the gate: it is what marks the test plan ready and what lets the work proceed to the build handoff. Without it, the plan is not yet approved.

Relationship to the rest of the lifecycle

flowchart TD
    A[Sprint planning: QA attends, learns scope] --> B[QA impact analysis + create JIRA test plan ticket]
    B --> C[Author and categorize cases; write new cases for uncovered functionality]
    C --> D[ITCR meeting: QA presents to Developers and Management]
    D --> E{Coverage complete?}
    E -->|gaps: add or revise cases| C
    E -->|complete| F[Developer approves the test plan on the JIRA ticket]
    F --> G[Approved test plan ready for QA & Testing execution]

Authoring (B and C) runs alongside Development; the build is not handed to QA until F is done.

Example

For v1.4.0, QA attends planning and sees the new CSV export story. After planning, QA creates the JIRA test plan ticket TEST-58, maps the existing order and checkout cases, and notes that the export-to-CSV path has no existing coverage. While the developer builds feature/ABC-1310, QA writes new cases for the export: empty result set, an account with exactly one order, a large export, and special characters in field values. QA then holds the ITCR with the developer and the Manager. The developer points out that the date columns depend on the client timezone, so QA adds two timezone cases. With the set agreed, the developer comments on TEST-58 approving the plan. That approved plan is what QA later executes against BUILD-58 and links in the release go-ahead.