UNIT IV : Defect Management

Defect
• Inconsistency in behavior of s/w
• s/w doesn’t meet requirement
• Errors in coding or logic
• Expected result don’t match with actual results.
• Root causes of defects :
• --requirement are not well defined
• -Design or implementation are not proper
• --people are not trained
• Defect management process focuses on:
• --preventing defects.
• --catching defects as early
• --minimizing impact of defects
• Defect classification:
• -- severity wise
• -- error wise
• --status wise
• --work product wise
 Defect classification
• Severity wise: can be decided based on how bad is the
defect.
• -- severity 1 / critical : eg : s/w crash frequently.
• -- severity 2 /major : Operational errors
• --severity 3 / medium :misspelling , UI layout
• --severity 4/ low : Suggestion
• Probability wise : Likelihood of a user encountering the
defect
• -- High : encountered by all the users.
• --Medium : encountered by 50% of the users
• --Low : encountered by very few users.
• Priority Wise : defined order in which the defect should be
resolved
• -- Urgent : must be fix immediately
• -- High : Must fix before product release
• -- Medium : Should fix when time permits
• --Low : whould like to fix but product can be release
•
• Work product wise:
• --SSD (System Study Document)
• --FSD (Functional Specification Document)
• --ADD (Architecture Design Document)
• --Source code
• --Test Plan / Test cases
• --user documentation
• Error wise:
• --comment : incorrect , inadequate
• --computational error
• --logic error
• --interface error
• --Boundary condition neglected
• Status wise:
• --open
• resolved
• --close
• --deferred
• --review
 Defect Management Process
• Objectives :
• --finding defects
• --reducing them at low cost
• 1. defect prevention
• 2. deliverable base line
• 3. defect discovery
• 4. defect resolution
• 5. process improvement
• 1. defect prevention:
• -- a. identify critical risks:
• -- missing key requirements
• -- H/w malfunctioning
• -- performance is poor
• -- b. estimate expected impact:
• -- E= P * I I impact
• P  probability of risk to become real
• -- c. minimizing expected impact:
• --eliminate risk
• -- reduce probability of risk
• -- reduce the impact : eg : disaster recovery plan for reducing
impact of data loss
• 2. deliverable base line:
• --deliverables is a base lined when it reaches a predefined mile stone in its
development
• Milestone involve transferring the product from one stage to next
• Baseline refers to a predefined benchmark which when reached
determine next step to be taken.
• As work product moves from one stage to next , defect in the deliverable
have large impact on rest of system and making changes become
expensive.
• Defect is an instance of baselined product , not satisfying given set of
rqmts.
– Thus error caught before deliverable baselined would not be considered defects.
• If component is baselined and defect found then it can not proceed
further till bug is fixed
• 3. defect discovery:
• --defect is said to be discovered when documented and
acknowledged as valid defect from developer side
• --find defect
• --report defect
• --acknowledge defect
• Organization should predefine defects by category.
– identify defect and then get an agreement that they are
defects.
– The objective is to minimize conflicts over the validity of
defects.
• 4. defect resolution:
• --done by developer
• -- prioritize defect : critical , major , minor
• --schedule to fix: based on priority, defect fix should be
scheduled
• --fix defect: correcting deliverables .
• --report resolution: developer response back to tester
• 5. process improvement:
• --identify and analysis of process in which a defect originated
• -- improve process to prevent future occurrence of similar
defects.
 Defect bug life cycle
• It start when defect is found and end when a
defect is closed.
• Bug has different states in the life cycle.
BUG FOUND

OPEN REVIEW

RESOLVED

CLOSED DEFFERED
• OPEN: when bug found by tester
• OPEN-RESOLVED : once programmer fixes the code
• RESOLVED-CLOSED : tester close the bug after verifying
• OPEN-REVIEW : CCB decide whether the bug should be fixed or not
• REVIEW- CLOSED : CCB decide that bug is not a real problem
• REVIEW-DEFERRED: CCB decide that bug should be fix in future ,
but not for this release of the s/w
• REIEW-OPEN: CCB decide that bug should be fix.
• RESOLVED – OPEN : tester find bug is not fix
• CLOSED – OPEN : bug may occur in future
• DEFERRED – OPEN: bug has to be fix in future.
Defect template
 Defect Template
• 4 sections:
• 1.section : tester report
• -Defect id , Defect name , Date , Tester
• -Severity (1,2,3,4), Priority (1,2,3,4),
• -Description
• 2.section: Developer report
• -resolution(defect state)
• -resolved date , version , resolved by , comment
• 3.section : retesting report
• - retested by , version tested , comment
• 4.section: Signature
 Severity : 1.Critical 2.Major 3.medium 4.low
Priority : 1. Critical 2.high 3.medium 4.low

• Example:
• 1.s/w crashes as soon as you start
• Severity -1 priority – 1

• 2. tester thing that button should be moved little down

on the page.
• Severity – 4 Priority – 4

• 3.misspelling in the setup instruction.

• Severity – 3 Priority - 2
 Estimate Expected impact of a defect
• What loss will be suffered by a user in case of
occurrence of risk.
• Estimation my be done by different methods to
find probability of risk occurrence. send impact
when it become real.
• Some organization categories impact as high ,
medium and low.
• Some organization calculate risk on the basis of
money value of the loss
 Way to handle risk
• 1.accept the risk as it is :
• Some risk may not have any solution like natural
disasters.
• These type of risk may be accepted by organization
• They make fallback arrangement , but may not define
ways to eliminate risks.
• This make team well prepared to accept the risk
• Customer are given information about probable
failures and effect of such failure. (called accident
prone zone)
• 2. by passing the risk:
By pass risk by avoiding the particular
approach.
• It required when the risk faced by user cannot
be accepted or no action can be taken to
reduce probability or impact.
 Minimize risk impact
• 1.eliminate risk :taking steps to remove risk from
root cause.
• 2. mitigation of risk: action taken by organization to
minimize possible damage .
• 3.detection ability improvement: people are aware
of the risk , they can be well prepared to handle
• 4.contingency planning: actions initiated by an
organization , when preventive and corrective
actions fails and risk actually occurs
 Techniques of finding defects
• 1. static techniques:
• Testing is done without physically executing a program.
• Eg:reviews
• 2.dynamic techniques: physical execution
• Eg : test cases execution
• 3.operational techniques: defect is found as a result of a
failure.
• Operational techniques typically include auditing work
products and projects to understand whether the processes
defined for development are revisiting the defects
 Defect reporting
• Discovered defect must be brought to the
developers attention.
• Guidelines while reporting :
• 1.be specific:
• --don’t say anything which add confusion.
• --in case of multiple paths , mention exact
path
• --be detailed : provide more information
• Be objective: stick to fact and avoid emotions
• Reproduce the defect:
• -- don’t be impatient .
• --replicate it at least once more
• -- state exact test condition
• Review the report