Chapter Defect Management H06 M14 Objectives Find handle

Chapter Defect Management H-06 M-14 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 Programming techniques adopted Peer review Root Cause of Defect during development: Software development methodologies Code analysis Effect of Defect.

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.

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 Test-Design Defect Test-Environment Defect Test-Tool Defect

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

• • • Error-wise types: Comments, Computational 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, • • • Status wise errors: • Open, Close, Deferred, Cancelled • • • 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.

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

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:

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:

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

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.

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.

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.

Defect Life Cycle

Defect Life Cycle

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.

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.

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.

Contents of defect template. A defect report documents 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.

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.

DEFECT REPORT TEMPLATE continued…

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.

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.

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.

ü 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.