ISTQB CTFL Defect Management: Workflow, Defect Reports, Severity and Priority

Defect management is the process an organization uses to handle every reported anomaly from the moment it is discovered until its report is closed. Finding defects is one of the main objectives of testing, so the CTFL syllabus expects every project to have an established defect management process, and it expects all of the stakeholders involved (testers, developers, product owners, managers, and anyone else who reports or resolves anomalies) to follow it, not only the test team.

The process deals with reported anomalies rather than confirmed defects. When something is first reported, nobody yet knows what it is: it may turn out to be a real defect, or something else, such as a false positive or a change request. That question is settled while the report is being handled, so the process starts at discovery, not at the point where a developer agrees that the code is wrong. Anomalies can be reported in any phase of the software development lifecycle (SDLC), and the form the reports take depends on that lifecycle (a ticket in a defect tool, an item on a board, a review log entry).

The CTFL learning objective for this topic is K3, FL-5.5.1 Prepare a defect report: you are expected not only to recall what a defect report contains but to apply it to a situation, for example by judging which items a draft report is missing.

At a minimum, a defect management process includes two things: a workflow for handling individual anomalies from their discovery to their closure, and rules for their classification. Organizations often build more on top of these two, but anything beyond them is a choice for the project rather than part of the minimum the syllabus defines.

The typical workflow has four activities, in this order:

1. Log the reported anomaly, so that it is recorded and cannot be lost.
2. Analyze and classify it: work out what it is (a real defect, a false positive, a change request, a duplicate of another report) and classify it, for example by severity.
3. Decide on a suitable response: typically either to fix the defect or to keep it as it is (for example, accept a cosmetic problem in a release, or defer it).
4. Close the defect report once the response has been carried out (for a fix, after successful confirmation testing).

The order matters. You cannot analyze something that was never logged, and the decision to fix or keep a defect comes from the analysis; closing comes last. Analysis establishes what the anomaly is and how serious it is; the choice of what to do about it, such as accepting a clumsily worded but correct help text until a later release, belongs to the decide on a response activity, and closing only records that the chosen response has been completed.

A reported anomaly can turn out to be a real defect or something that is not a defect at all, and the defect management process resolves which it is. The syllabus names two non-defect outcomes:

Two related terms from the ISTQB glossary are easy to confuse. A false positive is a reported failure that is not caused by a defect in the test object. A false negative is the opposite: a test that passes even though a defect is present, so nothing is reported at all. Only false positives arrive as defect reports.

Because these outcomes are part of the process, the reports for false positives and change requests are kept and resolved through the workflow too; their outcome is recorded in the report like any other. A duplicate of an existing report is another common outcome, handled through the report's status (see below).

Yes. The syllabus advises that anomalies found by static testing, particularly by static analysis, are handled in a similar way to those found by dynamic testing. A coding-standard violation flagged by a static analysis tool, or a defect found in a review of a requirements document, is a defect in a work product even though no failure has been observed: it is logged, analyzed and classified, given a response and closed.

The syllabus does not prescribe a separate report format for these findings. In practice, because no test was executed and no failure observed, such a report typically focuses on the work product and where in it the defect lies, rather than on actual output. Handling static findings through the same process means they count towards the quality picture and the process-improvement data just as dynamic findings do.

A defect report has three objectives in the CTFL syllabus:

• Resolving the issue: it gives those responsible for handling and resolving the reported defect enough information to do so. This is the main reason the report must be clear and reproducible.
• Tracking work-product quality: taken together, defect reports give a means of tracking the quality of the work product, for example how many open defects of high severity remain in a build.
• Improving the process: they provide ideas for improving the development and test process. Analysing many reports may show, for example, that a large share of defects come from misunderstood interface agreements between two teams, which suggests a change to how those agreements are written and checked.

