CASE STUDIES: Why is bug reporting an art that should be learned by every tester?

Share This Post

Share on facebook
Share on linkedin
Share on twitter
Share on email

CASE 1

Why is bug reporting an art that should be learned by every tester?

Acc. to Mr. Rahul: Bug reporting isn’t just an art. It is a form of martial art

Let us better understand this by example:

Type 1

App crashes when clicked on the submit button after entering all the details

Steps to reproduce:

Open the app

Click on the Hamburger Menu

Click on “Create”

After page loads – enter Username, Address and Phone Number

Hit the Submit button

Expected Result: App should not crash.

Actual Result: App crashes

Notes:

A lot of testers do this – as though the product owner and developer doesn’t know where the create page is. It is a bad practice carried from one organisation to another. It is a blind belief that if we don’t break it down like this people can’t reproduce it.

Some bugs need precise instructions because the bug is about the flow. This bug isn’t about the flow and hence does not require the details.

Type 2

Create Page : App crash on initiating a write to database

Any write function to the database appears broken on Create Page.

Write points tested

Submit – Result -> Crash

Edit – Result -> Crash

Crash logs attached.

Tried 3 times – all 3 times consistent result

Notes:

This is far better than the previous one. This shows the clarity of a tester in reporting this bug. This shall make the developer not come back to testers for obvious questions. Most of what is required is there. This also shows a tester’s awareness that a Write_Function is causing an issue than the Submit button itself.

Type 3

Create Page : Write_Function causes Null Pointer Exception

Any write function to the database appears broken on Create Page.

Write points tested

Submit – Result -> Crash

Edit – Result -> Crash

Crash logs attached.

Tried 3 times – all 3 times consistent result

Impact : This is the page where users spend 15% of their time as per our analytics. This can have a direct impact on user reviews and revenues.

Notes:

This is a slightly improvised version of the previous one. This shows the awareness of a tester of how the users use the app and the impact this bug can have on the users and the business. This kind of bug reporting (with bug advocacy) showcasing the impact of the bug on users and or business helps people understand the value from a tester.

Type 4

Create Page : Write_Function causes Null Pointer Exception

Any write function to the database appears broken on Create Page

This issue is specific to Create Page as Write_functions on other pages seem to be fine

Write points tested on Create Page

Submit – Result -> Crash

Edit – Result -> Crash

Write points tested on Other Pages

Submit – Result -> Write Done

Edit – Result -> Write Done

Crash logs / ADB Logs are attached.

Tried 3 times – all 3 times consistent result. Also, the state of the app does not matter. This issue is reproducible in all states the app can be in.

Impact : This is the page where users spend 15% of their time as per our analytics. This can have a direct impact on user reviews and revenues.

Notes

This one shows the investigation done after having found a bug. This helps in understanding that the tester won’t create too many bug reports for the same bug. If there is a problem with write_function across pages the whole bug report would have changed to – Any write function to the db appears to result in Null Pointer Exception.

Plus – it shows the tester has a deeper sense of what could be causing the issue and the oracle of “Inconsistent behaviour within the application”. Does the state of the app matter? NO, in this case. That is captured too.

Type 5:

On Slack, “Hey, I found a crash with any write_function implementation, probably an incorrect version got checked in – are you giving me a new build?”

Notes:

At times this maybe good because creating a new ticket will end up adding noise to everyone when things can be sorted out. There are people who argue that every bug should be reported and not sorted out with developers like this but the counter argument is – if reporting becomes an overhead and there is a way to get it resolved – do it.

Bug reporting isn’t just an art. It is a form of martial art

Subscribe To Our Newsletter

Get updates and learn from the best

More To Explore

Do You Want To Boost Your Business?

drop us a line and keep in touch

© All Right Reserved | Vision QA

Follow Us

Want To Hire Us?

Let's get your software polished

Need urgent assistance?