UNIT – IV DEFECT MANAGEMENT

What is Bug?
A bug is the consequence/outcome of a coding fault

What is Defect?
➢ A defect is a variation or deviation from the original business requirements
➢ These two terms have very thin line of difference, In the Industry both are faults that need
to be fixed and so interchangeably used by some of the Testing teams.
➢ When a tester executes the test cases, he might find that actual result vary from expected
results.
➢ This variation in the test result is referred as a Software Defect.
➢ These defects or variation are referred by different names in a different organization
like issues, problem, bug or incidents.
➢ In case you find a defect , What information you will convey to the developer to help him
understand the defect
➢ While reporting the bug to developer, your Bug Report should contain the following
information

Enlist any six attributes of defect. Describe them with suitable example.

Defect has following attributes:

Any six of the following attributes shall be considered
1) Defect ID: Identifies defect as there are many defects might identified in system.
a. i.e. D1, D2, etc.
2) Defect Name: Name of defect which explains the defect in brief.
a. It must be short but descriptive. i.e. Login error.
3) Project Name: Indicates project name in which defect is found
4) Module /Sub-module name: for which the defect is found.
5) Phase introduced: Phase of life cycle to which the defect belongs to.
6) Phase found: Phase of project when the defect is found is added here. It is used to find defect
leakage or stage.

Prof. Mrs Seema Kaimal Page 1

UNIT – IV DEFECT MANAGEMENT
7) Defect type: Defines defect type. i.e. security defect, functional defect, GUI defect etc.
8) Severity: Declared in test plan, i.e. high medium or low.
9) Priority: defines on the basis of how the project decides a schedule to take the defects for fixing.
10) Summary: Describes short about the defect.
11) Description: Describes it in detail.
12) Status: dynamic field, open, assigned, resolved, closed, hold, deferred, or reopened, etc.
13) Reported by/ Reported on: Who found defect, and on what date.
14) Assigned to: The tester is being assigned to some testing team member.

Prof. Mrs Seema Kaimal Page 2

UNIT – IV DEFECT MANAGEMENT
Sample bug report : Application product Bug report sample
Application testing scenario:
Lets assume in your application you want to create a new user with his/her information, for that
you need to logon into the application and navigate to
USERS menu > New User, then enter all the details in the User form like, First Name, Last
Name, Age, Address, Phone etc. Once you enter all these need to click on SAVE button in order
to save the user and you can see a success message saying, “New User has been created
successfully”.
Now you entered into your application by logging in and navigate to USERS menu > New user,
entered all the information and clicked on SAVE button and now the application crashed and you
can see one error page on the screen, now you would like to report this BUG.
Now here is how we can report bug for above scenario:
Bug Name: Application crash on clicking the SAVE button while creating a new user.
Bug ID: The BUG Tracking tool will automatically create it once you save this.
Area Path: USERS menu > New Users
Build Number:/Version Number 5.0.1
Severity: HIGH (High/Medium/Low)
Priority: HIGH (High/Medium/Low)
Assigned to: Developer-X
Created By: Your Name
Created On: Date
Reason: Defect
Status: New/Open/Active – Depends on the Tool you are using
Environment: Windows 2003/SQL Server 2005
Description:
Application crash on clicking the SAVE button while creating a new user, hence unable to create
a new user in the application.
Steps To Reproduce:
1) Logon into the application

Prof. Mrs Seema Kaimal Page 3

UNIT – IV DEFECT MANAGEMENT
2) Navigate to the Users Menu > New User
3) Filled all the fields
4) Clicked on ‘Save’ button
5) Seen an error page “ORA1090 Exception: Insert values Error…”
6) See the attached logs for more information
7) And also see the attached screenshot of the error page.
Expected: On clicking SAVE button should be prompted to a success message “New User has
been created successfully”.
Save the defect/bug in the BUG TRACKING TOOL.

Defect Management Process

Major steps involved in the Defect Management Process are:

