4.

1 Defect Classification
• What is Defect Management: Defect management is the process to find the
defect as quickly as possible & minimize the impact of the defect.

• It is the process of enhances quality by adding value to the most important

attributes of software like reliability, maintainability, efficiency and portability.

• Software defects are expensive. Moreover, the cost of finding and correcting
defects represents one of the most expensive software development activities.

• To do this development teams need to implement a defect management

process that focuses on preventing defects, catching defects as early in the
process as possible, and minimizing the impact of defects.
• A little investment this process can yield significant return.
 Classification of Defect:
There are various ways in which we can classify. Below are some of the classifications:

1) Severity Wise:
 Major: A defect, which will cause an observable product failure or departure from
requirements

 Minor: A defect that will not cause a failure in execution of the product

 Fatal: A defect that will cause the system to crash or close abruptly or effect other
applications
2) Work Product Wise:
 SSD: A defect from System Study document

 FSD: A defect from Functional Specification document

 ADS: A defect from Architectural Design Document

 DDS: A defect from Detailed Design document

 Source code: A defect from Source code

 Test Plan/ Test Cases: A defect from Test Plan/ Test Cases

 User Documentation: A defect from User manuals, Operating manuals

3) Type of Errors Wise:

 Comments, Computational Error, Data Error, Database Error, Missing Design

 In correct Design, Boundary Conditions Neglected, Interface Error, Logic Error, Message Error,

Navigation Error, Performance Error

 Missing Requirements, Incorrect Requirements, Test Plan error, TC Error, Variable Declaration

Error, etc.
4) Status Wise:
• Open
• Closed
• Deferred
• Cancelled

MSBTE Question:

• Give / Explain Defect Classification in detail.

• Define Defect Management. Which are the root causes of Defect Management.

• What is defect management ? Give defect classification in detail

4.2 Defect Management Process

• The process of finding defects & reducing them at the lowest cost is called as Defect Management
Process.
• Following Figure shows Defect Management Process:
1. Defect Prevention: Implementation of techniques, methodology and standard processes to
reduce the risk of defects.
2. Deliverable Baseline: Deliverables are considered to be ready for further development. i.e. the
deliverables meet exit criteria. When a deliverables is base lined, any further changes are
controlled. Errors in a deliverables are not considered defects until after the deliverables is base
lined.
3. Defect Discovery: To find the defect through the process of verification and validation.
4. Defect Resolution: Defect is corrected or corrective action is taken and notification is given to
tester. Work by the development team to prioritize, schedule & fix a defect & document the
resolution.

5. Process Improvement: To identify ways to improve the process to prevent further future
occurrences of similar defects. l.e. Corrective and preventive action is taken for processes
improvement.

6. Management Reporting: Reporting is about status of application and processes.

 Defect Prevention Process:
• Prevention is better than cure applies to defects in the software development life cycle
for software testing.

• Defect prevention is one of the important activities in any software project. It is QA

process to identify the root causes of defects and improve the process to avoid
introducing defects, which help to improve the quality of the software product.
• In Defect prevention phase testers are involved in the studying and reviewing requirement
specification document. Basically this is an art to review the requirement documents.

The five general activities of defect prevention are:

 Software Requirement Analysis

 Review: Self & Peer Review
 Defect logging & Documentation
 Root Cause Analysis & Preventive Measures Determination
 Embedding Procedures in to Software Development Process
 Finally, Defect Prevention is not an individual exercise but a team effort

MSBTE Question:

Draw & explain Defect Management Process.

Draw & explain Defect Prevention Process.

4.3 Defect Life Cycle The

different states of bug life cycle are as shown in the above

diagram:

1. New: When the bug is posted for the first time, its state will
be "NEW". This means that the bug is not yet approved.

2. Open: After a tester has posted a bug, the lead of the tester
approves that the bug is genuine and he changes the state
"OPEN".

3. 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".
 4. Test: 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.

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

6. 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".

7. 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".
8. 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.

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

MSBTE Question:
Draw & explain Defect Life Cycle.
Draw Defect Life Cycle
4.4 Defect Template
 Defect report is probably primary work product for most of the software testers.
 Good bug report is informative & understandable. Weak reports generate extra work for everyone.
 Defect reports are used to alert software programmers about the defect & give them sufficient information to
