Bug Reporting

Go back to Tutorial

A software bug is an error, flaw, failure, or fault that produces an incorrect or unexpected result.

Types of Bugs

In software development projects, a “mistake” or “fault” may be introduced at any stage. Bugs arise from oversights or misunderstandings made by a software team during specification, design, coding, data entry or documentation. For example, a relatively simple program to alphabetize a list of words, the design might fail to consider what should happen when a word contains a hyphen. Or when converting an abstract design into code, the coder might inadvertently create an off-by-one error and fail to sort the last word in a list. Errors may be as simple as a typing error: a “<” where a “>” was intended.

Another category of bug is called a race condition that may occur when programs have multiple components executing at the same time. If the components interact in a different order than the developer intended, they could interfere with each other and stop the program from completing its tasks. These bugs may be difficult to detect or anticipate, since they may not occur during every execution of a program.

Conceptual errors are a developer’s misunderstanding of what the software must do. The resulting software may perform according to the developer’s understanding, but not what is really needed.

Arithmetic

• Division by zero.
• Arithmetic overflow or underflow.
• Loss of arithmetic precision due to rounding or numerically unstable algorithms.

Logic

• Infinite loops and infinite recursion.
• Off-by-one error, counting one too many or too few when looping.

Syntax

• Use of the wrong operator, such as performing assignment instead of equality test. For example, in some languages x=5 will set the value of x to 5 while x==5 will check whether x is currently 5 or some other number. Interpreted languages allow such code to fail. Compiled languages can catch such errors before testing begins.

Resource

• Null pointer dereference.
• Using an uninitialized variable.
• Using an otherwise valid instruction on the wrong data type.
• Access violations.
• Resource leaks, where a finite system resource (such as memory or file handles) become exhausted by repeated allocation without release.
• Buffer overflow, in which a program tries to store data past the end of allocated storage. This may or may not lead to an access violation or storage violation. These are known as security bugs.
• Excessive recursion which—though logically valid—causes stack overflow.
• Use-after-free error, where a pointer is used after the system has freed the memory it references.
• Double free error.

Multi-threading

• Deadlock, where task A cannot continue until task B finishes, but at the same time, task B cannot continue until task A finishes.
• Race condition, where the computer does not perform tasks in the order the programmer intended.
• Concurrency errors in critical sections, mutual exclusions and other features of concurrent processing. Time-of-check-to-time-of-use (TOCTOU) is a form of unprotected critical section.

Interfacing

• Incorrect API usage.
• Incorrect protocol implementation.
• Incorrect hardware handling.
• Incorrect assumptions of a particular platform.
• Incompatible systems.

Bug Report

While reporting the bug to developer, your Bug Report should contain the following information

• Defect_ID – Unique identification number for the defect.
• Defect Description – Detailed description of the Defect including information about the module in which Defect was found.
• Version – Version of the application in which defect was found.
• Steps – Detailed steps along with screenshots with which the developer can reproduce the defects.
• Date Raised – Date when the defect is raised
• Reference- where in you Provide reference to the documents like . requirements, design, architecture or maybe even screenshots of the error   to help understand the defect
• Detected By – Name/ID of the tester who raised the defect
• Status – Status of the defect , more on this later
• Fixed by – Name/ID of the developer who fixed it
• Date Closed – Date when the defect is closed
• Severity which describes the impact of the defect on the application
• Priority which is related to defect fixing urgency. Severity Priority could be High/Medium/Low based on the impact urgency at which the defect should be fixed respectively.

Good bug report

The aim of bug reporting is to explain an issue to web developers as soon as possible to aid overall project development. Before the QA team starts writing a bug report, they should know the answers to the following questions:

• What? – What has happened with the application?
• How? – What did we click/do to produce the bug?
• Where? – Where exactly in the app did we find the bug? What is the webpage and/or server (environment)?

Effective Bug Reporting

Bug reporting is an important aspect of software testing. An effective bug report communicates well with the development team and avoids confusion or miscommunication.

A good bug report should be clear and concise without any missing key points. Any lack of clarity leads to misunderstanding and slows down the development process as well.  Defect writing and reporting is one of the most important but neglected areas in the testing life cycle.

Good writing is very important for filing a bug. The most important point that a tester should keep in mind is not to use a commanding tone in the report. This breaks the morale and creates an unhealthy work relationship. Use a suggestive tone.

Don’t assume that the developer has done a mistake and hence you can use harsh words. Before reporting, it is equally important to check if the same bug has been reported or not.

A duplicate bug is a burden in the testing cycle. Check the whole list of known bugs. At times, the developers might have known the issue and ignored for a future release. Tools like Bugzilla which automatically searches for duplicate bugs can also be used. However, it is best to manually search for any duplicate bug.

The import information that a bug report must communicate is “How?” and “Where?” The report should clearly answer how the test was performed and where the defect occurred exactly. The reader should easily reproduce the bug and find where the bug is.

Keep in mind that the objective of writing the bug report is to enable the developer to visualize the problem. He/She should clearly understand the defect from the bug report. Remember to give all the relevant information that the developer is seeking.

Also, bear in mind that a bug report would be preserved for future use and should be well written with the required information. Use meaningful sentences and simple words to describe your bugs. Don’t use confusing statements that wastes the time of the reviewer.

Report each bug as a separate issue. In case of multiple issues in a single bug report, you can’t close it unless all the issues are resolved.

Hence it is best to split the issues into separate bugs. This ensures that each bug can be handled separately. A well-written bug report helps a developer to reproduce the bug at their terminal. This helps them to diagnose the issue as well.

Go back to Tutorial