Severity, priority, the bug life cycle and writing a good bug report
How to rate defects, how a bug moves from New to Closed, which test types to run when, and what a useful bug report contains.
Finding a defect is only half the job. The other half is describing and rating it so the team can fix the right things first.
Severity and priority
Severity is the technical impact on the system. Priority is how soon the business needs it fixed. Testers usually suggest severity; priority is often set with the product owner or lead. The two do not always match:
- Misspelled company name on the home page: low severity, high priority.
- Crash in a rarely used export with a workaround: high severity, low priority.
- Payment fails for all users: high severity, high priority.
The bug life cycle
Names vary by tool, but a common flow is:
- New: logged by the tester.
- Assigned: given to a developer.
- Open / In progress: being worked on.
- Fixed: developer has made a change.
- Retest: tester checks the fix.
- Closed if it works, or Reopened if it does not.
Side statuses include Rejected (not a bug, or cannot be reproduced), Duplicate and Deferred (fix planned for a later release).
Which testing to run when
- Smoke: a quick, broad check that a new build is stable enough to test.
- Sanity: a narrow check of one area after a small change.
- Retesting: confirming a specific bug is fixed.
- Regression: re-running existing tests to make sure the change broke nothing else.
Writing a bug report developers can use
Title: Checkout - Pay now does nothing when card
expiry month is the current month
Environment: Build 2.3.1, Chrome on Windows, test server
Steps:
1. Add any item to cart and go to checkout
2. Enter a test card with expiry set to this month
3. Click Pay now
Expected: payment processed, confirmation page shown
Actual: button does nothing, no error message
Severity: High Attachments: screen recordingReport one defect per bug, state facts rather than opinions, and check that someone else can reproduce it from your steps alone.
Checklist before you submit: clear title, environment, numbered steps, expected versus actual result, evidence attached, and a search to make sure it is not a duplicate.
More in Software testing