EXPLAIN DEFECT MANAGEMENT PROCESS

1.Defect identification – Defects are identified through various testing activities, such as unit
testing, integration testing, and user acceptance testing.

2.Defect logging – Defects are logged in a defect tracking system, along with details such as
description, severity, and priority.

3.Defect triage – The triage process involves evaluating the defects to determine their priority
and the resources required to resolve them.

4.Defect assignment – Defects are assigned to developers or testers for resolution, based on their
expertise and availability.

5.Defect resolution – The assigned personnel work on resolving the defects by fixing the code,
updating the documentation, or performing other necessary actions.

6.Defect verification – Once the defect is resolved, it is verified by the tester to ensure that it has
been fixed correctly and does not introduce any new defects.

7.Defect closure – Once the defect has been verified, it is closed and the status is updated in the
defect tracking system.
  Techniques to Identify Defects :

Static Techniques : Static technique, as name suggests, is a technique in which software is tested without
any execution or program or system. In this, software products are tested or examined manually, or with
help of different automation tools that are available, but it’s not executed. Different type of causes of
defects can be found by this technique such as :

Missing requirements

Design defects

Deviation from standards

Inconsistent interface specification

Non-maintainable code

Insufficient maintainability, etc.

Dynamic Techniques : Dynamic technique, as name suggests, is a technique in which software is tested
by execution of program or system. This technique can only be applied to software code as in this
technique, testing is done only by execution of program or software code. Different types of defects can
be found by this technique such as :

Functional defects – These defects arise when functionality of system or software does not work as per
Software Requirement Specification (SRS). Defects that are very critical largely affect essential
functionalities of the system that in turn affect a software product or its functionality. Software product
might not work properly and stop working. These defects are simply related to working of system.

Non-functional defects – A defect in software products largely affects its non-functional aspects. These
defects can affect performance, usability, etc.

Operational Techniques : Operational techniques, as name suggests, are a technique that produces a
deliverable i.e. Product. Then user, customer, or control personnel identify or found defects by inspection,
checking, reviewing, etc. In simple words, defect is found as a result of failure

 What is Severity?
The impact of the bug/defect on the application is known as the severity of blocker defects and what is the
impact of the defect on the whole system’s functionality. The severity is a parameter set by the tester
while opening a bug/defect and is essentially in control of the tester.

 What is the priority?

Priority defines in which order we should resolve a defect. Should we fix it now or later, or can it wait?
This priority status is confirmed by the tester to the developer mentioning the time frame to fix the defect.
If high priority is specified then the developer has to fix it as soon as possible. The priority status is
determined based on the customer’s requirements.
  Types of Severity
There are four different levels of severity.

1. Critical
2. Major
3. Minor
4. Low

 Types of Priority
There are three types of priority

1. High
2. Medium
3. Low

 STEPS TO defect reporting

1. identify the defect
2. describe the defect
3. document action step
4. specify expected and actual result
5. include relevant details
6. add visual proof
7. document date

 A defect report AND TEMPLETES in software testing is a formal document that describes a flaw
or issue in a software application. It is crucial for effective communication between developers, testers, and
other stakeholders. Here’s a detailed breakdown of what a defect report typically includes:

1. Defect ID

 A unique identifier for the defect to facilitate tracking.

2. Summary

 A brief overview of the defect. This should be concise yet descriptive enough to give an immediate understanding of
the issue.

3. Description

 A detailed explanation of the defect. This should include:

o What the expected behavior is.
o What the actual behavior is.
o Steps to reproduce the defect.
o Any specific scenarios or conditions that trigger the defect.
4. Severity

 The impact of the defect on the system, usually categorized as:

o Critical: Causes system failure or data loss.
o Major: Significant functionality is impaired.
o Minor: Minor issues that do not significantly impact the user experience.
o Trivial: Cosmetic issues that do not affect functionality.

5. Priority

 Indicates how soon the defect should be addressed, often categorized as:
o High: Must be fixed immediately.
o Medium: Should be fixed in the next release.
o Low: Can be scheduled for a future release.