#1) Defect Prevention:

Defect Prevention the best method to eliminate the defects in the early stage of testing instead of
finding the defects in the later stage and then fixing it. This method is also cost effective as the
cost required for fixing the defects found in the early stages of testing is very low. However, it is
not possible to remove all the defects but at least you can minimize the impact of the defect and
cost to fix the same.

The major steps involved in Defect Prevention are as follows:

Prof. Mrs Seema Kaimal Page 4

UNIT – IV DEFECT MANAGEMENT

• Identify Critical Risk: Identify the critical risks in the system which will impact more if
occurred during testing or in the later stage.
• Estimate Expected Impact: For each critical risk, calculate how much would be the
financial impact if the risk actually encountered.
• Minimize expected impact: Once you identify all critical risks, take the topmost risks
which may be harmful to the system if encountered and try to minimize or eliminate the
risk. For risks which cannot be eliminated, it reduces the probability of occurrence and its
financial impact.

#2) Deliverable Baseline:

• When a deliverable (system, product or document) reaches its pre-defined milestone then
you can say a deliverable is a baseline. In this process, the product or the deliverable moves
from one stage to another and as the deliverable moves from one stage to another, the
existing defects in the system also gets carried forward to the next milestone or stage.
• For Example, consider a scenario of coding, unit testing and then system testing. If a
developer performs coding and unit testing then system testing is carried out by the testing
team. Here coding and Unit Testing is one milestone and System Testing is another
milestone.
• So during unit testing, if the developer finds some issues then it is not called as a defect as
these issues are identified before the meeting of the milestone deadline. Once the coding
and unit testing have been completed, the developer hand-overs the code for system testing
and then you can say that the code is “baselined” and ready for next milestone, here, in
this case, it is “system testing”.
• Now, if the issues are identified during testing then it is called as the defect as it is identified
after the completion of the earlier milestone i.e. coding and unit testing.

Prof. Mrs Seema Kaimal Page 5

UNIT – IV DEFECT MANAGEMENT
• Basically, the deliverables are baselined when the changes in the deliverables are finalized
and all possible defects are identified and fixed. Then the same deliverable passes on to the
next group who will work on it.

#3) Defect Discovery:

• It is almost impossible to remove all the defects from the system and make a system as a defect-
free one. But you can identify the defects early before they become costlier to the project. We can
say that the defect discovered means it is formally brought to the attention of the development team
and after analysis of that the defect development team also accepted it as a defect.
• Steps involved in Defect Discovery are as follows:

• Find a Defect: Identify defects before they become a major problem to the system.
• Report Defect: As soon as the testing team finds a defect, their responsibility is to make the
development team aware that there is an issue identified which needs to be analyzed and fixed.
• Acknowledge Defect: Once the testing team assigns the defect to the development team, its the
development team’s responsibility to acknowledge the defect and continue further to fix it if it is a
valid defect.

#4) Defect Resolution:

• In the above process, the testing team has identified the defect and reported to the development
team. Now here the development team needs to proceed for the resolution of the defect.
• The steps involved in the defect resolution are as follows:

• Prioritize the risk: Development team analyzes the defect and prioritizes the fixing of the defect.
If a defect has more impact on the system then they make the fixing of the defect on a high priority.
• Schedule and Fix the defect: Based on the priority, the development team fixes the defect, higher
priority defects are resolved first and lower priority defects are fixed at the end.

Prof. Mrs Seema Kaimal Page 6

UNIT – IV DEFECT MANAGEMENT
• Report the Resolution: Its the development team’s responsibility to ensure that the testing team is
aware when the defects are going for a fix and how the defect has been fixed i.e. by changing one
of the configuration files or making some code changes. This will be helpful for the testing
team to understand the cause of the defect.

#5) Process Improvement:

