Establish and Maintain the Application's Known Defects - Application Management Best Practices

Establish and Maintain the Application's Known Defects

(Chapter 113 of Application Management Best Practices)

Executive Summary: Chapter Overview

IF4IT

The Bottom Line

Every Application carries Defects that are known but not yet fixed, and leaving them unrecorded causes rediscovery, duplicate reports, and a hidden picture of quality. This chapter sets out what to record for each known Defect, requires explicit approval of any deferral, and calls for open Defects and workarounds to appear in Release Notes. A maintained Defect record lets support teams answer users immediately and gives owners an accurate basis for Release priorities.

Core Concepts

Concept	Definition & Strategic Role
Known Defect Record	The set of facts captured for each known Defect: description and reproduction steps, affected Instances and Releases, severity and impact, workaround, status, owner, planned or delivered fix Release, and links to incidents, Problems, requirements, and tests.
Deferred Defect Approval	The requirement that Defects found in testing and deferred to a later Release be recorded, with the deferral approved by the Business Application Owner or their delegate. It makes shipping with a known flaw an accountable decision rather than a silent one.
Release Notes Defect Listing	The practice of listing open Defects and their workarounds in each Release’s Release Notes. It puts known flaws in front of support teams so they can tell users immediately whether a problem is already known and how to work around it.

Quick Q&A

Question: What goes wrong when an Application's known Defects are not recorded?

Answer: The same Defect is rediscovered and re-reported, support teams cannot tell users whether a problem is already known, and the true quality of the Application is hidden from its owners. Recording known Defects prevents this duplicated effort and gives owners an accurate view of quality when prioritizing future Releases.

Question: Who must approve a Defect found in testing that is deferred to a later Release?

Answer: The deferral must be approved by the Business Application Owner or their delegate, and the deferred Defect must be recorded like any other known Defect. It is then kept in the enterprise’s defect tracking tool, linked from the Application Documentation, and reviewed with every Release.

This chapter explains how to establish and maintain the record of an Application’s known Defects.

Why Known Defects Must Be Recorded

Every Application has Defects, and many are known but not yet fixed. When known Defects are not recorded, the same Defect is rediscovered and re-reported, support teams cannot tell users whether a problem is known, and the true quality of the Application is hidden from its owners.

Establish the Record of Known Defects

For each known Defect, record:

A description and the steps to reproduce it.
The Instances and Releases in which it occurs.
Its severity and its impact on users and the business.
Any workaround.
Its status, owner, and the Release in which a fix is planned or was delivered.
Links to related incidents, Problems, requirements, and tests.

Defects found in testing and deferred to a later Release must be recorded, with the deferral approved by the Business Application Owner or their delegate.

Keep known Defects in the enterprise’s defect tracking tool, linked from the Application Documentation, and list open Defects and their workarounds in each Release’s Release Notes, so that support teams can use them. Review open Defects with every Release.

Best Practice: Establish and Maintain the Application’s Known Defects

It is a best practice to both establish and maintain the solution for an Application’s known Defects: record each with its impact, affected Instances and Releases, workaround, status, and owner, approve any deferral explicitly, and share open Defects and workarounds with support teams.

Benefits: A maintained Defect record prevents duplicated effort, lets support teams give users immediate answers and workarounds, and gives owners an accurate view of the Application’s quality when prioritizing future Releases.

The Systems Development Lifecycle (SDLC) Best Practices addresses Defect management during testing. The Release Management Best Practices addresses how known Defects are considered in Release decisions.

How to cite this page

When referencing this page in academic work, internal standards, or external publications, include the page title, IF4IT as author and publisher (The International Foundation for Information Technology (IF4IT), LLC), the URL, and your access date.

Example (informal web citation):

The International Foundation for Information Technology (IF4IT), LLC. Establish and Maintain the Application's Known Defects | Application Management Best Practices. https://if4it.org/best-practices/application-management-best-practices/establish-and-maintain-the-application-s-known-defects/ (accessed 2026-10-30).

See About Us for content governance and site-wide citation guidance.

Legal Disclaimers

Why Known Defects Must Be Recorded

Establish the Record of Known Defects

Maintain and Share the Record

Best Practice: Establish and Maintain the Application’s Known Defects

Connections to Related IF4IT Practices and Inventories

How to cite this page