6. Environment

 Information about the system where the defect was found, including:
o Operating system
o Browser/version (if applicable)
o Device type (desktop, mobile, etc.)
o Software version/build number

7. Attachments

 Screenshots, logs, or any other relevant files that provide additional context about the defect.

8. Status

 The current status of the defect, which can include:

o New: Defect just reported.
o Assigned: A developer is working on it.
o In Progress: Work on the defect is ongoing.
o Fixed: The defect has been resolved.
o Verified: Testing confirms the defect has been fixed.
o Closed: The defect is no longer relevant or was not reproducible.

9. Reported By

 The name or ID of the person who reported the defect.

10. Date Reported

 The date when the defect was reported.

11. Resolved By

 The name or ID of the developer who addressed the defect.

12. Date Resolved

 The date when the defect was fixed.

13. Comments/Notes

 Additional remarks or updates related to the defect, including any communication between team members.

Importance of a Defect Report

 Clarity: Helps ensure that all team members understand the issue.
 Tracking: Aids in monitoring the status and history of the defect.
 Prioritization: Assists in deciding which defects to address first based on severity and priority.
 Documentation: Serves as a record for future reference and learning.

 Defect prevention in software testing refers to proactive measures taken to identify and
eliminate potential defects before they occur. This process aims to improve software quality and
reduce the cost and effort associated with fixing defects later in the development lifecycle. Here’s
a detailed explanation of the defect prevention process:

1. Requirements Review

 Clear Requirements: Ensure that requirements are well-defined, complete, and understood by all stakeholders.
 Review Sessions: Conduct formal reviews or inspections to catch ambiguities, inconsistencies, and gaps in
requirements.

2. Design Reviews

 Peer Review: Engage team members to review design documents for adherence to requirements and best practices.
 Use of Design Patterns: Encourage the use of established design patterns to avoid common pitfalls.

3. Coding Standards

 Establish Standards: Define coding conventions and best practices for the development team.
 Code Reviews: Implement regular code reviews to ensure adherence to standards and catch potential issues early.

4. Static Code Analysis

 Automated Tools: Use static analysis tools to identify code smells, potential bugs, and security vulnerabilities before
the code is executed.
 Metrics and Reports: Analyze code quality metrics to identify areas for improvement.

5. Test Planning

 Comprehensive Test Plans: Develop detailed test plans that include test cases, test data, and testing strategies
aligned with requirements.
 Risk Assessment: Prioritize testing efforts based on risk analysis, focusing on areas more likely to contain defects.

6. Early Testing

 Shift-Left Testing: Implement testing activities early in the development lifecycle, such as unit testing and integration
testing, to catch defects sooner.
  Continuous Integration: Use continuous integration tools to run automated tests frequently as code changes are
made.

7. Training and Knowledge Sharing

 Skill Development: Provide training for team members on best practices, tools, and techniques for defect prevention.
 Knowledge Sharing: Foster an environment where team members share insights and lessons learned from past
projects.

8. Feedback Loops

 Regular Feedback: Establish regular communication channels among developers, testers, and stakeholders to provide
feedback on processes and deliverables.
 Retrospectives: Conduct retrospectives at the end of iterations to analyze what went well and identify areas for
improvement.

9. Root Cause Analysis

 Analyze Defects: When defects are found, conduct root cause analysis to understand why they occurred.
 Implement Improvements: Use findings to adjust processes, tools, or training to prevent similar defects in the future.

10. Metrics and Monitoring

 Track Defects: Monitor defect rates and types over time to identify patterns that indicate process weaknesses.
 Continuous Improvement: Use metrics to inform ongoing improvements to processes, tools, and training efforts.

Benefits of Defect Prevention

 Cost Efficiency: Reduces the cost associated with fixing defects later in the development lifecycle.
 Higher Quality: Increases overall software quality, leading to better user satisfaction.
 Improved Morale: Creates a more positive work environment, as developers and testers feel more in control of
quality.
 Faster Time to Market: Reduces delays caused by late-stage defect discovery, leading to quicker releases.