Reporting bugs for Dummies with Google Drive forms

There are bugs in every application. Even more so for applications that are in development, there is no question about it. If it is a given that bugs are present then the question is how do we find those bugs?

A simple answer is: look hard and look frequently. The harder you look, the more bugs you will find. This is usually a job for someone who specializes in Quality Assurance (QA). A QA-er should be an analytical and critical and should have the skills and experience to efficiently look for issues in software. If he or she has found a bug then it should be reported in a clear and efficient way. A good QA-er will of course know how to do this.

So, a good QA-er will be looking hard, but he or she only has one pair of eyes. In most cases the QA-er thankfully isn’t the only one looking at the application. The developers and other people within a team (system administrators, scrum masters, business architects, you name it!) will also see the software and maybe a manager will even take a look at it. At least one person from the customer perspective (and preferably more than one) should also be looking at it and if you are really lucky you will have input from a good, open and honest customer too! These are all people who can help by identifying the bugs and let’s be honest although it may not always be fun to identify them, once found they can be fixed, which is typically a good thing right?

There is however one crucial difference between a QA-er whose job it is to find bugs and all the other people for whom testing isn’t their main concern; QA-ers have experience with reporting bugs. It might not seem like such a big deal, how hard can it be to report a bug? Just throw it in a bug tracker (or in an email) and that’s that! Reporting a bug isn’t difficult. However, making a good clear bug report can be if you have little or no experience with it.

A bug goes through some stages in it’s lifecycle. The first stage is discovery; the bug is found and reported. Then a QA-er might need to reproduce it and review if it is a valid bug (if someone outside the development team found it). If the bug is found to be valid then a developer will need to reproduce it in order top be able to find out where the exact problem lies within the code. After the problem is solved a QA-er will take a look at the fix and decide if the bug is fixed correctly. Making a good clear bug report is important since it is a phase in which you can gain a lot of time and effort.

If you report a bug along the lines of ‘it doesn’t work in screen x’ then a tester will probably spend a lot of time and effort trying to reproduce it and find out what is meant exactly. After that a developer will spend time and effort on reproducing the bug in order to localise the problem and in trying to define the impact. And finally, the tester might spend time and effort again in trying to validate the bug fix! This is a lot of time and effort that can be drastically reduced by making a clear report.

But how do you make a good bug report? A good report answers a couple of questions. The first question is: Where does the bug happen? What is the context? The second question is: When does the bug occur? What are the steps needed to reproduce it? The final question is What is the bug and how should the application work? We want to know what the result is and what the desired result should be.

A bug appears in a context that can consist of:

• a specific version of a specific browser
• an operating system
• a version of the application
• the user that found the bug (and the specific rights that user might have)
• certain data that was used to trigger the bug
• the part of the application the bug was found in (in what tab/screen/field?)
• the configuration of the (test)data that was in the application when the user started

Steps to reproduce are needed, such as:

• which input did the user give? Did the user enter, edit or delete data? What was that data; text or a file?
• what was the action the user performed to trigger the bug? Did he or she use a button, drag an item, refresh a page, etc.?

Finally we need to know the result of the steps to reproduce and the desired result:

• what is the output the user sees in the application? Is there information of a more technical nature such as an error log or an error message?
• what is the output that you would expect and/or like as a user?

In order to make sure someone who found an issue report all the relevant data you can of course simply hand them the link to the bug tracker you are using. A good bug tracker will have the fields to enter the relevant data. However, they can be cumbersome and off-putting to people who aren’t experienced with the specific tool you might be using. To help guide people through making a good report you can make a google drive form. It is an easy to make and user-friendly functionality in google drive.

It allows you to create a form with fields that you can modify. You can add fields, write a short explanation for it to guide users, make a field required and choose the field entry (from text to checkboxes to multiple choice). You can add a field for each entry that is relevant to your project.

After you have finished creating a form you can send the people you want using it a link and they will be able to use it anywhere.

The results someone enters will appear in a google drive sheet that can be shared with other people. The benefit of this sheet is that you can easily export it and then you could even enter it in most bugtrackers (if they support data import).

If you are tired of dealing with vague descriptions of issues and you and other people on your development team are spending too much time on trying to figure out what the issue is and how you can reproduce it then a google drive form can help. It will help the people finding bugs to create a good report, it will also help the people reviewing the validity and severity of an issue, it will help a developer trying to localise the bug and fixing it and it will help the QA-er who needs to test if the fix is correct. Those are a lot of people being helped out with just the use of one simple form.