Defect Management

1
 Defect Management

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.

2
 Defect Management

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.

3
 Defect Management

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

4
 Defect Management

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.

5
 Defect Management

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

6
 Defect Management

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

7
 Defect Management

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.

8
 Defect Management

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.

9
 Defect Management

Error & Fault & Failure:

10
 Defect Management

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.

11
 Defect /Bug Life Cycle
In Next Version

Tester Finds a defect

(First Time)

NEW Rejected Deferred Duplicate

Report to Test Lead NO NO YES

Is it is Is it is Is it is
Test Lead Review a valid in already Test Lead Assign
Defect Defect scope raised
NO
Defect to Dev Team
YES YES

Once Bug is Assigned

Re-Assigned
to Dev Team to Fix

R
E Assigned
G
R
E
S
S During Bug Fixing
I
O Re-Open
N

Fail Open

Pass

Closed Re-
Testing Fixed Bug Fixed

Test Lead 12
 Incident/Defect Management
Defect /Bug Life Cycle
New Tester

Assigned Dev. Lead

Test Lead Reopen Open Developer

Fixed Developer

Retest Test Lead

No
Fixed?

Yes
Close Tester

13
 Defect Management
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’. 14
 Defect Management

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.

15
 Defect Management

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

16
 Defect Management

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.

17
 Defect Management
How to decide severity?

Severity Description Criteria

Core dumps, Inability to install/uninstall the product,

Very High /
1 Show Stopper Product will not start, Product hangs or Operating

System freezes, No workaround is available, Data

corruption, Product abnormally terminates

Workaround is available, Function is not working

2 High according to specifications, Severe performance

degradation, Critical to a customer

Incorrect error messages, Incorrect data, Noticeable

3 Medium
performance inefficiencies

Misspellings, Grammatical errors, Enhancement

4 Low
requests. Cosmetic flaws

18
 Defect Management

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.

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

20
 Defect Management
Defect Report Attributes:
8. Priority
1.Defect Id
9. Summary/Description
2.Project Name
10.Steps to Re-Produce
3.Module Name
11.Status
4.Sub-module Name
12.Reported by/on
5.Phase
13.Assigned to
6.Type
14.Cc to
7.Severity
15. Screen Shot

21
 Defect Management
Defect Report Template:

22
 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

23
 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)

24
 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

25
Question and Answer

26