1

Defect Management

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

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

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

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

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

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

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

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

10

Error & Fault & Failure:

Defect Management

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

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 Fixed Fixed Re-

Testing

Re-Open

Fail

Pass

Closed

Rejected

NO

Deferred

NO

Duplicate

YES YES

YES

In Next Version

REGRESSION

Re-Assigned

Test Lead

13

Incident/Defect Management

New

Assigned

Open

Fixed

Retest

Close

Reopen

Fixed?

Yes

No

Developer

Test Lead

Dev. Lead

Tester

Developer

Tester

Test Lead

Defect /Bug Life Cycle

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

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

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

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

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

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

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

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

22

Defect Management

Defect Report Template:

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

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

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

26

Question and Answer