Test Execution and Defect Management
Test Execution and Defect Management is the operational core of testing: running cases from a controlled baseline, recording results honestly, and turning failures into actionable, trackable defects. CAST questions focus on the defect life cycle, the distinction between severity and priority, and the discipline that makes a defect report useful to a developer.
Execution discipline
- Execute against a known build and record version, environment, date, and tester.
- Give every case one status: pass, fail, blocked, or not run. Blocked is not failed.
- Investigate before logging: reproduce the failure, isolate the conditions, and confirm the expected result against the requirement.
Defect report essentials
A usable report includes an identifier, a specific title, build and environment, preconditions, numbered steps to reproduce, expected versus actual result, severity, priority, supporting logs or screenshots, reporter, and status. A good title is concrete: "Checkout total ignores 10% discount when cart exceeds $500", not "discount broken".
Life cycle and severity versus priority
Typical flow: new → assigned → open → fixed → retest → closed, with rejected, deferred, and duplicate as side paths. Severity is the impact on the system - a technical judgement. Priority is the urgency of the fix - a business judgement. They are independent. A misspelt company name on the login page is low severity but can be high priority before a launch.
Triage
Hold regular defect reviews with test, development, and business representation. Decide fix now, defer, or reject. A deferred defect needs a documented rationale and a target release, otherwise it silently becomes a production incident.
Worked example
A payment screen crashes when a user pays with an expired card. The crash reproduces in production but affects only about 2% of users.
Reasoning: severity is high because the system crashes and the payment path is broken. Priority is also high because payment failure damages revenue and trust. The low frequency informs priority - it does not lower severity, because severity measures impact when the defect occurs, not how often it occurs.
Traps that cost marks
- Setting priority equal to severity by default.
- Closing a defect because a developer says it is fixed, without a retest.
- Logging "it doesn't work" with no steps, expected result, or environment.
- Counting duplicates, rejected, and invalid reports as real defects in metrics.
- Leaving deferred defects without an owner or target release.