1. Chapter Defect Management
Objectives:
Find, handle and report defect by using standard technique.
Understand the Defect Life Cycle.
A Defect is:
Undesirable state.
Cause of customer/user satisfaction
Concern about the quality of an Application Under Test.
Inconsistency in behavior of the software.
Condition in a software product which does not meet a software requirement or end user expectations/satisfaction
Methods for preventing programmers from introducing bugs during development:
Programming techniques adopted
Peer review
Root Cause of Defect
Software development methodologies
Code analysis
Effect of Defect.

2. Introduction to Defect Management , Its need
Introduction of Defect Management
Process of recognizing , investigating, taking action (Decision making) and disposing of defects
It involves recording, classifying them and identifying their impact.
Its counting and managing defects
Need of defect Management:
Defect analysis is at early stages of software development reduce the time, cost and resources required for rework.
Early defect prevents its migration from requirement phase to design and then to implementation phase.
It enhances quality by adding value to the most important attributes of software i.e. reliability, maintainability efficiency and portability.

3. Defect Classification
Defect may be classified in Different ways under different schemes.
 Requirement-related defects may be further classified as-
Functional Defect
Interface Defect
 Design related defect may be classified as follows-
Algorithm Defect
Module –Interface Defect
System –Interface Defect
User –Interface Defect
Coding Defect
Variable Declaration/Initialization Defect
Database-Related Defect
Commenting/Documenting Defect
Testing Defect
Test-Design Defect
Test-Environment Defect
Test-Tool Defect

4. Work product wise errors
• SSD -- System Study Document
• FSD – Functional specification Document
• ADS – Architectural Design Document
• DDS – Detailed design document
• Source Code – defect from source code
• Test plan/ Test cases: From Test plan/ Test cases
• User Documents : From user manuals, Operating manuals

5. Error-wise types: Comments, Computational Errors, Data Errors,
Database Errors,
Missing Design,
Inadequate or sub optimal design,
Incorrect design,
Ambiguous design,
Boundary conditions neglected, Interface errors,
Logic errors,
Message errors,
Navigation errors,
Performance errors
Missing requirement errors,
Inadequate requirement,
Ambiguous requirements,
sequencing / timing errors,
standards,
system errors,
test plan,
test case errors,
typographical errors,
variable declaration errors.
Status wise errors:
Open, Close, Deferred, Cancelled

6. Defect Management process must have the following Characteristics/ Principles:
Primary Goal of Defect Management Is to Prevent Defect
Defect Management Must Be Risk Driven
Defect Prevention Must Be an Integral Part of Development Process
Process of Defect Tracking Must be Automated As Maximum As Possible
Defect Integration Must Be Used for Process Improvement
Defects are caused by imperfect or faulty processes

7. Defect Management Process(Fixing and Root Cause Defect)
Defect Management process must include the appraisal of a defect finding process, software development process and the actions initiated to close the defects and strengthen the product/process associated with development, so that defects are not repeated again and again. It typically includes correction, corrective action and preventive action.
 It includes,
Defect Naming
Defect Resolution
Once the developer have acknowledged a valid defect ,
the resolution process starts:

8. Deliverable Base-lining , Identify key deliverables
Defect Management Process(Fixing and Root Cause Defect) continues………..
Prioritize risk:
Answer following questions and initiate any immediate action
Is this a previously reported defect or new?
What priority should be given to fixing this defect?
What Steps to minimize impact of the defect prior to fix?
(Critical, Major, Minor)
Schedule Fix:
Based on the priority of the defect, the fix should be scheduled.
Fix defect:
It corrects and verifies one or more deliverables required to remove the defect from the system.
Test data, check lists, should be reviewed, enhanced so that in future this defect would be caught earlier.
Report Resolution:
Once defect have been fixed, along with other information,
like nature of the fix, when and how the fix will be released,
Deliverable Base-lining , Identify key deliverables
Define standards for each deliverable
Process Improvement
Management Reporting:

9. Following Information needed to collect during the defect management process
To report on the status of individual defects
To provide tactical information and metrics to help project management, redesign of error prone modules.
To provide strategic information and metrics to senior management, defect trends, problem systems.
Process to be improved to either prevents defects or minimizing their impact.
To provide insight into the likelihood that target dates and cost estimates will be achieved

10. Defect Prevention process / Defect Fixing
The process of risk analysis and defect prevention is refer from following figure:
Identifying critical risks:
Understand the critical risks facing the project/system
Missing a key requirement
Vendor supplied software does not function properly
Performance is poor and unacceptable
Critical function of software that does not function properly.
Hardware malfunctioning
Hardware and/or software does not integrate properly
Users are unable or willing to hold new system.

11. Estimate expected Impact:
When critical risks are identified , the financial impact of each risk should be estimated Estimating/expected impact by ,
E = P * I
Where,
P= Probability of risk
I = Impact in dollar’s if risk is problematic.
Defect prevention or defect fixing begins with an assessment of the critical risks associated with system. It is cycle of risk analysis and actions based on its ranking.