• Though in the defect resolution process the defects are prioritized and fixed, from a process
perspective, it does not mean that lower priority defects are not important and are not
impacting much to the system. From process improvement point of view, all defects
identified are same as a critical defect.
• Even these minor defects give an opportunity to learn how to improve the process and
prevent the occurrences of any defect which may impact system failure in the future.
• Identification of a defect having a lower impact on the system may not be a big deal but
the occurrences of such defect in the system itself is a big deal.
• For process improvement, everyone in the project needs to look back and check from where
the defect was originated.
• Based on that you can make changes in the validation process, base-lining document,
review process which may catch the defects early in the process which are less expensive.

Management Reporting

• It is important that the defect information, which is a natural by-product of the defect
management process, be analyzed and communicated to both project management and
senior management.
• This could take the form of defect rates, defect trends, types of defects, failure costs, etc.
• From a tactical perspective, defect arrival rate (rate at which new defects are being
discovered) is a very useful metric that provides insight into a project's likelihood of
making its target date objectives.
• Defect removal efficiency is also considered to be one of the most useful metrics, however
it can not be calculated until the system is installed.

Prof. Mrs Seema Kaimal Page 7

UNIT – IV DEFECT MANAGEMENT
• Defect removal efficiency is the ratio of defects found prior to product operation divided
by the total number of defects found in the application.

Information collected during the defect management process has a number of purposes:

➢ To report on the status of individual defects.

➢ To provide tactical information and metrics to help project management make more
informed decisions -- e.g., redesign of error prone modules, the need for more testing, etc.
➢ To provide strategic information and metrics to senior management -- defect trends,
problem systems, etc.
➢ To provide insight into areas where the process could be improved to either prevent defects
or minimize their impact.
➢ To provide insight into the likelihood that target dates and cost estimates will be achieved.
➢ Management reporting is a necessary and critically important aspect of the defect
management process, but it is also important to avoid overkill and ensure that the reports
that are produced have a purpose and advance the defect management process.
➢ The basis for management reporting should be the information collected on individual
defects by the project teams. Thus the information collected during the defect management
process and the classification of individual defects needs to be considered by each
organization.
Conclusion
➢ The Defect Management Process should be followed during the overall software
development process and not only for specific testing or development activities.
➢ If a defect found in the testing phase then a question can be raised that if the defect is caught
in this phase then what about the other defects that are alive in the system which may cause
system failure if it occurs and is not yet discovered.
➢ So all processes like review process, static testing, inspection, etc., need to strengthen and
everyone in the project should be serious about the process and contribute wherever
necessary. Senior management in the organization should also understand and support the
defect management process.

Prof. Mrs Seema Kaimal Page 8

UNIT – IV DEFECT MANAGEMENT
➢ Testing approaches, review process etc., should choose based on the project objective or
organizational process.

DEFECT MANAGEMENT PROCESS

Describe steps in Defect Management Process. (Diagram-2Marks, Explanation-4Marks)

1. Defect Prevention: Implementation of techniques ,methodology and standard processes to

reduce the risk of defects.
2. Deliverable Baseline: Deliverables are considered to be ready for further development.i.e.
the deliverables meet exit criteria.
3.Defect Discovery: To find the defect through the process of verification and validation.
4.Defect Resolution: Defect is corrected or corrective action is taken and notification is given
to tester.
5.Process Improvement: To identify ways to improve the process to prevent further future
occurrences of similar defects. i.e. Corrective and preventive action is taken for processes
improvement.
Management Reporting: Reporting is about status of application and processes.

Bug Life Cycle or Defect Life Cycle:

Bug life cycle is also known as Defect life cycle. In Software Development process, the bug has a
life cycle. The bug should go through the life cycle to be closed. Bug life cycle varies depends
upon the tools (QC, JIRA etc.,) used and the process followed in the organization.

Prof. Mrs Seema Kaimal Page 9

UNIT – IV DEFECT MANAGEMENT
What is a Software Bug?

