Defects

When a test fails, the finding needs to be captured, owned, and resolved. A defect records that failure as a tracked item connected to the work it affects — so a failed step becomes an actionable, traceable record rather than a note.

Logging a defect

A failed step or test case is the natural trigger for raising a defect. The defect captures what went wrong and links back to the test that surfaced it, so the evidence and the problem stay together. Because the defect is a record, it carries its own identity, history, and audit trail like everything else in the platform.

Status and severity

A defect moves through a lifecycle — typically Open, In Progress, and Closed — so its state is always clear. It also carries a severity (for example, critical down to minor) that signals how serious the problem is and helps prioritize what gets fixed first. Status and severity together let you manage a backlog of findings rather than just a list.

Linking and impact

A defect connects to more than the test that found it. Through the thread, it links to the requirement the failing test verifies and to anything else it touches, so the Linked Defects view on an item shows the open issues against it at a glance. This is what keeps a known problem visible everywhere it’s relevant — on the test, on the requirement, and in the release that depends on them.

Closing the loop

A defect stays open until it’s resolved and re-verified. Re-running the test that failed — often as part of the next run of the plan — confirms the fix, and closing the defect completes the record. The full history, from the failed step through the fix to the passing re-test, remains as evidence that the issue was found and handled.