Writing a Defect Report: Severity and Priority

Three habits make the difference between a report that is fixed and one that bounces back.

• Make the steps the smallest that still fail. Chapter Forty-Seven, on debugging, reduced a failing case to its essentials; the reporter who does that first saves the developer hours.
• Report what was seen, not what was guessed. The gateway rejects Rs 249.99 is an observation; the rounding code is broken is a guess, and may be wrong.
• One failure per report. A report holding two failures is closed when one is fixed, and the other is lost.

Worked example: rewriting a report

A student helping with ExamReg's system test filed a report whose title was Fee wrong!!, whose only step was pay the fee, whose actual result was wrong amount, and whose severity was very high.

The tester who investigated it rewrote it as DR-205, the defect whose life cycle Chapter Seventy-Four followed. The program checks both versions against ISTQB's list of contents and three rules of this chapter's own: a title of at least six words that is not mostly words like wrong and error, more than one step, and a build number in the environment.

# the contents of a defect report logged in dynamic testing (ISTQB CTFL v4.0.1, section 5.5)
FIELDS = ["id", "title", "date", "author", "test object", "environment", "context",
          "steps", "expected", "actual", "severity", "priority", "status", "references"]
SEVERITY = ["critical", "major", "minor", "cosmetic"]          # ExamReg's scale
PRIORITY = ["P1", "P2", "P3", "P4"]
VAGUE_WORDS = {"error", "bug", "problem", "issue", "wrong", "broken", "fails", "not working"}

def check(report):
    """What stops a developer acting on this report."""
    problems = [f"missing: {f}" for f in FIELDS if not report.get(f)]
    title = report.get("title", "")
    words = [w.strip("!.?,").lower() for w in title.split()]
    if title and (len(words) < 6 or sum(w in VAGUE_WORDS for w in words) > len(words) / 3):
        problems.append("title: too short or too vague to find the report again")
    if report.get("steps") and len(report["steps"]) < 2:
        problems.append("steps: one step is rarely enough to reproduce a failure")
    if report.get("severity") and report["severity"] not in SEVERITY:
        problems.append(f"severity: {report['severity']!r} is not on the scale {SEVERITY}")
    if report.get("environment") and "build" not in report["environment"]:
        problems.append("environment: no build number, so nobody knows which version failed")
    return problems

first = {"title": "Fee wrong!!", "author": "Rohan", "steps": ["pay the fee"],
         "actual": "wrong amount", "severity": "very high"}
rewritten = {
    "id": "DR-205",
    "title": "Fee page shows Rs 249.99 instead of Rs 250 for a concession student 3 days late",
    "date": "2026-10-14", "author": "Neha, tester",
    "test object": "ExamReg 2.0, fee payment page",
    "environment": "build 2.0.7 on the test server; Chrome 140 on Windows 11",
    "context": "system test cycle 1, test case TC-FEE-07 (decision table rule R7)",
    "steps": ["log in as test student 2026CS014, who has a concession",
              "fill the exam form with 1 backlog paper, submitted 3 days after the last date",
              "open Pay the fee"],
    "expected": "Rs 250: Rs 150 for the backlog paper and Rs 100 late fee; no form fee",
    "actual": "Rs 249.99, and the payment gateway rejects the amount",
    "severity": "major", "priority": "P1", "status": "new",
    "references": "TC-FEE-07; requirement FEE-2; screenshot fee-page-DR205.png",
}
for name, report in [("the first report", first), ("the rewritten report", rewritten)]:
    problems = check(report)
    print(f"{name}: {len(problems)} problem(s)")
    for p in problems:
        print("   " + p)

the first report: 12 problem(s)
   missing: id
   missing: date
   missing: test object
   missing: environment
   missing: context
   missing: expected
   missing: priority
   missing: status
   missing: references
   title: too short or too vague to find the report again
   steps: one step is rarely enough to reproduce a failure
   severity: 'very high' is not on the scale ['critical', 'major', 'minor', 'cosmetic']
the rewritten report: 0 problem(s)

The first report has twelve problems, and each is a question the developer would have to come back with. Which build? Which student, which papers, how late? What amount was expected, and why? Very high on what scale? The rewrite answers all of them before they are asked. Its title alone says what fails (the amount shown), where (the fee page), for whom (a concession student 3 days late) and by how much (a paisa). Its steps start from a named test student, and its expected result shows its arithmetic and its source, the fee rule the decision table of Chapter Fifty-Six tested. And its context links it to the test case that will confirm the fix.

