👑 Trusted by 50,000+ QA Professionals💎 Premium Access AvailableUnlock 100+ QA Jobs
Templates
Test Case, Bug Report, Test Plan & RTM Templates (with Real Examples)
Ready-to-use QA templates with filled examples — 32 sample test cases for login, cart and payment, a bug report template, a test plan, an RTM and a test summary report. Copy into Excel, JIRA or Zephyr.
Interviewers often ask freshers to “write test cases for a login page” or “show how you report a bug”. On the job, the same documents — test cases, bug reports, test plans and traceability matrices — are what your lead reviews every sprint.
This page gives you professional templates with filled examples you can copy straight into Excel, Google Sheets, JIRA, Zephyr or TestRail. Tap Download PDF to keep a copy.
FREEDaily Free QA JobsFresh manual, automation, API & remote QA openings shared every morning.View today’s free jobs →PREMIUMUnlock 100+ Verified QA Jobs DailyPremium members get every daily opening along with HR contact details.See premium plans →
Test scenario vs test case
A test scenario is a one-line description of what to test (“Verify login with valid credentials”). A test case is the detailed, repeatable version with preconditions, steps, data and expected result. One scenario usually has several test cases (positive, negative and boundary).
Standard test case template
| Field | What to write |
|---|---|
| Test Case ID | Unique id, e.g. TC_LOGIN_001 |
| Module / Feature | Login, Cart, Payment… |
| Requirement / Story ID | JIRA story or requirement it covers (for traceability) |
| Test Scenario | One-line objective |
| Preconditions | What must be true before you start (user registered, item in stock) |
| Test Steps | Numbered, one action per step |
| Test Data | Exact inputs used |
| Expected Result | What should happen — measurable and specific |
| Actual Result | What happened (filled during execution) |
| Status | Pass / Fail / Blocked / Not Run |
| Priority | High / Medium / Low |
| Type | Positive, Negative, Boundary, UI, Security… |
| Executed by / Date / Build | Who ran it, when and on which build |
| Remarks / Bug ID | Linked defect if failed |
🚀 Practised the templates? Apply to fresh QA jobs
QA Jobs India shares 100+ fresh QA & software testing openings every morning — manual, automation, API and remote roles.
See today’s QA jobs →Sample test cases: Login page (12)
| ID | Scenario | Steps | Test data | Expected result | Priority |
|---|---|---|---|---|---|
| TC_LOGIN_001 | Valid login | 1. Open login page 2. Enter email and password 3. Click Login | qa.user@test.com / Valid@123 | User lands on dashboard; name shown in header | High |
| TC_LOGIN_002 | Wrong password | Enter valid email, wrong password, click Login | qa.user@test.com / Wrong@1 | “Invalid email or password” shown; user stays on login page | High |
| TC_LOGIN_003 | Unregistered email | Enter unregistered email and any password | nouser@test.com | Same generic error (no hint that email does not exist) | High |
| TC_LOGIN_004 | Empty fields | Click Login with both fields empty | — | Required-field messages for email and password; no request sent | Medium |
| TC_LOGIN_005 | Invalid email format | Enter email without @ | qa.usertest.com | “Enter a valid email” validation | Medium |
| TC_LOGIN_006 | Password masking | Type password | Valid@123 | Characters masked; eye icon toggles visibility | Low |
| TC_LOGIN_007 | Account lock | Enter wrong password 5 times | Wrong@1 ×5 | Account locked for 15 min with clear message (as per rule) | High |
| TC_LOGIN_008 | Remember me | Login with “Remember me”, close and reopen browser | Valid user | User still logged in until session expiry | Medium |
| TC_LOGIN_009 | Logout and back button | Login, logout, press browser Back | Valid user | Dashboard not shown; redirected to login | High |
| TC_LOGIN_010 | SQL injection | Enter ' OR '1'='1 in email | Injection string | Login fails safely; no DB error shown | High |
| TC_LOGIN_011 | Leading/trailing spaces | Enter email with spaces around it | “ qa.user@test.com ” | Spaces trimmed (or clear validation), per requirement | Low |
| TC_LOGIN_012 | Forgot password link | Click “Forgot password?” | — | Reset page opens; reset email sent to registered address | Medium |
Sample test cases: Shopping cart (10)
| ID | Scenario | Expected result | Priority |
|---|---|---|---|
| TC_CART_001 | Add an in-stock item | Item added, cart badge count increases by 1, success message shown | High |
| TC_CART_002 | Add same item twice | Quantity becomes 2 (not two separate lines) | High |
| TC_CART_003 | Update quantity | Line total and cart total recalculate correctly | High |
| TC_CART_004 | Quantity 0 or negative | Not allowed; item removed at 0 or validation shown | Medium |
| TC_CART_005 | Maximum quantity limit | Cannot exceed stock / max-per-order; clear message | Medium |
| TC_CART_006 | Remove item | Item removed; totals update; empty-cart message when last item removed | High |
| TC_CART_007 | Out-of-stock item in cart | Warning shown; checkout blocked for that item | High |
| TC_CART_008 | Apply valid coupon | Discount applied once; total correct; coupon shown | High |
| TC_CART_009 | Invalid / expired coupon | Error message; total unchanged | Medium |
| TC_CART_010 | Cart persistence | Guest cart merges with account cart after login; cart kept after logout/login | Medium |
Sample test cases: Payment (10)
| ID | Scenario | Expected result | Priority |
|---|---|---|---|
| TC_PAY_001 | Successful card payment | Order placed, payment status “Paid”, confirmation page and email/SMS | High |
| TC_PAY_002 | Successful UPI payment | UPI app/collect request flow works; order confirmed after success callback | High |
| TC_PAY_003 | Declined card | Clear failure message; order not placed; user can retry | High |
| TC_PAY_004 | User cancels on gateway page | Returns to checkout with “Payment cancelled”; cart intact | High |
| TC_PAY_005 | Network drop after payment | No double charge; order status reconciled via webhook; user sees correct status | High |
| TC_PAY_006 | Double-click Pay button | Only one transaction created | High |
| TC_PAY_007 | Amount check | Gateway amount = cart total incl. tax, shipping and discount | High |
| TC_PAY_008 | Refund on cancellation | Refund initiated to source; status and timeline shown | Medium |
| TC_PAY_009 | Sensitive data | Card number masked; CVV never stored or logged; HTTPS only | High |
| TC_PAY_010 | Session timeout on payment page | User asked to log in again; no partial order left | Medium |
Tip for interviews: when asked to write test cases, first ask 2–3 clarifying questions (allowed payment methods, lock rules, supported browsers), then cover positive, negative, boundary, UI, security and performance angles. Interviewers value structured thinking more than a long list.
Bug report template
Bug ID: BUG-1234 (auto in JIRA)
Title: [Module] What is wrong + where (short and specific)
Environment: QA / Staging · Build 2.4.1 · Chrome 129 · Windows 11 (or device + OS version)
Severity: Critical / Major / Minor / Trivial Priority: P1 / P2 / P3
Preconditions: …
Steps to reproduce: 1. … 2. … 3. …
Test data: …
Expected result: …
Actual result: …
Frequency: Always / Intermittent (3 of 5 tries)
Attachments: screenshot, screen recording, console/network logs, API request & response
Linked story / test case: STORY-210 / TC_PAY_007
Title: [Module] What is wrong + where (short and specific)
Environment: QA / Staging · Build 2.4.1 · Chrome 129 · Windows 11 (or device + OS version)
Severity: Critical / Major / Minor / Trivial Priority: P1 / P2 / P3
Preconditions: …
Steps to reproduce: 1. … 2. … 3. …
Test data: …
Expected result: …
Actual result: …
Frequency: Always / Intermittent (3 of 5 tries)
Attachments: screenshot, screen recording, console/network logs, API request & response
Linked story / test case: STORY-210 / TC_PAY_007
Filled example
Title: [Checkout] Order total ignores coupon discount when shipping is free
Environment: Staging · Build 2.4.1 · Chrome 129 / Android 14 app 5.2.0
Severity: Major Priority: P1
Preconditions: User logged in; coupon SAVE10 active (10% off); cart value above ₹999 (free shipping)
Steps: 1. Add “Wireless Mouse” (₹1,200) to cart 2. Apply coupon SAVE10 3. Proceed to payment
Expected: Payable amount ₹1,080 on cart and payment page
Actual: Cart shows ₹1,080 but the payment page charges ₹1,200
Frequency: Always
Attachments: video, network log showing
Environment: Staging · Build 2.4.1 · Chrome 129 / Android 14 app 5.2.0
Severity: Major Priority: P1
Preconditions: User logged in; coupon SAVE10 active (10% off); cart value above ₹999 (free shipping)
Steps: 1. Add “Wireless Mouse” (₹1,200) to cart 2. Apply coupon SAVE10 3. Proceed to payment
Expected: Payable amount ₹1,080 on cart and payment page
Actual: Cart shows ₹1,080 but the payment page charges ₹1,200
Frequency: Always
Attachments: video, network log showing
/api/checkout response "discount": 0- Severity = impact on the product (set by QA). Priority = how soon to fix (set by PO/lead).
- One bug per report; never combine issues.
- Write the title so a developer understands it without opening the ticket.
- Always attach evidence — a 20-second video saves 20 minutes of discussion.
Test plan template
| Section | What to include (example) |
|---|---|
| 1. Introduction / Objective | Purpose of testing for release 2.4 — new UPI payment and coupon engine |
| 2. Scope — in scope | Cart, coupons, UPI and card payments, order confirmation, refunds (web + Android) |
| 3. Scope — out of scope | iOS app, admin panel, load testing beyond 500 users |
| 4. Test approach | Functional, regression (automated Selenium/Playwright suite), API (Postman/REST Assured), exploratory, cross-browser, basic security |
| 5. Test environment | Staging URL, test payment gateway sandbox, Chrome/Firefox/Edge latest, Android 12–14 devices, test DB |
| 6. Entry criteria | Stories meet DoR, build deployed to staging, smoke suite passes, test data ready |
| 7. Exit criteria | All High-priority cases executed, 95%+ pass rate, no open Critical/Major bugs, regression green |
| 8. Suspension / resumption | Suspend if smoke fails or environment is down for over 4 hours; resume on a fixed build |
| 9. Deliverables | Test cases, execution report, bug report, RTM, test summary report |
| 10. Schedule | Test design 6–8 Oct, execution 9–15 Oct, regression 16–17 Oct, sign-off 18 Oct |
| 11. Roles | QA lead: plan and sign-off; 2 QA engineers: execution; SDET: automation; PO: UAT |
| 12. Risks and mitigation | Gateway sandbox downtime → mock responses; late builds → risk-based prioritisation |
| 13. Tools | JIRA + Zephyr, Postman, Selenium/Playwright, Jenkins, BrowserStack |
| 14. Approvals | QA lead, Dev lead, Product owner |
Requirement Traceability Matrix (RTM) template
An RTM maps every requirement to its test cases, executions and defects, proving coverage and showing the impact of changes.
| Req / Story ID | Requirement | Test case IDs | Status | Defect IDs | Coverage |
|---|---|---|---|---|---|
| STORY-201 | User can log in with email and password | TC_LOGIN_001–009 | Pass | — | 100% |
| STORY-202 | Account locks after 5 failed attempts | TC_LOGIN_007 | Fail | BUG-1201 | 100% |
| STORY-210 | Coupon discount applies to cart and payment | TC_CART_008–009, TC_PAY_007 | Fail | BUG-1234 | 100% |
| STORY-215 | Pay using UPI | TC_PAY_002, 004, 005 | In progress | — | 67% |
| STORY-220 | Refund on cancellation | TC_PAY_008 | Not run | — | 0% |
Types: forward traceability (requirement → tests), backward (test → requirement) and bidirectional (both).
Test summary report template
Project / Release: ShopApp 2.4 · Test cycle: 9–17 Oct 2026
Builds tested: 2.4.0 → 2.4.3
Test cases: 420 planned · 412 executed · 398 passed · 10 failed · 4 blocked (96.6% pass)
Automation: 260 regression tests, 99% pass, 3 flaky tests fixed
Defects: 46 raised · 41 fixed & closed · 5 open (0 Critical, 1 Major, 4 Minor — all with workarounds)
Not tested / risks: iOS out of scope; UPI on Android 11 not covered due to device unavailability
Recommendation: Go for release, with known issues BUG-1250 and BUG-1262 listed in release notes
Sign-off: QA Lead · Dev Lead · Product Owner
Builds tested: 2.4.0 → 2.4.3
Test cases: 420 planned · 412 executed · 398 passed · 10 failed · 4 blocked (96.6% pass)
Automation: 260 regression tests, 99% pass, 3 flaky tests fixed
Defects: 46 raised · 41 fixed & closed · 5 open (0 Critical, 1 Major, 4 Minor — all with workarounds)
Not tested / risks: iOS out of scope; UPI on Android 11 not covered due to device unavailability
Recommendation: Go for release, with known issues BUG-1250 and BUG-1262 listed in release notes
Sign-off: QA Lead · Dev Lead · Product Owner
Next, practise writing these under time pressure with our manual testing interview questions.
FAQs
What is the best format for writing test cases?
Excel/Google Sheets for interviews and small teams; JIRA with Zephyr or Xray, or TestRail, in most companies. The fields stay the same.
How many test cases should I write for a login page?
In an interview, 10–15 well-chosen cases covering positive, negative, boundary, security and UI are better than 50 repetitive ones.
Who prepares the test plan?
Usually the QA lead or test manager, with input from testers, developers and the product owner. Testers should still understand every section.
Is an RTM still used in Agile?
Yes, often generated automatically from JIRA links between stories, test cases and bugs (Zephyr/Xray traceability reports).
📚 More QA interview question banks
Selenium (60) · Playwright (50) · Manual Testing (60) · API Testing (50) · SQL for Testers (50) · Mobile / Appium (50) · JIRA & Agile (50) — open the all-in-one QA Study Material hub →
💎 Get every QA opening, every day
Join QA Jobs India Premium for 100+ verified QA jobs daily with HR contact details.
