Test Management Basics
You've written test cases. You've found bugs. But where do you put all of this? How do you track what's been tested, what hasn't, and what the results were? That's test management.
What Test Management Covers
- Test cases: Storing, organizing, and versioning your test cases
- Test execution: Tracking which tests have been run, passed, or failed
- Bug tracking: Logging defects, assigning them, and tracking resolution
- Reporting: Showing stakeholders the current state of quality
The Lightweight Approach
For small teams and personal projects, you don't need fancy tools. A spreadsheet can work:
| Test ID | Feature | Test Case | Status | Date | Notes |
|---|---|---|---|---|---|
| TC-001 | Login | Valid credentials → dashboard | Pass | Apr 1 | |
| TC-002 | Login | Empty password → error | Fail | Apr 1 | No error shown — BUG-003 |
| TC-003 | Login | SQL injection attempt | Pass | Apr 1 | Error handled correctly |
The key is consistency. Whatever system you use, track the same information every time.
Bug Tracking Essentials
Every team uses some form of bug tracker. The workflow is usually:
New → Assigned → In Progress → Fixed → Verified → Closed
↓
Reopened (if fix didn't work)
As a tester, you own the New (writing the report), Verified (confirming the fix), and potentially Reopened (if it's not actually fixed) steps.
What Makes a Good Bug Tracker Entry
Good entries are:
- Searchable. Use consistent titles so duplicates are easy to find
- Linkable. Reference related test cases, user stories, or other bugs
- Traceable. You can follow a bug from discovery through fix to verification
- Updatable. Add new information as you learn more (environment details, workarounds)
Test Reporting
At the end of a test cycle, you report results. Keep it simple:
- Total tests: How many test cases existed
- Executed: How many were actually run
- Pass/Fail/Blocked: Results breakdown
- Open bugs by severity: What's still broken
- Recommendation: Ship, hold, or test more
One clear dashboard beats a 20-page test report that nobody reads.
The key takeaway: The goal of test management isn't process — it's information. Can the team answer "what's the quality of this release?" at any moment?
Put these bug lifecycle states in the correct order.
At the end of a test cycle, which metric is MOST useful for making a ship/no-ship decision?
Open bugs by severity directly answers "what's still broken and how bad is it?" Total tests written or executed shows effort, not quality. Hours spent shows cost, not risk. The severity breakdown lets stakeholders make an informed risk-based release decision.
As a tester, which steps in the bug lifecycle do you own?
Click to reveal answer
Testers own New (writing the bug report), Verified (confirming the developer's fix actually works), and potentially Reopened (if the fix didn't resolve the issue). Developers own Assigned, In Progress, and Fixed.
Click to flip back