12. 3. Minimizing risk impact on estimated defect
It may be strongly affected by a risk becomes a problem and how long it takes for a problem to become recognized and how long it takes to be fixed once recognized.
 Estimate the risk: by Reducing scope of the product.
Reduce the probability of a risk becoming a problem: Inspections and testing reduces but not eliminates the probability of problems.
Reduce the Impact if there is a problem: Sometimes risk cannot be eliminated and even probability is low the expected impact is high , here emergency or disaster recovery plans would be used.

13.  Defect Life Cycle

14.  Defect Life Cycle

15. The different states of bug life cycle are
New: When the bug is posted for the first time, its state will be “NEW”. This means that the bug is not yet approved.
Open: After a tester has posted a bug, the lead of the tester approves that the bug is genuine and he changes the state as “OPEN”.
Assign: Once the lead changes the state as “OPEN”, he assigns the bug to corresponding developer or developer team. The state of the bug now is changed to “ASSIGN”.
Test/Retest: Once the developer fixes the bug, he has to assign the bug to the testing team for next round of testing. Before he releases the software with bug fixed, he changes the state of bug to “TEST”. It specifies that the bug has been fixed and is released to testing team.// At this stage the tester do the retesting of the changed code which developer has given to him to check whether the defect got fixed or not.

16. The different states of bug life cycle continued….
Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software.
Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “REJECTED”.
Verified: Once the bug is fixed and the status is changed to “TEST”, the tester tests the bug. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “VERIFIED”.
Reopened: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “REOPENED”. The bug traverses the life cycle once again.

17. The different states of bug life cycle continued….
Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “CLOSED”. This state means that the bug is fixed, tested and approved.
Fixed: When developer makes necessary code changes and verifies the changes then he/she can make bug status as „Fixed‟ and the bug is passed to testing team.
Pending retest: After fixing the defect the developer has given that particular code for retesting to the tester. Here the testing is pending on the testers end Hence its status is pending retest.
Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “duplicate“.
Not a bug: The state given as “Not a bug” if there is no change in the functionality of the application. For an example: If customer asks for some change in the look and field of the application like change of color of some text then it is not a bug but just some change in the looks of the application.

18. Contents of defect template.
A defect report documents an anomaly discovered during testing. It includes all the information needed to reproduce the problem, including the author, release/build number, open/close dates, problem area, problem description, test environment, defect type, how it was detected, who detected it, priority, severity, status, etc.
After uncovering a defect (bug), testers generate a formal defect report. The purpose of a defect report is to state the problem as clearly as possible so that developers can replicate the defect easily and fix it.

19. DEFECT REPORT TEMPLATE
In most companies, a defect reporting tool is used and the elements of a report can vary. However, in general, a defect report can consist of the following elements.

20. DEFECT REPORT TEMPLATE continued…

21. Estimate Expected Impact of a Defect
Ways To Handle Risk
Accept the Risk As It Is
Bypassing the Risk
Minimize Risk Impact or Probability
Minimization of problem due to risk happens in the following manner
Eliminate Risk
Mitigation of Risk
Detection Ability Improvement
Contingency Planning
Risk is important factor in Defect Management:
Defect indicates a probability that some unplanned event may happen with a system during production due to wrong, either system interaction, or user interaction with system or environment problem.

22. Techniques for Finding Defect-
Static Techniques: quality control define checking the software product and related artifacts without executing them.– Desk checking/ Verification.
Reviews, Walkthroughs, Inspection, and Audits,
Reviewed with Checklist, Standards, and other artifacts, Knowledge and experience,
As there is no execution of code , product or documentation.
This helps conformance of requirements.
Dynamic Testing:
Its validation technique , which includes dummy or actual execution of work products to evaluate it with expected behavior. i.e. system testing, Unit Testing, This evaluates the product with respect to requirements defined , designs created and mark it as pass or fail – fitness for use.
Operational Techniques:
Include auditing work products and projects to understand whether the processes defined for development /testing are being followed correctly or not. Whether they are effective or not, it also revisits the defects before and after fixing any analysis. Smoke testing, Sanity testing.

23. Reporting a Defect-
Finding and reporting defects include following important steps SDLC, To establish capability of processes and for initiating corrective and preventive actions along with corrections, defect is symbol of failure, to find root cause of defect by analysis, initiate correction, corrective action, and preventive actions
In defect reporting following are points:
Give Complete Record of Discrepancies
Defect Report Forms the Base for Quality Measurement(for the software As well as Process)
Probability associated with defect finding.
Nobody can find all the defects in an application, if defect is not found in test it does not mean that software is good.
No. of defects can be a measure of lack of quality in software , severity, priority, category of defect must be defined.
Defect management is to get info. About capability of the processes and project management in totality.

24. Tips for Defect management
Be specific, Be detailed, Be objective,
Reproduce the defect, Review the report
Include Defect Management important stages,
Correct the Defect
Report Status of System
Gather Statistics to Predict Future
Process Improvement
Tips for Defect management
List all the defects found in various stages,
Those may be found in verification as well as validation
Initiate correction for all defects found in work product. Perform root-cause analysis for defects and initiate corrective as well as preventive actions.
perform risk analysis for allocating priority and severity of defect.