Software bug can be defined as the abnormal behavior of the software. Bug starts when the defect
is found and ends when a defect is closed, after ensuring it is not reproduced.

“Bug Life Cycle / Defect Life Cycle”

The different states of a bug in the bug life cycle are as follows:
New: When a tester finds a new defect. He should provide a proper Defect document to the
Development team to reproduce and fix the defect. In this state, the status of the defect posted by
tester is “New”
Assigned: Defects which are in the status of New will be approved (if valid) and assigned to the
development team by Test Lead/Project Lead/Project Manager. Once the defect is assigned then
the status of the bug changes to “Assigned”

Prof. Mrs Seema Kaimal Page 10

UNIT – IV DEFECT MANAGEMENT
Open: The development team starts analyzing and works on the defect fix.
Fixed: When a developer makes the necessary code change and verifies the change, then the status
of the bug will be changed as “Fixed” and the bug is passed to the testing team.
Test: If the status is “Test”, it means the defect is fixed and ready to do test whether it
is fixed or not.
Verified: The tester re-tests the bug after it got fixed by the developer. If there is no
bug detected in the software, then the bug is fixed and the status assigned is “verified.”

Closed: After verified the fix, if the bug is no longer exits then the status of bug will be
assigned as “Closed.”
Reopen: If the defect remains same after the retest, then the tester posts the defect using
defect retesting document and changes the status to “Reopen”. Again the bug goes
through the life cycle to be fixed.
Duplicate: If the defect is repeated twice or the defect corresponds the same concept of
the bug, the status is changed to “duplicate” by the development team.
Deferred: In some cases, Project Manager/Lead may set the bug status as deferred.
If the bug found during end of release and the bug is minor or not important to fix
immediately
If the bug is not related to current build
If it is expected to get fixed in the next release
Customer is thinking to change the requirement
In such cases the status will be changed as “deferred” and it will be fixed in the next
release.
Rejected: If the system is working according to specifications and bug is just due to
some misinterpretation (such as referring to old requirements or extra features) then
Team lead or developers can mark such bugs as “Rejected”

Prof. Mrs Seema Kaimal Page 11

UNIT – IV DEFECT MANAGEMENT

Some other statuses are:

Cannot be fixed: Technology not supporting, Root of the product issue, Cost of fixing
bug is more
Not Reproducible: Platform mismatch, improper defect document, data mismatch,
build mismatch, inconsistent defects
Need more information: If a developer is unable to reproduce the bug as per the steps
provided by a tester then the developer can change the status as “Need more
information’. In this case, the tester needs to add detailed reproducing steps and assign
bug back to the development team for a fix. This won’t happen if the tester writes a
good defect document.
This is all about Bug Life Cycle / Defect Life Cycle.

Testing tools
Testing tool logo Used
Selenium: Selenium is the most popular automated testing
tool. It supports Automation Testing of web based
applications, wide range of platforms and browsers.

qTest:

TestLink: TestLink is a web-based test management tool

which facilitates software quality assurance.

Practitest: PractiTest is an end-to-end test management tool for

all QA stakeholders, it enables full visibility into the

Prof. Mrs Seema Kaimal Page 12

UNIT – IV DEFECT MANAGEMENT
testing process and a deeper understanding of testing
results.
Zephyr: Zephyr is the #1 selling testing tool, providing end-
to-end solutions for agile teams of all sizes.

Automated Testing Tools

Squish Squish is the GUI Test Automation tool

QTP: Quick Test Professional (QTP) is an automated

functional GUI testing tool

Watir: Waitr is an open-source cross-platform web

application testing tool

TestComple TestComplete is an automated test management

te: tool which helps to increase efficiency and
reduce the cost of the testing process.

Webload: WebLOAD is an excellent testing tool which

offers many powerful scripting capabilities, that
is helpful for testing complex scenarios.

Prof. Mrs Seema Kaimal Page 13

