Learn Bug Reporting Techniques

Agenda
● Definition of a Bug
● Elements of Bug Reporting
● Severity and Priority
● Key Points to a Good Bug Report
● Roles and Responsibilities
Copyright © by QA InfoTech.
All rights reserved.

Definition of a Bug
Bug: A fault in a program which causes the program to perform in an unintended or
an unanticipated manner.

Elements of Bug Reporting
● Defect Identifier, ID: The identifier is very important in being able to refer to the defect in
the reports.
If a defect reporting tool is used to log the defects, the ID is normally a program-generated
unique number which increments per defect log.
● Summary: The summary is an overall high level description of the defect and the observed
failure.
This short summary should be a highlight of the defect since this is what the developers or
reviewers first see in the bug report.

● Description: The nature of the defect should be clearly written.
The description should explain exactly the steps that need to be taken to reproduce the defect,
along with what the expected results were and what the outcome of the test step was. The
report should say at what step was the failure observed.
● Severity: The severity of the defect normally concerns the software in question.
Example: An application does not launch at all and causes the operating system to shut down.

● Priority: The priority normally concerns the target customers in question.
Example: A company name is misspelled on the splash screen as the application launches.
● Date and Time: The date and time that the defect occurred or was reported is also
essential.
This is normally useful when you want to search for defects that were identified for a particular
release of the software or from when the testing phase started.
● Version and Build: It is essential to note which version of the software exhibited the
failure that we are reporting.
We may always refer to that version of software to reproduce the failure.

● Reported by: One may need to refer to the person who logged the defect.
● Attachment/Evidence: Any evidence of the failure should be captured and submitted
with the defect report.
This is a visual explanation of the description of the defect and helps the reviewer or the
developer to better understand the defect.

Severity
Severity: It represents the intensity or the degree of how negatively is the system affected.
Severity is classified into 4 categories:-
● Critical:- The defects which block the user to further use an application.
● Major:- The defects which don’t block the user to further use an application but produce wrong
results.
● Minor:- The defects which can be avoided by using some workaround and don’t impact the
end-user results.
● Cosmetic:- Cosmetic issues are majorly enhancement issues or UI issues.

Priority
Priority: It represents the importance or necessity of being attended to. Priority is given by testers or
developers in order to fix a defect within a given period of time.
Priority is classified into 3 categories:-
● Low:- The defect is a valid bug but it can be deferred to a later release in order to be fixed.
● Medium:- The defect is fixed during normal development activities and can wait until the next build
comes.
● High:- The defect which needs to be fixed as soon as possible as it makes an application unusable.

Key Points to a Good Bug Report
● Be very specific when describing the bug
❏ There shouldn’t be any room for misinterpretation
❏ More concise means less ambiguous, so less clarification will be needed later
● Calling windows by the correct names will eliminate some ambiguity
❏ By the name displayed on the title bar
● Don’t be repetitive
❏ Do not repeat yourself by saying something twice or thrice

● Try to limit the number of steps to recreate the problem
❏ A bug that is written in 7 or more steps usually becomes hard to read
● Start describing with “where the bug begins”, not before
❏ Example: You don’t have to describe how to load and launch the application if the
application crashes on exit
● Proofreading the bug report is very important
❏ Send it through a spell checker before submission

● Make sure all step numbers are sequenced
❏ No missing step numbers and no duplicates
● Don’t use a condescending or negative tone in the bug report
❏ Example: Don’t say things like “It’s still broken” or “It’s completely wrong”.

Roles and Responsibilities
Role of a Tester:
1. What is the exact and minimal sequence of steps required to reproduce the symptoms of
the bug? How often do these steps successfully reproduce it?
2. Does the failure indicate a test bug or a system bug? In other words, does the anomalous
result originate from a test artifact or from the tester’s side, or from system misbehaviour
that could affect customers?
3. What external factors influence the symptoms?

Role of Programmer:
1. What is the root cause of the problem- whether in the code, the electronics, the network,
or the environment?
2. How can the problem be repaired without introducing new problems?
3. Are the changes properly debugged?

Thank You
info@QA InfoTech.com
www.QA InfoTech.com

Learn Bug Reporting Techniques

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Learn Bug Reporting Techniques

Similar to Learn Bug Reporting Techniques (20)

More from QA InfoTech

More from QA InfoTech (17)

Recently uploaded

Recently uploaded (20)

Learn Bug Reporting Techniques