Each objective serves a different reader: the people resolving one defect, the people monitoring the quality of the product, and the people improving how it is built and tested. Other activities, such as test progress and test completion reporting, may draw on defect data, but they have their own work products and their own objectives.

A defect report logged during dynamic testing typically contains the items below. This list is the core of the K3 objective: when preparing or reviewing a report, check it against each item.

The list describes the anomaly as the reporter observed it. Information that only emerges while the defect is being resolved, from debugging and planning the fix, is produced later by the people who resolve it. When you are asked which items a draft report is missing, compare it with this list item by item, rather than with what a particular tool happens to show.

Many of these items can be filled in automatically when a defect management tool is used: typically the identifier, the date, the author and the initial status. The tester still has to supply the content that only a person who saw the failure can give, such as the steps, the test data, screenshots, the expected and actual results and the severity.

The syllabus also points to ISO/IEC/IEEE 29119-3, the test documentation standard, which provides templates and examples for defect reports. That standard calls them incident reports.

A good defect report lets someone who was not there understand, reproduce and resolve the anomaly. Four items do most of that work, and each has a distinct job.

Title

The title is a short, factual summary of the anomaly: the area where it happened and the observable symptom, in a few words. For example, “Search: date filter returns orders outside the selected range” lets a reader recognise the report in a list without opening it. A title reports what was observed; the full detail belongs in the description and the urgency in the priority field.

Context

The context says what the tester was doing when the anomaly appeared: which test case was being run, in which test activity and SDLC phase (for example acceptance testing), and with which test technique, checklist or test data (for example values chosen by equivalence partitioning). It is different from the identification of the test object and environment, which says what was tested and where.

Test object and environment

This item identifies exactly what was tested, such as the version or build of the test object, and where, such as the operating system, device, configuration or data set. Failures often depend on these details, so recording them precisely lets someone else set up the same conditions.

Description of the failure

The description must make the failure reproducible: the exact steps that detected it, the input used and supporting evidence such as test logs, database dumps, screenshots or screen recordings. Compare “Booking confirmation shows the wrong time” with a description that lists the steps, the time zone set in the user profile, the booking entered and a screenshot of the confirmation: only the second can be followed by someone else to see the same failure.

A defect report must state both the expected result and the actual result, because a failure is a difference between the two, and a reader cannot judge a difference from one side alone. If an online shop charges 7.50 for shipping a parcel while the rate table in the specification gives 5.00 for that weight, 7.50 is the actual result (what happened) and 5.00 is the expected result (what should have happened); together they show precisely what is wrong.

The expected result is also what makes a report checkable. Suppose a report says only that a search with an empty search box listed every product. On its own that is an observation, and a reader cannot tell whether it is wrong. Stating the expected result, for example that the specification requires a prompt asking the user to enter a search term, turns the observation into a defect claim that can be checked against the test basis.

Severity is the degree of impact that a defect has on the interests of stakeholders or on the requirements. Priority is the urgency with which the defect should be fixed. They are recorded separately because they are independent: any combination is possible.

The combinations that look surprising are the useful ones to understand:

• High severity, low priority: a crash in a reporting module that is switched off for every customer until a later release would have a serious impact if it occurred, but nothing can trigger it yet, so the fix is not urgent.
• Low severity, high priority: an outdated logo on a promotional page has little functional impact, but if a marketing campaign starts sending visitors to that page this afternoon, it needs fixing straight away.

When you set the two values, judge each against its own definition: severity from the impact, priority from the urgency in the stated situation.

The status records where a defect report is in its workflow. The CTFL syllabus lists these values as examples without defining them; the meanings below are how they are typically used:

Two distinctions come up often. Duplicate versus re-opened: a duplicate is a second report of an anomaly that is already reported; re-opened applies to the original report when its fix fails confirmation testing. One report per defect: a report and its status describe a single anomaly, so a different failure gets its own report with its own status rather than being added to an existing one. Confirmation testing and regression testing themselves are covered in the lesson on test types.