UNIT – IV DEFECT MANAGEMENT
Loadrunner It is a load testing tool for Windows and Linux,
which allows testing the web application
efficiently. It to determines the performance and
result of the web application under heavy load.

Wapt: Wapt is a load, and stress testing tool works for

all Windows. It provides an easy and cost-
effective way to test all types of websites

Defect Tracking Tools

JIRA JIRA is a defect tracking tool which is used for defect/issue
tracking as well as project management. This tool is not only
used for recording, reporting but also integrated directly with
code development environment.

FogBugz The FogBugz is a tracking tool which can be used to track the
status of defects and changes in ongoing software projects,
such as application development and deployment

Bugzilla Bugzilla is one of the best defect Tracking System. The tool allows
individual or groups of developers to keep track of outstanding bugs
in their system. It is the best open source software used in the
market by small scale as well as large- scale organizations

Prof. Mrs Seema Kaimal Page 14

UNIT – IV DEFECT MANAGEMENT
BugNet BugNet is open source Bug Finding Tool. It is a cross-platform
application that is written using an ASP.NET platform, and it
needs MySQL database as backend tool. The main objective of
this defect tracking tool is to make codebase simple and easy to
deploy

Bug Genie It is an open source, web-based bug tracking software.

Appium Appium is an open source test automation tool for mobile

applications

RedMine Redmine is another important defect tracing tool.

Techniques to find defects can be divided into three categories:

Static techniques: Testing that is done without physically executing a program or system.
Example : A code review
Dynamic techniques: Testing in which system components are physically executed to identify
defects. Example : Execution of test cases is an example of a dynamic testing technique.
Operational techniques: An operational system produces a deliverable containing a defect found
by users, customers, or control personnel -- i.e., the defect is found as a result of a failure.
The research did arrive at the following conclusions:
• Both static and dynamic techniques are required for an effective defect management
program. In each category, the more formally the techniques were integrated into the
development process, the more effective they were.
• Since static techniques will generally find defects earlier in the process, they are more
efficient at finding defects.

Prof. Mrs Seema Kaimal Page 15

UNIT – IV DEFECT MANAGEMENT
What are different techniques for finding defects? Explain in detail.

Different techniques to find the defects are :

a) Quick Attacks:

b) Equivalence and Boundary Conditions

c) Common Failure Modes

d) State-Transition Diagrams

e) Use Cases

f) Code-Based Coverage Models

g) Regression and High-Volume Test Techniques

a) Quick Attacks:

·The quick-attacks technique allows you to perform a cursory analysis of a system in a very
compressed timeframe.
Even without a specification, you know a little bit about the software, so the time spent is also
time invested in developing expertise.

b) Equivalence and Boundary Conditions:

Boundaries and equivalence classes give us a technique to reduce an infinite test set into something
manageable.
They also provide a mechanism for us to show that the requirements are "covered".

c) Common Failure Modes:

• The heart of this method is to figure out what failures are common for the platform,
the project, or the team; then try that test again on this build.
• If your team is new, or you haven't previously tracked bugs, you can still write down
defects that "feel" recurring as they occur—and start checking for them.

Prof. Mrs Seema Kaimal Page 16

UNIT – IV DEFECT MANAGEMENT
• The more your team stretches itself (using a new database, new programming language,
new team members, etc.), riskier the project will be—and, at the same time, the less
valuable this technique will be.

d) State-Transition Diagrams:

• Mapping out the application provides a list of immediate, powerful test ideas.
• Model can be improved by collaborating with the whole team to find "hidden"
states— transitions that might be known only by the original programmer or
specification author.
• Once you have the map, you can have other people draw their own diagrams, and
then compare theirs to yours.
• The differences in those maps can indicate gaps in the requirements, defects in the
software, or at least different expectations among team members.
• The map you draw doesn't actually reflect how the software will operate; in other
words, "the map is not the territory."
• Drawing a diagram won't find these differences,
Like just about every other technique on this list, a state-transition diagram can be helpful, but
it's not sufficient by itself to test an entire application.

