Bug Reporting
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.
Copyright Š by QA InfoTech. All rights reserved.
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.
Copyright © by QA InfoTech. All rights reserved.
●
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.
Copyright © by QA InfoTech. All rights reserved.
●
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.
Copyright © by QA InfoTech. All rights reserved.
●
Reported by:
●
Attachment/Evidence: Any evidence of the failure should be captured and submitted
One may need to refer to the person who logged the defect.
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.
Copyright © by QA InfoTech. All rights reserved.
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.
Copyright © by QA InfoTech. All rights reserved.
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.
●
Copyright © by QA InfoTech. All rights reserved.
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
Copyright © by QA InfoTech. All rights reserved.
●
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
Copyright © by QA InfoTech. All rights reserved.
●
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”.
Copyright © by QA InfoTech. All rights reserved.
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?
Copyright Š by QA InfoTech. All rights reserved.
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?
Copyright Š by QA InfoTech. All rights reserved.
Thank You
info@QA InfoTech.com www.QA InfoTech.com