find root cause & fix the problem.

A good defect report might have following sections:

1) Severity: It indicates how bad the bug is, the likelihood and the degree of impact when the user encounters the
bug.
1. System crash, data loss, data corruption.
2. Operational error, wrong result, loss of functionality.
3. Minor problem, misspelling, Ul layout, rare occurrence
2)Priority: It indicates how much emphasis should be placed on fixing the bug
and the urgency of making the fix.
Levels are:
 Immediate fix, blocks further testing, very visible.
 Must fix before the product is released.
 Should fix when time permits.
 Would like to fix but the product can be released as it is.

3) Headline: One line description of the defect. Remember a good headline will
always be clear, related to the defect & give some hints on how critical defect
could be.

4) Product: In most cases defect tracking system is used for more than one
product. So specifying appropriate product & version is very important
 5) Component: Products are normally very complex & can be divided into components. A defect report

containing proper information about component can help managers in assigning it to appropriate person.

6) Defect Type: Defect type could be functionality, specification, regression, UI, etc. This classification can

be used to analyze how defects are distributed in the system.

7) Environment: Proper information about your test execution environment should be present. eg.

Database, platform, etc.

8) Steps: All the steps should be specified clearly. You should not assumed that programmer will

understand this.

9) Attachments: Whatever additional information is needed for the defect, should also be attached.

10) Comments: If you have any additional comments on the defect, you should specify early
Example:
 Name of Reporter
 Email Id of Reporter
 Version or Build: <Version or Build of the product>
 Module or component: <mention here the name of tested module or component>
 Platform / Operating System:
 Type of error: <coding error/design error/suggestion / UI/documentation / text error/hardware error >
 Priority:
 Severity:
 Status:
 Assigned to:
 Summary:
 Description: <mention here the steps to reproduce, expected result and actual result>
SBTE Question:
• Which parameters are considered while writing good defect report? Also write contents of Defect Template.
• Explain Defect Report Template with its attributes.
 4.5 Estimate Expected Impact of Defect
• Defect Impact means degree of impact on the development or operation of a
component or system is called defect impact.

• Once the critical risk are identified, the financial impact of each risk should be
estimated.

• This can be done by assessing the impact, in dollars, if the risk does become a problem
combined with the probability that the risk will become problem.

• The product of these two numbers is the expected impact of the risk. The expected
impact of a risk (E) is calculated as;
E = P * I,

where: P= probability of the risk becoming a problem and I= Impact in dollars if the
risk becomes a problem.
 Techniques For Finding Defect:
Defects are found either by pre planned activities specifically intended to uncover
defects (eg. Quality control activities such as inspection, testing, etc.) or by accident (e.g. user
in production). Following are the different techniques used in finding defects:

• Static Techniques: Testing that is done without physically executing a program or system. A code review is an
example of static testing techniques.

• Dynamic Techniques: Testing in which system components are physically executed to identify defects.
Execution of test case is an example of dynamic testing techniques

• Operational Techniques: When the software system product is completed it produces deliverables of the user,
customer or control personnel. While using the final software product the defect is found & software is not
working or fails.

MSBTE Question:
• What are the points considered while estimating impact of Defect?
• Explain Techniques to Find Defect.
• State how to minimize risk impact while estimating defect.
 4.6 Reporting A DefectIt
is essential that you report defects effectively so that time & effort is not
unnecessarily wasted in trying to understand & reproduce the defect.
Following are some guidelines for making bug reports:

• Be Specific: Specify the exact action: Do not say somethingwhich adds confusion. In case of multiple paths,
mention the exact path you followed.

• Be Detailed: Provide more information. i.e. do not be lazy.

• Be Objective: Do not make subjective statements like "This is lousy applications" or "You fixed it real bad“

• Reproduce the defect: Do not be impatient & file a defect report as soon as you uncover a defect. Replicate it
at least once more to be sure.

• Review the report: Do not submit as soon as you write the report. Review it at least once.
 MSBTE Question:
What is the Process of Bug Reporting prepare a sample bug reporting format?