Defect Management (12 Marks)

Topic/Sub Topic

1. Defect classification

2. Defect management process

3. Defect Life cycle

4. Defect Template

5. Estimated expected impact of the defect

6. Techniques for finding defect

7. Reporting defect

Define Defect
A Software Defect / Bug is a condition in a software product which does not meet a software
requirement or end-user expectations .

OR

Defect is an error in coding or logic that causes a program to malfunction or to produce

incorrect/unexpected results.

Explain defect classification with an example.

Defect Classification

Defect Classification: Requirement/Specification Defects

• Requirement related defects arise in a product when one fails to understand what is required by
the customer.
• These defects may be due to customer gap, where the customer is unable to define his
requirements

• Producer gap, where developing team is not able to make a product as per requirements.

• Requirements/Specification documents are written using natural language representation, there

are very often occurrences of ambiguous, contradictory, unclear, redundant and imprecise
requirements.

Requirement/Specification Defects: Functional Defects

Requirement/Specification Defects: Feature Defects

Requirement/Specification Defects: Interface Defects

Defect Classification: Design Defects

• Design defects occur when system components, interactions between system components,
interactions between the outside software/hardware, or users are incorrectly designed.

• This covers in the design of algorithms, control, logic/ data elements, module interface
descriptions and external software/hardware/user interface descriptions.

• Design defects generally refer to the way of design creation or its usage while creating a product.
Design Defects: Algorithmic Defects

Design Defects: Module Interface Defects

Design Defects: System Interface Defects

Design Defects: User Interface Defects

Defect Classification: Coding Defects

Coding Defects: Variable declaration /Initialization Defects

Coding Defects: Database related Defects

Coding Documentation /Commenting Defects

Defect Classification: Testing Defects

Testing : Test Case Design Defects.

These would encompass incorrect, incomplete, missing inappropriate test cases and test procedures.

Testing : Test Environment Defects.

Testing : Test tool Defects.

Explain Defect Management Process with suitable diagram.

Defect Management Process

• Defects found during Verification and validation process in SDLC must be recorded so that it helps
in further analysis and root causes of the defect.

• The defects found during these phases are used to find weak areas of project /process so that
action can be initiated to strengthening it.

Defect Management Process :Prevention

• It is a process of improving quality and productivity by preventing the defects into a software
product.

• It is virtually impossible to eliminate the defects altogether.

• Implementation of techniques, methodology and standard processes are used to reduce the risk of
defects.
• Defect prevention is intended to remove the possibility of any defects before it occurs.

Defect Management Process :Deliverable Baselining

• Once the defect is fixed, retested and found to be closed, the product is created again .

• If the newly created product satisfies the acceptance criteria, it is base lined.

• Only base lined work products can go to the next stage.

Defect Management Process : Defect Discovery

• A defect is said to be discovered when it is brought to the attention of the developers and
acknowledged (i.e., “Accepted”) to be valid one.

• Team should find defects before they become major problems. As soon as team finds the defects,
they should report them so that those can be resolved.

• Team should also make sure that defects should be acknowledged by developers and should be
valid one.

Defect Management Process : Defect Resolution

• Work by the development team to prioritize, schedule and fix a defect, and document the
resolution.

• This also includes notification back to the tester to ensure that the resolution is verified.

Defect Management Process :Process Improvement

• All problems are due to failure in the process involved in creating software.

• Defects gives an opportunity to identify the problem with process used and update them.

• Better processes mean better product with less defect.

Defect Management Process :Management Reporting

• Analysis and reporting of defect information to assist management with risk management, process
improvement and project management.
Explain defect life cycle diagram and different states.
Defect Life Cycle

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

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

Assign: Once the lead changes the state as “OPEN”, he assigns the bug to corresponding developer
or developer team. The of the bug now is changed to “ASSIGN”.

Test/Retest: Once the developer fixes the bug, he must 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”.

Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases.

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

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

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.

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

Fixed: When developer makes necessary code changes and verifies the changes then he/she can
make bug status as “Fixed‟ and the bug is passed to testing team.

