Survival Kit Content:
1. Bug Report Template Title: “Because ‘It doesn’t work’ isn’t enough.”
➡️ A clean bug report format with space for steps, expected vs actual, and attachments.
2. Test Case Template Title: “When you want to prove you actually tested something.”
➡️ Standard fields (ID, preconditions, steps, expected result) with examples.
3. Regression Checklist Title: “Catching bugs that tried to sneak back in like ninjas.”
➡️ A checklist of critical areas to retest before every release.
4. Exploratory Testing Notes Sheet Title: “For when you’re Sherlock Holmes with a browser.”
➡️ Structured notes for charters, observations, and oddities you spot.
5. Defect Reproduction Steps Sheet Title: “Making bugs reproducible since developers don’t believe in ghosts.”
➡️ A guide to write clear, repeatable reproduction steps (so devs can’t escape).
6. Test Data Table Title: “Because random123 isn’t test data.”
➡️ A simple table to document test inputs, variations, and expected outputs.
7. Release Readiness Checklist Title: “Before we ship it and regret it.”
➡️ Checklist for final checks (features, integrations, performance, rollback plan).
8. QA–Dev–BA Clarification Notes Sheet Title: “Lost in translation: requirements edition.”
➡️ A template to document questions + answers between roles, avoiding endless pings.
9. Ticket with No Description Clarification Template Title: “BA forgot, but QA never does.”
➡️ Ready-to-use polite message for asking missing requirements.
10. “Works on My Machine” Bug Template Title: “For bugs that only appear when you touch them.”
➡️ A doc to capture environment, system info, and proof that “my machine” isn’t the real world.
Hey fellow QA, tester, bug hunter, requirement whisperer (or accidental mind reader). Welcome to The QA Survival Kit! This little pack was born from my daily adventures as a QA who:
- Gets tickets with no description,
- Hears “Works on my machine” more often than “Good morning,”
- And occasionally feels like Sherlock Holmes with a browser.
Inside you’ll find 10 practical templates — bug reports, test cases, checklists, notes, even a polite-but-sarcastic way to ask a BA “What exactly am I testing here?”. Use them, copy them, laugh at them, customize them. They’re here to save your time, save your sanity, and maybe even save your dev from another late-night ping.
Now let’s jump in — because those bugs won’t log themselves.
1. Bug Report Template
Because “It doesn’t work” isn’t enough.
Fields to Fill In
| Field | Example / Instruction |
|---|---|
| ID | BUG-001 |
| Title / Summary |
Login button does nothing (unlike me, it just stares back) |
| Environment | Chrome 120, Windows 10 |
| Preconditions | User account exists |
| Steps to Reproduce |
1. Open login page |
| Expected Result | User is logged in and redirected to the dashboard |
| Actual Result | Nothing happens. Button mocks user silently |
| Severity High | (can’t log in = can’t test = can’t blame dev) |
| Priority | P1 – Fix before product launch, or users will riot |
| Attachments | Screenshot, console logs, screen recording |
Extra Examples for Template #1 (Bug Report)
Example 2
● Title: Search returns unrelated results (I searched “shoes,” got “sofas”)
● Steps:
- Go to search bar
- Enter “shoes”
- Hit Enter
● Expected: Only products related to shoes
● Actual: Random items like sofas, tables, blender appear
● Severity: Medium
● Priority: High (unless client sells sofas disguised as shoes
Example 3
● Title: “Add to Cart” button throws 500 error
● Steps:
- Open product page
- Click Add to Cart
● Expected: Item is added to cart
● Actual: 500 Internal Server Error (backend panic attack)
● Severity: Critical
● Priority: P0 (because no cart = no $$$)
Pro Tips (QA Wisdom)
✅ Avoid vague titles like “App broken” — give devs something they can actually find.
✅ Screenshots are nice, but a short video saves 5 Slack messages.
✅ Write steps so even a sleepy Monday-morning dev can follow.
Golden Rule: Never write “It doesn’t work.” Unless you want a reply: “Works on my machine.”
Extra Examples:
1. Dropdown menu overlaps footer → screenshot attached.
2. Mobile checkout crashes on Place Order → crash log attached.
2. Test Case Template
When you want to prove you actually tested something and because testing without a plan is just guessing.
Fields to Fill In
| Field | Example / Instruction |
|---|---|
| Test Case | ID TC-001 |
| Title / Summary |
Verify user can log in with valid credentials |
| Module / Feature | Login Page |
| Preconditions | User account exists, browser opened |
| Test Steps |
1. Navigate to login page |
| Expected Result |
User is successfully logged in and redirected to the dashboard |
| Actual Result | (Leave blank until execution) |
| Status | Pass / Fail / Blocked |
| Test Data | user@example.com / Password123 |
| Notes | Add screenshots, logs, or funny observations |
Extra Examples for Template #2
Example 2
● Test Case ID: TC-002
● Title: Verify login with an invalid password
● Steps: Enter a valid email + wrong password → click Login
● Expected Result: Error message “Invalid credentials” displayed
● Status: Pass/Fail after execution
Example 3
● Test Case ID: TC-003
● Title: Verify password reset via email
● Steps:
- Click “Forgot Password”
- Enter registered email
- Click submit
● Expected Result: Password reset link sent to email
● Status: Pass/Fail after execution
Pro Tips (QA Wisdom)
✅ Keep test steps atomic — one action per line (no novels).
✅ Expected result should be measurable, not “looks fine.”
✅ Status “Blocked” = Dev owes you a coffee.
Golden Rule: If a dev asks “Did you test it?”, just send them the Test Case ID. Instant silence.
Extra Examples:
Update profile picture → verify new image displayed correctly
3. Regression Checklist
“Catching bugs that tried to sneak back in like ninjas.”
Regression Checklist (Before Every Release)
● Login – valid, invalid, empty inputs
● Navigation menus – no teleporting to wrong pages
● Forms – submit, reset, cancel, validation messages
● API responses – correct status codes (no 500 surprise parties)
● UI layout – buttons/labels not overlapping like Romeo & Juliet
● Email/Notifications – sent when triggered, not when bored
● File Upload/Download – works with correct formats
● Search/Filters – return correct results (no black holes)
● Payment/Checkout – successful and error flows
● Performance – loading times are reasonable (no infinite spinners)
● Critical workflows – end-to-end happy paths still work
Pro Tips (QA Wisdom)
✅ Prioritize high-risk, business-critical flows.
✅ Automate regression if possible (or at least automate your coffee supply).
✅ Keep the checklist updated after each sprint.
Golden Rule: Regression testing is like déjà vu — but necessary.
Extra Examples:
- Web App – all core flows green, rollback plan defined.
- Mobile App – smoke tests passed, push notifications verified.
4. Exploratory Testing Notes Sheet
Because sometimes testing feels like detective work, or for when you’re Sherlock Holmes with a browser.
Fields to Fill In
| Field | Example / Instruction |
|---|---|
| Charter ID | EXP-001 |
| Charter / Mission |
Explore checkout flow with invalid coupons |
| Environment | Chrome 122, Windows 11 |
| Observations |
1. Coupon “FREE100” applied twice → discount > 100%. |
| Oddities |
The checkout button is still active even when the total = 0 |
| Notes / Next Steps | Log defect, retest after fix, try on mobile |
Pro Tips (QA Wisdom)
✅ Exploratory = structured curiosity. You’re not just clicking randomly.
✅ Always write oddities — today’s “funny quirk” becomes tomorrow’s P1 bug.
Golden Rule: If you can’t explain what you explored, you didn’t really explore.
Extra Examples:
1. Explore profile settings → Employee can see Admin actions.
2. Explore notifications → Some emails trigger multiple times.
5. Defect Reproduction Steps Sheet
Making bugs reproducible since developers don’t believe in ghosts.
Fields to Fill In
| Field | Example / Instruction |
|---|---|
| Defect ID | DEF-045 |
| Title |
App crashes with 50+ items in cart |
| Environment | iOS 17, Safari |
| Preconditions |
User logged in |
| Steps to Reproduce |
1. Add 50+ “Product A” to cart |
| Expected Result | The cart displays all items |
| Actual Result | White screen crash |
| Attachments | Screenshot, crash log |
| Reproducibility | 100% (QA magic) |
Pro Tips (QA Wisdom)
✅ Be precise — “sometimes” is not a repro step.
✅ Attach proof (logs/screenshots) so devs don’t call it a ghost bug.
Golden Rule: If it’s not reproducible, it’s not a bug… it’s a legend.
Extra Examples:
1. User not redirected after login → happens only on Firefox.
2. Image upload fails with 500 error → reproducible in Ubuntu.
6. Test Data Table
Because random123 isn’t test data.
Fields to Fill In
| Input Field | Test Data | Variation | Expected Output |
|---|---|---|---|
| user@test.com | valid | Login success | |
| user#test.com | invalid format | Error message | |
| Password | Pass123! | valid | Login success |
| abc | too short | Error message |
Pro Tips (QA Wisdom)
✅ Cover both happy paths and silly-user paths.
✅ Keep a reusable dataset — saves hours of typing.
Golden Rule: Good test data is half the test.
Extra Examples:
1. Payment card types → success/fail scenarios.
2. Form inputs → boundary cases (empty, long, special chars).
7. Release Readiness Checklist
Before we ship it and regret it.
Checklist Fields
| Field | Example / Instruction |
|---|---|
| Build ID |
2.4.0-rc1 |
| Regression Passed | Yes / No |
| Critical Bugs |
Open? None (fingers crossed) |
| Performance Check |
Homepage loads < 3s |
| Rollback Plan | Documented & tested |
| Sign-Off | QA, Dev, PM all approved |
Pro Tips (QA Wisdom)
✅ Never release on Friday (unless you enjoy weekend support).
✅ Always confirm rollback actually works — not just in theory.
Golden Rule: If you can’t sleep after the release, you weren’t ready.
Extra Examples:
1. Web App – all core flows green, rollback plan defined.
2. Mobile App – smoke tests passed, push notifications verified.
8. QA–Dev–BA Clarification Notes Sheet
Lost in translation: requirements edition.
Fields to Fill In
| Field | Example / Instruction |
|---|---|
| Ticket ID |
US-231 |
| Regression Passed | Yes / No |
| Question |
“Should guests be able to check out without creating an account?” |
| Asked To |
BA |
| Answer | “Yes, but only with a credit card.” |
| Status | Updated in requirements v1.3 |
Pro Tips (QA Wisdom)
✅ Document every clarification — memory is not a requirement system.
✅ Keep answers visible to the whole team, not buried in Slack.
Golden Rule: If it’s not written down, it will be forgotten (or denied).
Extra Examples:
1. QA → Dev: Why API returns 200 on a wrong password?
2. QA → BA: Should the discount code work after expiry?
9. Ticket with No Description Clarification Template
BA forgot, but QA never does.
Message Template
“Hi [BA/Dev], thanks for the ticket. Currently, it has no description or acceptance criteria.
Could you clarify what’s expected? Otherwise, I’ll assume the feature is supposed to make coffee
— and I’ll log it as a bug if it doesn’t. ☕”
Pro Tips (QA Wisdom)
✅ Stay polite, even if the ticket screams chaos.
✅ Clarify ASAP — bad tickets waste the most time.
Golden Rule: Garbage in = garbage out.
Extra Examples:
1. “Ticket empty, QA wonders if we’re designing Hogwarts app?”
2. “No details, so I’ll pretend it’s urgent… and log appropriately.”
10. “Works on My Machine” Bug Template
For bugs that only appear when you touch them.
Fields to Fill In
| Field | Example / Instruction |
|---|---|
| Bug ID | BUG-404 |
| Title |
Image upload fails on Firefox |
| QA Environment | Ubuntu, Firefox 113 |
| Dev Environment |
macOS, Chrome 122 |
| Steps to Reproduce |
1. Go to the upload page |
| Expected Result | File uploads successfully |
| Actual Result | 500 error |
| Evidence | Console log + HAR file |
Pro Tips (QA Wisdom)
✅ Specify the environment to kill the “works here” excuse.
✅ Logs > screenshots when proving reality.
Golden Rule: If it only works on your laptop, ship your laptop.
Extra Examples:
1. Search returns empty → only Firefox issue.
2. Payment fails → reproducible only on Ubuntu.
Bonus: QA Humor Bingo
Survival Edition
Instructions: Every time you hear one of these “greatest hits” in a stand-up, meeting, or Slack chat, mark it off. Five in a row instant QA legend status (or maybe just emotional damage).
⚠️ Warning: May cause uncontrollable eye-rolling, spontaneous sarcasm, or the urge to switch careers. Play responsibly.
You’ve reached the end of The QA Survival Kit.
If you liked it, keep an eye out for my next pack: “QA Communication Survival Guide – How to Talk to Devs Without Crying.”
Oh, and one last pro tip: Always double-check before hitting “Submit”… unless you’re a dev.
See you in the next release!
