QA Handbook · Bug Reporting & Defect Lifecycle
Bug Reporting & Defect Lifecycle
How to describe a defect clearly, decide what information matters, move it through a team workflow and communicate unresolved risk.
Statuses and ownership vary between organisations. The workflow and examples here are common patterns, not mandatory Jira rules or a record of a real production incident.
Report and manage a defect
A good defect report shortens the path from observation to a shared decision.
Error, Defect and Failure
Use the terms consistently so the team can discuss cause, work product and observed behaviour separately.
What to include
- Error: a human action or decision that produces an incorrect result, such as misunderstanding a session requirement.
- Defect / bug: a flaw in a work product, such as code or a requirement, that may cause incorrect behaviour.
- Failure: the observable event when the system does not deliver an expected result in operation.
QA Engineer’s tips
- Example: a developer forgets to revoke a session (error), the missing revocation logic is a defect, and the protected page loads after logout (failure).
- A failure can have several possible causes; report evidence before assigning blame.
Example · Secure User Logout
Secure User Logout · terminology
| Term | Example |
|---|---|
| Error | A session-revocation condition was missed during implementation. |
| Defect | The server accepts a revoked session token. |
| Failure | A user can open the protected account page after logout. |
Common mistake Calling every failed test a bug before checking the test, data and environment.
Write a Professional Bug Report
Provide enough context for another person to reproduce, understand impact and decide what to do next.
What to include
- Bug ID, clear summary, description, environment, preconditions and application version or build.
- Numbered reproduction steps, expected result, actual result, severity, priority and reproducibility.
- Evidence or attachments such as screenshots, video, logs, traces or sanitised request/response data.
QA Engineer’s tips
- Use a title that states the wrong behaviour and affected area.
- Redact tokens, passwords, personal data and secrets before attaching evidence.
Example · Secure User Logout
Illustrative Jira-style example · not a real production incident
- Bug ID
- BUG-LOGOUT-002
- Summary
- Protected account page remains accessible after successful logout
- Description
- After a user logs out, the browser is redirected to sign-in but a direct request to the protected account page still returns the account content.
- Environment
- QA / Staging · web build 1.4.1 · Chromium 128 · Authentication API 1.4.1
- Preconditions
- Synthetic user is signed in and has an active session; account page is available.
- Steps
- 1. Sign in. 2. Open /account. 3. Select Log out. 4. Navigate directly to /account.
- Expected
- The old session is rejected and the user is redirected to sign-in; protected content is not returned.
- Actual
- The sign-in page is shown after logout, but /account loads protected content without asking the user to sign in again.
- Severity / Priority
- High severity / High priority proposed because protected data remains accessible; final business priority is agreed during triage.
- Reproducibility
- 5/5 attempts on the recorded build.
- Evidence
- Sanitised video and network log attached; no real credentials or tokens included.
Common mistake Writing “logout is broken” without a build, steps, expected result or evidence.
Follow the Defect Lifecycle
Move the issue through visible states so ownership, work and verification are clear.
What to include
- Common flow: New / Open → Assigned / In Progress → Fixed / Ready for QA → Retest → Closed.
- Alternative outcomes: Reopened, Duplicate, Cannot Reproduce, Rejected / Won’t Fix and Deferred.
- Use the organisation’s actual status names and transition rules.
QA Engineer’s tips
- A defect can move backward when a retest fails; that is useful information, not process failure.
- Record why an alternative outcome was chosen and link the evidence or duplicate.
Example · Secure User Logout
BUG-LOGOUT-002 · example flow
- New: QA reports the protected-page failure with evidence.
- Assigned / In Progress: the team confirms ownership and investigates session invalidation.
- Fixed / Ready for QA: a candidate build is deployed.
- Retest: QA repeats the original steps.
- Closed: the fix is confirmed and related regression passes; otherwise the defect is Reopened.
Common mistake Treating “Fixed” as proof that the user-visible problem is solved.
Separate Severity from Priority
Describe impact and business urgency separately so the team can make a transparent decision.
What to include
- Severity describes the effect on users, data, security or system operation.
- Priority describes how urgently the organisation wants the work addressed.
- QA often proposes severity from evidence; the Product Owner, business stakeholders or agreed triage group typically determines priority, depending on the organisation.
QA Engineer’s tips
- Critical severity / High priority: an authentication defect exposes protected customer data before release.
- High severity / Low priority: a serious issue affects a rare, retired browser on a product with no current users there.
- Low severity / High priority: a small wording error appears on a launch campaign page.
- Low severity / Low priority: a minor spacing issue in an internal, rarely used screen.
Example · Secure User Logout
| Severity | Priority | Example |
|---|---|---|
| Critical | High | Protected data is exposed after logout; fix before release. |
| High | Low | A serious failure affects a browser the product no longer supports. |
| Low | High | A visible launch-page typo needs correction before a campaign. |
| Low | Low | Minor spacing issue in a low-use internal tool. |
Common mistake Using severity and priority as synonyms, or assuming QA alone owns the business priority.
Triage the Finding
Use a short, evidence-based discussion to decide whether the issue is valid, duplicated, urgent, owned and ready for action.
What to include
- Check for duplicate reports and compare versions, environments and reproduction steps.
- Attempt reproduction with the original data or an equivalent safe setup.
- Discuss impact, scope, severity, priority, owner, target build and release risk.
QA Engineer’s tips
- Invite the developer, QA, Product Owner and other relevant roles; not every issue needs a large meeting.
- If the issue is not reproducible, document what was tried and keep the report open or move it to the agreed status rather than guessing.
Example · Secure User Logout
Triage questions for BUG-LOGOUT-002
- Can the issue be reproduced on the recorded build and environment?
- Does the API also accept the old session, or is the problem only cached UI content?
- Is this a duplicate of BUG-LOGOUT-001 or a separate page-level failure?
- What release risk remains if the fix is deferred?
Common mistake Changing a report to “Cannot Reproduce” after one attempt without recording conditions.
Retest, Reopen or Close
Use confirmation testing to check the fix, then use regression testing to look for unintended effects.
What to include
- Retest: rerun the failed case with the original steps, data and a new build.
- Regression testing: select related checks based on the code or risk impact, not only the original case.
- Reopen when the original failure remains, the fix is incomplete or a related acceptance criterion still fails; close when agreed evidence supports resolution.
QA Engineer’s tips
- Ask the developer what changed to guide regression selection.
- Do not close a defect because the status says Ready for QA; close after evidence is reviewed.
Example · Secure User Logout
| Retest / confirmation | Regression testing | |
|---|---|---|
| Goal | Show that BUG-LOGOUT-002 is fixed | Find unintended effects of the session change |
| Scope | Original protected-page steps | Logout, API, Back, tabs and error handling checks |
| Evidence | New build and result | Selected related results and remaining risks |
Common mistake Running a broad regression without first confirming the original failure, or closing without recording the result.
Report Unresolved Release Risk
When a defect remains open or testing is incomplete, explain the decision the team must make.
What to include
- State the defect, affected scope, current evidence and business impact.
- Name what is not covered, the proposed mitigation and the owner of the decision.
- Update the report and the release or QA status when new evidence arrives.
QA Engineer’s tips
- Use respectful language: focus on behaviour and risk, not the person who wrote the code.
- A QA Engineer recommends based on evidence; the agreed release owner decides whether to accept or defer risk.
Example · Secure User Logout
Example message: “BUG-LOGOUT-002 is still reproducible on build 1.4.1 in QA. Protected page content is available after logout in 5/5 attempts. Confirmation is blocked until build 1.4.2 is deployed. I recommend holding release of the authentication change; the Product Owner and Engineering Lead should decide whether any exception is acceptable.”
Common mistake Reporting only “not fixed” without saying impact, evidence, next action or decision owner.
Bug reporting reference
Bug reporting checklist
- Unique ID and a concise summary.
- Description, version / build, environment and preconditions.
- Numbered steps, expected result and actual result.
- Severity, proposed priority and reproducibility.
- Sanitised evidence and links to the story, test case and related defects.
- Current status, owner, next action and release risk.
Sample communication with a developer
“I reproduced BUG-LOGOUT-002 five times on build 1.4.1 in QA. The UI redirects to sign-in, but a direct request to /account still returns protected content. The attached video and sanitised network log show the result. Could we review whether the server is still accepting the session, and let me know when the candidate fix is ready for retest?”
Common mistakes
- Vague titles such as “login issue”.
- Missing build or environment details.
- Steps that combine several actions or rely on hidden setup.
- Screenshots without the actual result or useful context.
- Exposing credentials or personal data in evidence.
- Treating a duplicate, rejected or deferred result as if it meant the observation never happened.
Related topics: Test Execution · Test Case · Test Scenarios · STLC · Agile & Scrum · Glossary.