Pending retest: After fixing the defect the developer has given that code for retesting to the tester.
Here the testing is pending on the testers end. Hence its status is pending retest.
Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then
one bug status is changed to “duplicate“.

Not a bug: The state given as “Not a bug” there is no change in the functionality of the application.
For an example: If customer asks for some change in the look and field of the application like change

Mention defect report template.

Describe defect template with its attribute.
write example for defect template
(Refer manual for example)

Defect Template
Severity

• Severity: Your bug report will also include Severity, which describes the impact of the defect on
the application.

• Severities may be ‘critical, high, medium or low depending on the impact of a defect. Severity
definitions may be as follows:

• 1. S1= Defect where an application fails or particular functionality is completely missing. There is
no work around available.

• 2. S2= Defect where functionality is not available but work around is possible. This may make
customer unhappy but alternate way to achieve same result does exist. 3.

• S3= Defects of very minor nature (such as cosmetic defects) are in this category. Spelling mistakes,
color and font mismatch may be put under least severity defects.

Priority

• Priority is defined based on how the project decides a schedule to take the defects for fixing.

• It is defined based on how many times the defect can be seen by normal users under normal
circumstances, or how many customers are being affected due to this.

• Priority which is related to defect fixing urgency. Priority could be High/Medium/Low based on the
impact urgency at which the defect should be fixed, respectively.

• Priority definitions are:

1. P1= Defects having highest probability of affecting the customer. Either it affects most of the
users or it appears at a place where maximum users will be visiting.

2. P2= Defects having lesser probability of affecting customer than P1 defects. They

may be appearing in circumstances and hitting customer at fewer instances.

3. P3= Defects having minimum probability of affecting customer.

Estimate Expected Impact of a Defect

• Actual impact of a defect can be measured when the risk realizes or becomes a reality in
production environment.

• Estimation may be done by different methods/approaches to find the probability of risk

occurrence and impact when it becomes reality.

• Some organizations categories risk impact as high, medium and low.

Ways to handle risk

Accept the Risk as It Is:

• Some risks may not have any solutions. e.g., natural disasters.

• The actions to reduce the probability and/or impact of certain risks may be very costly; hence the
organization may not be able to implement them.
• These risks may be accepted by the organization as it is. Such decisions are generally taken by the
senior management.

• They may prepare a fallback arrangement but may not define the ways ofminimizing/eliminating
risks.

• This makes a team psychologically prepared to accept the risk so that the impact on the
organization/project/user can be reduced to some extent.

• Listing of known issues or defects in the product indicates acceptance of risk by the management.

• Customer user are given information about probable failures and effect of such failures.

• This is a methodology of declaring ‘accident prone zone’ to users.

Bypassing the Risk:

• lf the approach is very risky to the users/customer, the management may decide to bypass the risk
by avoiding the approach.

• Bypassing of risk is required when the risk faced by the user cannot be accepted, or no action can
be taken to reduce probability/impact arising due to realization of risk.

Minimize Risk Impact or Probability

• Risk is a product of probability, impact, and detection ability.

• Risk minimization has three different methods of handling its probability, impact, or detection
ability.

• The decisions may be driven by organization policy, values, cost-benefit analysis etc..

State how to minimize risk impact while estimating defect.

Ways of Minimization of problem due to risk

Eliminate Risk:

• Elimination of risk involves taking steps to remove risk from the root.

• Risk's probability is reduced to almost ‘0’ by removing the causes of risk, so that the risk must not
happen at all.

• Organization user may be protected from the possible losses arising due to risk.

• Preventive controls can eliminate the probability of risk to a large extent.

• Preventive controls are management-decided controls.

• Preventive controls are applied if the probability of occurrence is very high.

• Preventive controls are useless if the probability of happening is already negligible.

Mitigation of Risk
• Actions initiated by an organization to minimize the possible damage due to realization of risk are
considered mitigation actions.

• Mitigation actions are planned by an organization/project so that if the risk is realized, the impact
due to it can be reduced to minimum possible.

