Finding a defect is only half the job. A tester must also report it, track it, verify the fix and close it, while making sure the team understands how serious and how urgent it is. The defect life cycle (also called the bug life cycle) describes the journey of a defect from the moment it is logged until it is closed. Severity and priority, meanwhile, decide which defects get fixed first. Both topics appear in almost every manual testing interview.
Defect, Bug, Error and Failure
An error is a human mistake made by a developer or analyst. That mistake introduces a defect (or bug) in the code or document. When the defective code runs and produces a wrong result, the user sees a failure. Testers observe failures and report the underlying defects.
The Defect Life Cycle
The exact state names vary between tools and companies, but the standard flow is:
- New: the tester logs the defect with steps, evidence and severity.
- Assigned: the test lead or development lead reviews it and assigns it to a developer.
- Open: the developer starts analysing and working on the fix.
- Fixed: the developer changes the code, unit tests it and marks the defect fixed.
- Retest (Ready for QA): the fix is deployed to the test environment and the tester verifies it.
- Closed: the tester confirms the defect no longer occurs and nearby functionality still works.
- Reopened: if the issue still occurs during retest, the tester reopens it and it returns to the developer.
A defect can also leave the main path into these states:
| State | Meaning | Typical reason |
|---|---|---|
| Rejected / Not a Bug | The developer or lead says the behaviour is correct | Tester misread the requirement, or the behaviour is by design |
| Duplicate | The same defect is already logged | Two testers found the same issue |
| Deferred / Postponed | Valid defect, fix moved to a future release | Low impact, release deadline, risky fix |
| Cannot Reproduce | Developer cannot make it happen | Missing steps, environment-specific or intermittent issue |
Do not argue in comments. Re-read the requirement, attach evidence, and if you still believe it is a defect, discuss it with the business analyst or product owner. A calm, evidence-based approach builds your credibility with developers.
Severity vs Priority
Severity measures the impact of a defect on the system's functionality. It is a technical assessment and is usually set by the tester. Priority measures the urgency of fixing it, based on business needs, release dates and customer visibility. It is usually set by the product owner, project manager or lead, often during defect triage meetings.
| Aspect | Severity | Priority |
|---|---|---|
| Question it answers | How badly does it break the system? | How soon must it be fixed? |
| Driven by | Technical impact | Business impact and schedule |
| Usually set by | Tester | Product owner, PM or lead |
| Common levels | Critical (Blocker), Major, Minor, Trivial | P1 (Urgent), P2 (High), P3 (Medium), P4 (Low) |
| Can change? | Rarely, unless impact was misjudged | Often, as business needs shift |
Severity Levels Explained
- Critical: the application crashes, data is lost or a core flow is completely blocked with no workaround.
- Major: an important feature does not work correctly, but a workaround exists or the system still runs.
- Minor: a non-critical feature behaves incorrectly with little impact on users.
- Trivial: cosmetic issues such as spelling, spacing or colour inconsistencies.
The Severity-Priority Matrix
Because severity and priority are independent, every defect falls into one of four combinations. Interviewers love this question, so learn one solid example for each:
| Combination | Example | Why |
|---|---|---|
| High Severity, High Priority | On an e-commerce app, the UPI payment is debited from the customer's account but the order is not created | Core flow broken, money involved, every customer affected |
| High Severity, Low Priority | A banking app crashes when a user exports a 10-year account statement on an Android version used by under 0.5% of customers | A crash is severe, but very few users are affected and a workaround (shorter date range) exists |
| Low Severity, High Priority | The company name is misspelt on the home page of a train booking app just before a major launch | No functional impact, but highly visible and damages brand trust |
| Low Severity, Low Priority | Footer text on the FAQ page is misaligned by a few pixels on tablets | Cosmetic, rarely seen, no business impact |
In a triage meeting, the test lead, development lead and product owner review all new defects. The tester explains the impact (severity), the product owner decides the urgency (priority), and the team agrees on assignment or deferral. Attend these meetings whenever you can; they teach you how business decisions are made.
Retesting vs Regression After a Fix
When a defect reaches the Retest state, you first retest the exact failed scenario with the same steps and data. Then you run focused regression on related areas, because fixes often break neighbouring functionality. For example, a fix to the coupon calculation should trigger regression on cart total, GST display and the payment amount.
Close a defect only after verifying it on the correct build in the correct environment. Mention the build number in your closing comment, for example "Verified on build 2.4.1 (QA env), working as expected".