e) Use Cases:

Use cases and scenarios focus on software in its role to enable a human being to do something.
Use cases and scenarios tend to resonate with business customers, and if done as part of the
requirement process, they sort of magically generate test cases from the requirements.

f) Code-Based Coverage Models:

• Imagine that you have a black-box recorder that writes down every single line of code as
it executes. Programmers prefer code coverage. It allows them to attach a number— an

Prof. Mrs Seema Kaimal Page 17

UNIT – IV DEFECT MANAGEMENT
actual, hard, real number, such as 75%—to the performance of their unit tests, and they can
challenge themselves to improve the score.
• Customer-level coverage tools are expensive, programmer-level tools that tend to assume
the team is doing automated unit testing and has a continuous-integration server and a fair
bit of discipline.
• After installing the tool, most people tend to focus on statement coverage—the least
powerful of the measures.

g) Regression and High-Volume Test Techniques:

o People spend a lot of money on regression testing, taking the old test ideas
described above and rerunning them over and over.
o This is generally done with either expensive users or very expensive programmers
spending a lot of time writing and later maintaining those automated tests.
. Weaknesses
o Building a record/playback/capture rig for a GUI can be extremely expensive, and
it might be difficult to tell whether the application hasn't broken, but has changed
in a minor way.
What are the points considered while estimating impact of a defect? Also explain
techniques to find defect.
• Estimate Expected Impact of a Defect, Techniques for Finding Defects, Reporting a
Defect.
• Once the critical risks are identified, the financial impact of each risk should be
estimated. This can be done by assessing the impact, in dollars, if the risk does become
a problem combined with the probability that the risk will become a problem. The
product of these two numbers is the expected impact of the risk.
The expected impact of a risk (E) is calculated as E = P * I, where:
P= probability of the risk becoming a problem and
I= Impact in dollars if the risk becomes a problem.

Prof. Mrs Seema Kaimal Page 18

UNIT – IV DEFECT MANAGEMENT
Once the expected impact of each risk is identified, the risks should be prioritized by the
expected impact and the degree to which the expected impact can be reduced. While guess
work will constitute a major role in producing these numbers, precision is not important. What
will be important is to identify the risk, and determine the risk's order of magnitude.
Large, complex systems will have many critical risks. Whatever can be done to reduce the
probability of each individual critical risk becoming a problem to a very small number should
be done. Doing this increases the probability of a successful project by increasing the
probability that none of the critical risks will become a problem.
Example:
· An organization with a project of 2,500 function points and was about medium at defect
discovery and removal would have 1,650 defects remaining after all defect removal and
discovery activities.
· The calculation is 2,500 x 1.2 = 3,000 potential defects.
· The organization would be able to remove about 45% of the defects or 1,350 defects.
· The total potential defects (3,000) less the removed defects (1,350) equals the remaining
defects of 1,650.

Estimate Expected Impact of a Defect :

i. There is a strong relationship between the number of test cases and the number of function
points.
ii. There is a strong relationship between the number of defects and the number of test cases
and number of function points.
iii. The number of acceptance test cases can be estimated by multiplying the number of
function points by 1.2.
iv. Acceptance test cases should be independent of technology and implementation techniques.
v. If a software project was 100 function points the estimated number of test cases would be
120.
vi. To estimate the number of potential defects is more involved.

Prof. Mrs Seema Kaimal Page 19

UNIT – IV DEFECT MANAGEMENT

Give any two root causes of defects. Also give any two effects of defects.
Root of defects:
i. Miscommunication of requirements introduces error in code.
ii. Lack of design Experience.
iii. Lack of coding practice.
iv. Unrealistic time schedule for development.
v. Multiple changes in the requirements.

Effects of defects
i. A defect is an error in coding or logic that causes a program to fail or to produce incorrect
/unexpected results.
ii. It is commonly refers to troubles with the software products, with its external behavior or
with its internal features.
iii. Increased complexity of software.
iv. Programming Errors.