• The corrective controls used from the mitigation action.

• Corrective controls may be auto corrective or suggestive.

Detection Ability Improvements:

• Impact of a risk is more if it catches the user unprepared.

• If people are aware of the risks, they can be well prepared to handle them.

• Generally, detective controls are used to increase the visibility towards risks. Sometimes, detective
controls give threshold to corrective controls.

Contingency Planning:

• Contingency planning refers to the actions initiated by an organization, when preventive or

corrective actions fail, and risk occurs.

• They are previously planned ways of tackling risks when all other planned activities for reducing
probability and impact of the risk fail, and the risk becomes reality.

Enlist different techniques for finding defects and describe any one technique
with an example.

Techniques for finding defect

Techniques for finding defect-→Static Techniques

❖ Testing that is done without physically executing a program or system.

❖ No execution of code, product, documentation.

❖ Helps in establishing conformance to requirements view

❖ Checking the software product and related artifacts without executing them.

❖ The work product is reviewed by the reviewer with the help of a checklist, standards, any other
artifact, knowledge, and experience, to locate the defect with respect to the established criteria.

❖ It may include reviews, walkthroughs, inspection, and audits.

Techniques for finding defect -→Dynamic Techniques

❖ Testing in which system components are physically executed to identify defects.

❖ Execution of test cases is an example of a dynamic testing technique.

❖ Dynamic testing is a validation technique which includes dummy or actual execution of work
products to evaluate it with expected behaviour.

❖ It includes black box testing methodology such as system testing.

❖ The testing methods evaluate the product with respect to requirements defined; designs created
and mark it as ‘pass’ or ‘fail’.

❖ This technique establishes ‘fitness for use’ view.

Techniques for finding defect -→Operational Techniques

❖ Operational system produces a deliverable containing a defect found by users, customers, or

control personnel . i.e., the defect is found because of a failure. .

❖ Operational techniques typically include auditing work products and projects.

❖ To understand whether the processes defined for development/testing are being followed
correctly or not, and whether they are effective or not.

❖ It also includes revisiting the defects before and after fixing and analysis.

❖ Operational technique may include smoke testing and sanity testing of a work product.

Reporting a Defect

• Defect finding and reporting are the important steps in software development life cycle.

• When we find defect, analyses it, take corrective and preventive actions for further steps. Points
for defects reporting are:
• Give Complete Record of Discrepancies:

• Complete description of a defect indicates the symptom observed by the tester.

• when the defect is located, corrective actions and preventive actions.

• Project manager must conduct complete analysis of how the defect occurred and what was not
done correctly.

• They should perform root-cause analysis to identify and correct the defect and responsible
processes which have resulted into the defect.

• Defect finding must lead to process improvement.

Defect management may go through the following stages:

Correct the Defect:

• Correcting the defect logged by the reviewer/tester in verification/validation during software

development life cycle

• It is the primary activity done by the author or developer responsible for defect fixing.

• Corrected detect may undergo review, unit testing and retesting.

• In case it is not possible to correct the defect or it is not advisable to do so, it may be noted as

known issue in release note.

Report Status of System:

• The status of system with respect to organizational standards and acceptance criteria fulfilment

can be assessed through status reporting.

• Number of defects found and fixed is a major measurement to establish the status of software.

• It helps in informing users, customer, and management about the readiness of an application for

delivery.

• Requirements of any efforts needed for fixing them, and any level of retesting and regression

testing required.

Gather Statistics to Predict Future:

• Defect statistics is used by an organization to plan corrective and preventive actions (CAPA) at

project/organizational level.

• It can be used for benchmarking a product as well as an organization and assessing the quality

improvement programs initiated by the organization.

• Matured organizations use defect calculators for predicting future and initiate actions to improve

the process capabilities.

Process Improvement:

• Testing is not the most efficient way of improving software quality.

• Verification and validation activities are costly.

• Finding and fixing defects cannot improve quality of software as well as productivity of team.

• An organization must stress on quality improvement programs through process improvements to

ensure that defects are not introduced in the system