Skip to content

Bug Report

16 Simple Ways That Make Your Bug Report 100% Powerful

Post is not focused on “How to write a Bug Report . Although it is about Bug Reporting, but will talk about “How Not To Write a Bug Report“.

I was recently assigned a project wherein there were already QAs working for quite some time and have raised truck load of bugs in bug tracking tool. My main task was to thoroughly test the website that was already tested by other testers. But before I could proceed, I decided to go through the important bugs already raised by QAs in order to avoid duplicity.

While reading the bug reports, I realized the common mistake QAs made while raising the bugs. I noted most of the bugs reported were in “Rejected” state & others (marked “Important” / “Critical”) were raised in such a manner that the bugs were in “Open” state for quite some time now, thus increasing the defect’s age. As a result, application was leading nowhere, So, client decided to do away with current QA team before it gets worse.

Continue reading

Bug Advocacy For Incomplete Bug Reports

Incomplete bug reportHow often (or rarely) does it happen when your bug gets rejected with a comment (from devs) that they were unable to repro the bug reported. Or it was rejected on the grounds of being incomplete or obsolete ?

if it happens more than often, it’s time to introspect.

Bug Advocacy is crucial to the project. An incomplete bug report can only harm the project to delay it further as it puts everyone’s time and money at stake. QA’s have to put in time to write the bug. Devs have to study the bug and send it back if they do not understand it. Meetings with the management. Stakeholders time and money is involved. Too much of to-and-fro communication just depletes the time and money inches down.

You as a tester need to take charge here. A tester guides the project. you are the one giving direction to it. If a Tester mislead, the project can derail.

Continue reading

Why Testers Overlook To Report a Bug?

Have you experienced when you do not report a bug and the same would get caught by your stakeholders and then you repent on your decision of not reporting it?

Oh! I noticed that bug but did not find it important to report it.

Oh! I noticed that bug but I was held up with other things that did not get time to report it.

I think this happens and there could be many possibilities of failing to report it. What might lead to take a decision in such cases? How one can decides to report it? What makes anything new more appealing than the one you overlook ?

Continue reading

You Missed That Testing Scenario!

You missed that scenario“You missed that scenario!” ever heard client saying that when you showcased your completed work?

In one such situation, the client was upset because they found an issue in production. I tried to convince her by presenting what I did and assured her to cover such scenarios in future.

I was curious to know more about the production issue, wondering how I failed to recognize that particular scenario. According to my client the issue was with a particular record not fetched using search functionality. When I found the pattern then, it was like search query fired with space followed by underscore would not fetch the correct results. I discussed my observation with developer and they informed that “technology” does not allow this kind of combination string in search query. It has technology limitations.

If I would debate whether this is an issue or not, nobody wins, because you can’t deny the fact that end user might use this kind of query to search results and technology has no answer to it.

The point is to convince the client that 100% testing or bug free software is a marketing term, in reality this may not be possible. Quality of the product depends on designs, development, time, technology, testing and decisions made against the bugs.

Unable to find bugs does not mean there are no issues. It does not mean testes is not doing her job. It does not mean test is careless. What I would say is a skilled tester would help you to do good enough testing and help you to release good quality product.

Continue reading

Think twice rejection of non-reproducible bugs

It’s a story about two testers who were testing the same application. Their client had direct access to those machine which these testers were accessing remotely. Tester A found a bug and she reported to the client. Client declined a bug stating that they were non-reproducible. For a minute she looked at the issue and close without giving a second thought.

After a week Tester B raised same issue and client again declined the issue giving the same reason. Tester B was restless because he was not able to understand the reason of not able to reproduce the issue. Tester B tried on different machine and also confirmed with Tester A but all his efforts were in vain. He did not have access to log files and it was impossible to get at this juncture.

Continue reading