Scribd
Upload
23 views

9 Defect Management

This document discusses defect structure, management, and tools. It defines a defect as an error or bug in software. Defects can arise from incorrect user or developer actions, or test environment setup issues. The document outlines how to log defects, including what information to include regarding the defect description, steps to reproduce, severity, and priority. It also discusses defect life cycles and issue management tools.

Uploaded by

lazaradela.2007
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
23 views

9 Defect Management

This document discusses defect structure, management, and tools. It defines a defect as an error or bug in software. Defects can arise from incorrect user or developer actions, or test environment setup issues. The document outlines how to log defects, including what information to include regarding the defect description, steps to reproduce, severity, and priority. It also discusses defect life cycles and issue management tools.

Uploaded by

lazaradela.2007
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 19

DEFECT STRUCTURE

1
DEFECT MANAGEMENT
AND TOOLS
SORINA INDRECAN
AGENDA
• DEFECT STRUCTURE
- Definition of Defect
2
- When defect arise and their costs
- How to log defects:
o What? Why? When? How?

• DEFECT MANAGEMENT AND TOOLS

- ISSUE PROCEDURE & DEFECT LIFE CYCLE

- EXERCISES

2
DEFINITION
Definition: A defect is an error or a bug, in the application which is created.
A programmer while designing and building the software can make mistakes or
error. These mistakes or errors mean3 that there are flaws in the software.
These are called defects.

- When actual result deviates from the expected result while testing
- When the result of the software application or product does not meet with the end
user expectations

3
WHEN DEFECT ARRISE
– The person using the software application or product may not have
enough knowledge of the product.
4

– Maybe the software is used in the wrong way which leads to the defects
or failures.

– The developers may have coded incorrectly and there can be defects
present in the design.

– Incorrect setup of the testing environments.


4
WHEN DEFECT ARRISE AND THEIR COSTS

5
WHAT
• An incident report contains a description of the misbehavior that was observed
and classification of that misbehavior.
6

6
WHY

• Provide detailed information7 about the behavior observed

• To support evaluation of the overall system quality.

• Contribute to development and test improvements.

7
WHEN

8
HOW TO LOG A BUG
• Careful and attentive approach when running the test
• Make sure that misbehavior can be reproduced
9
• Try to isolate the defect
• Log defect for a certain functionality (user story)
• Have the readers in mind
• Formulate clear and unambiguous
• Complete mandatory fields
• Keep the report concise
• One report for one problem

9
HOW TO LOG A BUG
Defect ID – Every bug or defect has it’s unique identification number
Defect Description – This includes the abstract of the issue.
Product Version – This includes the product version of the application in which the defect is found.
10
Detail Steps – This includes the detailed steps of the issue with the screenshots attached so that
developers can recreate it. (Precondition, Actual and Expected results)
Date Raised – This includes the Date when the bug is reported
Reported By – This includes the details of the tester who reported the bug like Name and ID
Status – This field includes the Status of the defect like New, Assigned, Open, Retest, Verification,
Closed, Failed, Deferred, etc.
Fixed by – This field includes the details of the developer who fixed it like Name and ID
Date Closed – This includes the Date when the bug is closed
Severity – Based on the severity (Critical, Major or Minor) it tells us about impact of the defect or bug in
the software application
Priority – Based on the Priority set (High/Medium/Low) the order of fixing the defect can be made.

10
SEVERITY AND PRIORITY
1) Severity:
It is the extent to which the defect can affect the software. In other words it defines the impact that
a given defect has on the system. For example: 11 If an application or web page crashes when a
remote link is clicked, in this case clicking the remote link by an user is rare but the impact of
application crashing is severe. So the severity is high but priority is low.
(critical,major,moderate,minor,cosmetic)
2) Priority:
Priority defines the order in which we should resolve a defect. Should we fix it now, or can it wait?
This priority status is set by the tester to the developer mentioning the time frame to fix the defect.
If high priority is mentioned then the developer has to fix it at the earliest. The priority status is set
based on the customer requirements. For example: If the company name is misspelled in the
home page of the website, then the priority is high and severity is low to fix it. (low, medium, high)

11
SEVERITY AND PRIORITY

12

12
13
ISSUE MANAGEMENT

AND

TOOLS

13
ISSUE PROCEDURE & DEFECT LIFE CYCLE

14

14
15

15
16

16
17

17
TIPS & TRICKS

• Use attachments
• Useful tools: 18
o Snipping tool, Jing
• Communicate with the team
• Use comments in the Tool used for logging
• When testing a fix do also a small regression in the affected functional
area

18
EXERCISES

19

19

You might also like