The Bug & The Bug Report

Before starting to write the bug report, let’s understand the basics about the Bug.

-What is the Bug in the software?

The fault in the system that can cause the system to fail to perform its required function. When the Tester found this fault before product deliver to its targeted customer then it is called as ‘The Bug’.

When Developer develops any application,

The system fault found by developer itself then it is called as ‘an Error’.

The same system fault found by tester then it is called as ‘The Bug’.

And if this system fault is found by the customer, then it will ‘The Mistake’.

Before any application/product is delivered to the customer it is tested by Software Tester and if Tester found any fault, then he raises the issue to the developer is called as the bug.

-What are the types of the bug that can tester find while testing the software?

There are different types of bugs. Some of them are:

1. Functional Bug:

The functional bug is the defect in an application that affects the actual functionality of an application.

For an example,

i. I am trying to login to the shopping website with the correct credentials, but I am unable to login.

ii. Trying to do the payment but it is not allowing (Even though details are correct)

2. User Interface Bug:

The defect is in the Graphical User Interface of an application called the User Interface Bug (UI Bug).

For an Example,

In any shopping website,

i. The spelling mistake is present in the company details.

ii. The Company logo is not displaying properly.

iii. The alignment of the form is not correct.

3. Performance Bug:

If there are any errors present in the program of developed application that causes poor performance of an application, poor User Experience then it is called as Performance Bug.

For an example,

i. Tring to access shopping website. But it is taking too much time to load and open the website.

ii. High number of people are accessing the website at the same time and website got crashed.

4. Compatibility Bug:

The developed application is working properly on one platform but unable to work the same as on different platform then we call it as Compatibility Bug.

For an example,

i. Android app is not working in the iPhone.

ii. The window application is unable to load in the MAC operating system.

iii. The Website is opening in the Internet explorer browser is having UI issue in Chrome Browser.

-Why to write the Bug Report?

In the SDLC life cycle, once the developer develops the application then it is giving to the Tester to test an application. When the tester found any bug in an application then the tester needs to tell the developer to solve the issue present in the application. To resolve the issue, developer need to regenerate the same issue in Development environment so the tester need to write the bug report and hand-over to developer so the developer can fix the same.

-Who write this bug Report?

The responsibility of writing bug report is of Quality Assurance Engineer or Software Tester.

-Where to Submit this bug report?

There are various platforms to know the Software Developer about the issue in an application.

i. To maintain the Excel Sheet

ii. Email Communication

iii. Using Bug Tracking tool like, Jeera, Bugzilla

So, after understanding of the bug now let’s see how to write bug report in an effective way.

-Bug Writing Criteria:

The most common bug report should contain the following fields.

1. BugID:

It is a unique Identification number of the Bug.

2. Bug Name:

Bug name should be small and simple to understand for developer.

3. Description:

The proper description about the bug so the developer can understand.

4. Precondition:

In this we have to provide environment setup to produce the issue in development environment.

5. Status:

The status describes the current status of the bug. The status of the bug can be anyone of the following:

Open

=========

When QA Engineer found any bug then he keeps the status as ‘Open’. So, the developer come to know the issue is present in the system.

Fixed

=========

When developer solve the bug then he marks the bug as ‘Fixed’. So later in release, QA retest the same functionality of the bug.

Resolved:

=========

When QA retest the issue fixed by developer then he marks the issue as resolved.

Re-Open:

========

The issue fixed by developer is still reproducing at testing environment then bug status is kept as ‘Re- Open’

Close:

======

If the bug is got fixed by developer and not re-producing it in testing environment, then the status of the bug is changed to ‘Close’.

Duplicate

========

If the developer found the raised bug is having duplicate entry, then he marks the bug as ‘Duplicate’.

Invalid

======

If the development team think the issue is not present as per functionality, then it is marked as ‘Invalid’.

6. Priority: The priority is how much urgency it takes to solve the bug. Priority can be:

Low

Medium

High.

Depending on priority, the developer starts to work on the issue.

7. Severity:

This is the impact of the bug on the specific functionality of an application.

Following are various stages of the severity of the bug.

Low

Minor

Major

Critical

8. Steps to produce the Bug:

We should write the each and every step (which followed while performing the testing) in the bug report so it will be helpful to reproduce the same bug in development environment. So, each and every step should be mentioned.

9. Actual Result:

The current output after following the steps mentioned in the bug report. In the actual result, we can attach some screenshot or provide some output data so the developer can easily understand the exact issue.

10. Expected Result:

What is the expected output after following the same steps.

Conclusion:

An effective bug report created by the Tester will always help the development team to understand the bug & try to work on it as soon as possible.

Thank you for reading this blog…...

Happy Testing…