Skip to content
Trevin Nimaladasa

TEMPLATESJIRA · TC

Test Case

A specific verification with preconditions, test data, steps, expected results and evidence.

Paste the blank into the ticket description and overwrite the [brackets].

  1. 01Summary

    Say exactly what's being verified, in one line. "Password reset" is a topic. "Password reset succeeds via email link" is a test.

    [Behaviour] [succeeds / fails / is blocked] [when / via]

    Example

    Password reset succeeds via email link

  2. 02Related Work

    Link what this test proves, so a failure points to something. Name the environments it should run in.

    - Jira issue / user story: [key]
- Requirement / epic: [key]
- Environment(s): [DEV / UAT / PROD]

    Example

    • Jira issue / user story: US-318
    • Requirement / epic: REQ-212, EPIC-41
    • Environment(s): UAT

  3. 03Preconditions

    State what must already be true before step 1. If someone can't get into that state, they can't run the test.

    - [State of the system or account]

    Example

    • A customer account exists with a verified email
    • The customer is signed out
    • The email service is running in UAT

  4. 04Test Data

    Name the accounts, roles and data used, so anyone can reproduce your result. Never put real credentials or personal data here.

    - Accounts / roles: [which]
- Data setup: [what to create or load]

    Example

  5. 05Steps

    One action per step, written as an instruction. Someone who's never seen the system should follow them without guessing.

    1. [Action]
2. [Action]
3. [Action]

    Example

    1. Open the app and tap "Forgot password".
    2. Enter uat.customer1@example.test and tap "Send link".
    3. Open the email and tap the reset link.
    4. Enter a new password that meets policy and tap "Save".

  6. 06Expected Results

    Match each result to a step number. State what you'd see or what changes, never "works correctly".

    1. [Result after step 1]
2. [Result after step 2]
3. [Result after step 3]

    Example

    1. The reset screen opens.
    2. A confirmation message appears and an email arrives within 60 seconds.
    3. The app opens on the new-password screen.
    4. The customer is signed in and the old password no longer works.

  7. 07Actual Results

    Fill this in when you run the test. Say what happened step by step, and where it differed.

    - Run on [date] by [name]: [what happened]

    Example

    • Run on 12 Nov by Priya: steps 1 to 3 as expected. Step 4: signed in, but old password still accepted for 2 minutes (see BUG-241).

  8. 08Evidence

    Link proof that someone else can open. Recordings and logs are better than a statement that it passed.

    - [Screenshot / video / log link]

    Example

    • Screen recording: UAT-118-run2.mp4
    • Server log extract attached

  9. 09Pass / Fail Criteria

    Say what counts as a pass. Be clear about what blocks it, such as any defect above a given severity.

    - Pass when [condition]. Fail if [condition].

    Example

    • Pass when all four results occur and no Critical or Major defect is raised. Fail if any step differs or the old password still works.

  10. 10Notes

    Anything that helps the next person: known flakiness, setup quirks, what to do next time.

    - [Note]

    Example

    • Reset emails can take up to 90 seconds in UAT after a deploy.

  11. 11Definition of Done (DoD)

    A test is done when it ran, was recorded, and any failure has an owner. Adjust to your sign-off needs.

    - [ ] Test executed in the agreed environment(s).
- [ ] Results recorded and evidence attached or linked.
- [ ] Any defects raised and linked (if failures).
- [ ] Stakeholder sign-off captured when required.

    Example

    • Executed in UAT on 12 Nov.
    • Result and recording attached.
    • BUG-241 raised and linked.
    • Sign-off not required for this test.