A program can check a report's form, as this one does; it cannot check its truth. That the steps really reproduce the failure is something only the reporter can make sure of, by following them once more before filing.

Severity and priority

The two fields look alike and answer different questions.

Severity is about the failure. IEEE 982:2024 defines it as the "relative detrimental effect of a failure". Florac calls the same attribute criticality, "a measure of the disruption a problem gives users when they encounter it", normally given by whoever reported it. Bugzilla's Severity field "indicates how severe the problem is", ranging "from blocker ('application unusable') to trivial ('minor cosmetic issue')". ExamReg's scale has four levels: critical, major, minor, cosmetic.

Priority is about the work. Florac's urgency "determines the order in which problems are evaluated, resolved, and closed", and it is assigned by the organisation that fixes problems. Bugzilla: "The Priority field is used to prioritize bugs, either by the assignee, or someone else with authority to direct their time such as a project manager."

Usually a severe failure is also urgent, but not always, and the exceptions are why both fields exist. ExamReg's four combinations:

The top-right and bottom-left boxes are the ones a student should be able to explain in an examination: severity is judged from the failure, priority from the failure, the deadline, the number of people affected, the workaround and the cost of fixing now.

What it does not mean

A defect report is not an accusation. It describes a failure and its evidence; it does not name whose mistake it was.

Severity is not priority. A critical failure in a rarely used function can wait; a cosmetic flaw on the first page every student sees cannot.

More detail is not always better. The steps should be the fewest that reproduce the failure; everything else goes in attachments.

A report checker does not make a report true. It finds missing parts; only reproducing the steps shows the report is right.

Quick revision

• ISTQB v4.0.1 contents: identifier; title; date, organisation, author and role; test object and environment; context; description with steps and evidence; expected and actual results; severity; priority; status; references.
• Good reports: a searchable title (what, where, when), minimal numbered steps from a stated start, observations not guesses, one failure per report, evidence attached.
• Severity: "relative detrimental effect of a failure" (IEEE 982:2024); Florac's criticality, from the reporter.
• Priority: the order of fixing; Florac's urgency, from the organisation that fixes.
• Four combinations: high and high (double charge), high severity and low priority (yearly report crash), low severity and high priority (misspelt name on the login page), low and low (small font).
• Worked example: the first report had 12 problems; the rewritten DR-205 had none.

Test yourself

1. List the contents of a defect report. A unique identifier; a title summarising the anomaly; the date, organisation and author with role; the test object and test environment; the context, such as the test case run; a description with the steps to reproduce and evidence such as logs and screenshots; the expected and actual results; the severity; the priority; the status; and references such as the test case.

2. Distinguish severity from priority, and say who sets each. Severity is the degree of harm the failure causes, judged from its effect on users and requirements, and is usually given by the reporter. Priority is how soon the defect should be fixed relative to others, set by whoever directs the fixing work, such as a project manager or triage board, taking into account deadlines, workarounds and cost.

3. Give an example of a high-severity, low-priority defect and of a low-severity, high-priority one. High severity, low priority: a crash in an annual report that is rarely run and has a workaround. Low severity, high priority: a misspelt college name on the login page just before registration opens.

4. Rewrite the report titled Fee wrong!!, with the single step pay the fee and the actual result wrong amount. DR-205: Fee page shows Rs 249.99 instead of Rs 250 for a concession student 3 days late. Environment: build 2.0.7, Chrome 140 on Windows 11. Steps: log in as test student 2026CS014 (concession); fill the exam form with one backlog paper, submitted 3 days after the last date; open Pay the fee. Expected: Rs 250 (Rs 150 backlog fee and Rs 100 late fee, no form fee). Actual: Rs 249.99, and the gateway rejects it. Severity major, priority P1; test case TC-FEE-07.

5. Why should a defect report contain only one failure? Because the report is resolved and closed as a unit; if it holds two failures, fixing one may close the report while the other remains unfixed and forgotten.

6. Why must the expected result state its source? Because the developer must know whether the tester's expectation is right; an expected result traced to a requirement or test case can be checked, while one without a source may itself be the mistake, a test case defect rather than a product defect.