[ISTQB-TA] Defect Management

Intro

  - Test Analysts evaluate the behavior of the system in terms of business and user needs

  - An anomaly (also called an incident) is an unexpected occurrence that requires further investigation.

  - An anomaly may be a failure caused by a defect.

  - An anomaly may or may not result in the generation of a defect report.

 

 

 

When Can a Defect be Detected?

  - A defect can be detected through static testing and dynamic testing.

  - Each phase of the software development lifecycle should provide methods for detecting and eliminating 

potential failures.

    Examples:

       - during the development phase, code and design reviews should be used to detect defects.

       - During dynamic testing, test cases are used to detect failures.

  - The earlier a defect is detected and corrected, the lower the cost of quality for the system as a whole.

  - The defect tracking system should allow the Test Analyst to record the phase in the lifecycle 

in which the defect was introduced and the phase in which it was found.

     --> If the two phases are the same, then perfect phase containment has been achieved.

     --> This means the defect was introduced and found in the same phase and didn’t “escape” to a later phase.

  - Phase containment is an effective way to reduce the costs of defects.

 

 

 

Defect Report Fields

  - The fields (parameters) supplied for a defect report are intended to provide enough information 

so the defect report is actionable.

  - An actionable defect report is:

 

 

  - The information recorded in a defect report should be divided into fields of data.

  - The more well-defined the fields, the easier it is to report individual defects as well as to produce 

trend reports and other summary reports.

  - When a defined number of options are available for a field, 

having drop down lists of the available values can decrease the time needed when recording a defect.

  - Different types of defect reports require different information and the defect management tool

  - Data should be recorded in distinct fields, ideally supported by data validation 

in order to avoid data entry failures, and to ensure effective reporting.

 

  - Defect reports are written for failures discovered during functional and non-functional testing.

  - Non-functional defect reports may require more details regarding the environment, other performance parameters, sequence of steps and expected results.

  - In cases where a standard is not available and the requirements did not cover the non-functional 

quality aspects of the software, the tester may use the "reasonable person" test to determine that the usability is unacceptable.

    --> In that case, the expectations of that "reasonable person" must be clearly stated in the defect report.

 

  - Because non-functional requirements are sometimes missing in the requirements documentation, 

documenting non-functional failures presents more challenges for the tester in documenting the "expected" versus the "actual" behavior.

  - the defect information must also be supplied to support accurate classification, risk analysis, and 

process improvement

 

 

Defect Classification

  - Common classification information for newly identified defects includes:

 

 

--> detected 와 introduced 의 차이?

 

  - Once the defect has been investigated, further classification may be possible:

 

 

 

  - When the defect is fixed (or has been deferred or has failed confirmation), 

even more classification information may be available, such as:

 

 

 

  - also frequently classified based on severity and priority.

  - depending on the project, it may make sense to classify based on mission safety impact, 

project schedule impact, project costs, project risk and project quality impact.

  - The final area of classification is the final resolution.

  - Defects are often grouped together based on their resolution

    Ex) fixed/verified, closed/not a problem, deferred, open/unresolved.

    --> This classification usually is used throughout a project as the defects are tracked through their lifecycle.

 

  - The classification values used by an organization are often customized.

    It is important that the classification values be used consistently in order to be useful.

    Too many classification fields will make opening and processing a defect somewhat time consuming

    it is important to weigh the value of the data being gathered against the incremental cost 

    for every defect processed.

      --> The ability to customize the classification values gathered by a tool is often 

            an important factor in tool selection.

 

 

Root Cause Analysis

  - The purpose of root cause analysis

    1. determine what caused the defect to occur

    2. provide data to support process changes that will remove root causes

  - Root cause analysis is usually conducted by 

    1. the person who investigates

    2. the person who is either fixes the problem or determines the problem should not or cannot be fixed.

       (This is usually the developer.)

  - Setting a preliminary root cause value is commonly done by the Test Analyst who will make 

an educated guess regarding what probably caused the problem.

  - When confirming the fix, the Test Analyst will verify the root cause setting entered by the developer.

  - At the point the root cause is determined, 

it is also common to determine or confirm the phase in which the defect was introduced.

 

  - Typical root causes include:

 

 

  - root cause information is aggregated to determine common issues that are resulting in the creation of defects.

     --> 어느 활동에 더 집중해야 할지 알게 해준다. ex_ 요구사항에 문제가 많이 발견된다면 리뷰 활동에 더 시간 투자

 

  - Using root cause information for process improvement helps

    1. an organization to monitor the benefits of effective process changes

    2. to quantify the costs of the defects

    3. provide funding for process changes that might require purchasing additional tools and 

equipment as well as changing schedule timing.