2. 2
Defect:
– Deviation between expected behaviour to actual behaviour is called defect.
Defect- Review:
– The software doesn’t do something that the product specification says it
should do.
– The software does something that the product specifications says it
shouldn’t do.
– The software does something that the product specification doesn’t mention.
– The software doesn’t do something that the product specification doesn’t
mention but should do.
– Difficult to understand, hard to use, slow etc.
Defect Management
3. 3
Defect:
– Deviation between expected behaviour to actual behaviour is called defect.
Defect- Review:
– The software doesn’t do something that the product specification says it
should do.
– The software does something that the product specifications says it
shouldn’t do.
– The software does something that the product specification doesn’t mention.
– The software doesn’t do something that the product specification doesn’t
mention but should do.
– Difficult to understand, hard to use, slow etc.
Defect Management
4. 4
Examples of Defects:
• User gives wrong / incomplete requirements.
• Analyst interprets requirement incorrectly.
• Requirements are not recorded correctly.
• Incorrect design specs
• Incorrect program specs
• Errors in coding
• Data entry errors
• Errors in testing: falsely detect an error / fail to detect existing errors
• Mistakes in error correction
Defect Management
5. 5
Software Bug:
– A fault in a program which causes the program to perform in an un-intended
manner.
Software bug occurs when:
1. The software does not do something that specification says it should do.
2. The software does something that specification says not to do.
Defect Management
6. 6
Error:
1. The stage of system from where further action of system will lead it to
failure.
2. A human action that produces incorrect step, process, result or data
definition.
3. Mistake made by developer
1. Typographical error
2. Misleading of specs
3. A misunderstanding of what module should do
Defect Management
7. 7
Error Contd…:
4. It may be
1. Actual bugs in the code
2. Calculation errors
3. Errors in handling/interpreting data
4. User does not observe operation described in manuals
5. Testing errors
Defect Management
8. 8
Fault:
1. A fault occurs when a human error results in a mistake in some software
product.
2. Difference between incorrect program and the correct versions.
3. A single error can lead to one or more faults.
4. One fault can result in changes to one product or multiple changes to
multiple products.
Defect Management
9. 9
Failure:
1. A fault can go undetected until a failure occurs, which is when a user or
tester perceives that the system is not delivering the expected service.
2. Deviation of the system from its expected behavior.
3. Inability of a system to perform its required functions within specified
performance requirements.
4. Problems identified by end user while using a system is called failure.
Defect Management
11. 11
1. Overview of defect management process.
2. Primary goal is to prevent defects.
3. Should be integral part of development process.
4. As much as possible should be automated.
5. Defect information should be used for process improvements.
6. To prevent defects processes must be altered.
Defect Management
12. 12
Defect /Bug Life Cycle
Tester Finds a defect
(First Time)
Report to Test Lead
Test Lead Review
Defect
Is it is
a valid
Defect
Is it is
in
scope
Is it is
already
raised
NEW
NO
Test Lead Assign
Defect to Dev Team
Once Bug is Assigned
to Dev Team to Fix
Assigned
During Bug Fixing
Open
Bug FixedFixed
Re-
Testing
Re-Open
Fail
Pass
Closed
Rejected
NO
Deferred
NO
Duplicate
YES YES
YES
In Next Version
R
E
G
R
E
S
S
I
O
N
Re-Assigned
Test Lead
14. 14
Defect/ Bug Status:
• The software defect reported by a tester need to be addressed properly, and this
is done with help of a systematic defect life cycle.
• New: The bug is in the “New” state when it is detected first time. The tester
logs the bug with the status as ‘New’ in the defect report.
• Assigned – After review, if the defect is a valid defect, it will be assigned to a
development team to fix.The development lead logs the status as ‘Assigned’
in the defect report.
• Duplicate – If the same defect is already reported by any other tester , defect
can be closed by changing it’s status as ‘Duplicate’.
• Deferred - Though the defect is valid, if the defect is not so important and it
is decided not to fix it and may be fixed in the next version, the status of a
defect is ‘Deferred’.
Defect Management
15. 15
Defect/ Bug Status:
• Open – The developer changes the status as ‘Open’ when he starts fixing the
bug.
• Fixed – Depending of the priority, when the developer will make the
changes to the application to remove the defect, the status of a defect will be
changed as ‘Fixed’ which is reviewed by the development lead and it is
forwarded to the test lead.
• Retested – When the defect is fixed, the application needs to be retested to
check whether the defect is removed or not. The test lead changes the status
as ‘Retest’ and sends it back to the tester to retest to check whether the bug
is fixed.
Defect Management
16. 16
Defect/ Bug Status:
• Closed:
– The tester checks whether the bug is fixed or not. If yes then the status is
changed to ‘Closed’.
• Reopen :
– If the bug is not fixed, the tester changes the status to ‘Reopen’.
• Rejected:
– The test lead reviews the bug, and, if the bug is not valid then the state is
changed to ‘Rejected’.
Defect Management
17. 17
Defect Severity:
– The impact of the defect or serious of the defect in the system is
called severity.
– As tester knows the customer business requirements well, tester is
the right person to specify defects severity.
Defect Management
18. 18
Defect Management
Severity Description Criteria
1
Very High /
Show Stopper
Core dumps, Inability to install/uninstall the product,
Product will not start, Product hangs or Operating
System freezes, No workaround is available, Data
corruption, Product abnormally terminates
2 High
Workaround is available, Function is not working
according to specifications, Severe performance
degradation, Critical to a customer
3 Medium
Incorrect error messages, Incorrect data, Noticeable
performance inefficiencies
4 Low
Misspellings, Grammatical errors, Enhancement
requests. Cosmetic flaws
How to decide severity?
19. 19
Defect priority:
– The order in which the defect has to be resolved is called defect
priority.
– Tester is the right person to specify defect priority.
Defect Management
20. 20
Defect Management
How to decide Priority?
Priority Description Criteria
1 Very High Immediate fix, block further testing, very visible
2 High Must fix before the product is released
3 Medium Should fix if time permits
4 Low Would like fix but can be released as it is.
21. 21
Defect Management
Defect Report Attributes:
1.Defect Id
2.Project Name
3.Module Name
4.Sub-module Name
5.Phase
6.Type
7.Severity
8. Priority
9. Summary/Description
10.Steps to Re-Produce
11.Status
12.Reported by/on
13.Assigned to
14.Cc to
15. Screen Shot
23. 23
Defect Management
Defect Report Advantages:
1. To have a complete record of discrepancies that may be used in
multiple ways.
2. Forms basis for quality measurement.
3. Major purpose
1. Correct the defect
2. Report status of application
3. Gather statistics to predict defects in future applications
4. Process improvement
24. 24
Defect Management
Defect Tracking Tools:
1. Test Director
2. Rational Clear Quest
3. Bugzilla
4. Excel Sheet
5. Quality Center (QC)
6. Application Life Cycle Management (ALM)
25. 25
Review Questions
Severity of the defect depends on the criticality of the
Functionality and Priority depends on the scope of release OR
business.
a) TRUE
b) FALSE
All the ‘severity 1‘ defects should be fixed earlier than the ‘priority
1’ defects.
a) TRUE
b) FALSE