What is defect management? Give defect classification in detail. (Definition -1Mark,

Explantion-3Marks)
It is the process of enhancing quality by adding value to the most important attributes of
software like reliability, maintainability, efficiency and portability.
Describe the requirement defects and coding defects in details.
Defect Classification:

➢ Requirements and specification defect:

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

Prof. Mrs Seema Kaimal Page 20

UNIT – IV DEFECT MANAGEMENT
define his requirements, or producer gap, where developing team is not able to make a product
as per requirements.
Defects injected in early phases can persist and be very difficult to remove in later phases.
Since any requirements documents are written using natural language representation, there are
very often occurrences of ambiguous, contradictory, unclear, redundant and imprecise
requirements. Specifications are also developed using natural language representations.

Example: Tester observation while testing the Website:

Tester found that ‗Disclaimer‘ link is missing in the website. According to
organization/webmaster guidelines it is mandatory to show ‗Disclaimer‘ link in the website so
tester expressed his/her concern that the ‗Disclaimer‘ link is missing and to fix this developer
expects the business analyst to document in requirement specification document.

➢ 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. The customer may or may not be in a position to understand these defects, if
structures are not correct. They may be due to problems with design creation and
implementation during software development life cycle.

➢ Coding defects: The requirements have been coded incorrectly due to which behavior
of an implemented software function is not in accordance with the requirement
specification documents. The other frequently occurred defects made by developers are
due to Missed to code for the requirements which listed in requirement specification
document , Coding the requirements which are not specified in the requirement
specification document

Prof. Mrs Seema Kaimal Page 21

UNIT – IV DEFECT MANAGEMENT
These types of defects are usually caused by developer‘s oversight.
Example: Requirement as per specification document: If user clicks on ‘Home‘ link
in a website then ‘Home‘ page should be presented to the user. Tester observation while
testing the ‘Home‘ link: Tester found that ‘About Me‘ page is displayed each time the
‘Home‘ link is clicked which is a deviation in the behavior from the requirement
specification document. This is an example of coding defect.

➢ Testing Defect: Testing defect are defects introduced in an application due to wrong
testing , or defects in the test artifact leading to wrong testing. Defects which cannot be
reproduced , or are not supported by requirement or are duplicate may represent a false
call
.In this defects includes
1. Test-design defect : test-design defect refers to defects in test artifacts. there can be defects
in test plans, test scenarios, test cases and test data definition which can lead to defect in
software.
2. Test-environment defect: this defect may arise when test environment is not set properly.
test environment may be comprised of hardware, software, simulator and people doing testing.
3. Test-tool defects: any defects introduced by a test tool may be very difficult to find and
resolve, as one may have to find the defect using manual test as against automated tools.

Prof. Mrs Seema Kaimal Page 22

UNIT – IV DEFECT MANAGEMENT
Defect management Questions
*Note : If answers of any questions are same write it only once.
1) What are the causes of defects.
2) What are the effects of defects.
3) Explain defect template with its attributes.
4) Enlist attributes of defect.
5) Explain categories of defect.
6) What is defect management?
7) Explain defect management process with a neat diagram.
8) Explain defect prevention cycle with a neat diagram.
9) Explain deliverable baseline step in defect management process.
10) Explain defect discovery step in defect management process.
11) Explain defect Resolution step in defect management process.
12) Explain process improvement step in defect management process.
13) What is the purpose of information collected during defect management process.
14) Enlist names of any six automated testing tools along with their features.
15) Explain Defect/bug’s life cycle with a neat diagram.
16) What do you mean by defect impact? Explain how to estimate defect impact.
17) What are the different techniques for finding defect? Explain each in detail.
18) Explain Defect classification in detail.
19) Explain requirement defect and coding defects in detail.

Prof. Mrs Seema Kaimal Page 23