Learn Bug Reporting Techniques

Views:
 
Category: Education
     
 

Presentation Description

The key for any flawless product or application is the elimination of all malfunctionalities. This PPT will shed light on the key elements under bug reporting wherein the role of a tester and a programmer becomes essential in reporting bugs. To know more on bug reporting techniques, concepts of severity and priority, defect identifier, explicit description, go through this presentation as well as the upcoming ones.

Comments

Presentation Transcript

slide 1:

Bug Reporting

slide 2:

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.

slide 3:

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.

slide 4:

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.

slide 5:

● 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.

slide 6:

● 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.

slide 7:

● 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. Copyright © by QA InfoTech. All rights reserved.

slide 8:

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.

slide 9:

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.

slide 10:

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.

slide 11:

● 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.

slide 12:

● 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.

slide 13:

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.

slide 14:

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.

slide 15:

Thank You infoQA InfoTech.com www.QA InfoTech.com

authorStream Live Help