Skip to content

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

Warning : Testers may put project in trouble

Often, Testers use words, phrases without calculating the probability of putting oneself / team / project in trouble by use of such statements.

Testers should be wary of using such phrases and should not believe in them blindfold.

List that may set the bomb:


Do you really think its possible to do Complete Testing? Can anyone claim that the software is completely bug free? Have you tested the application in different environments, paths & combinations? Were your findings enough to cover entire testing? Have you considered all the possible scenarios? What about non-functional testing? Security, performance Testing? Different OS, browser combinations? Configuration Testing? Testing on Mobile with unending number of combinations.

Continue reading

Dangers Decoded Before Testing the Application

You are testing an application and you come across a new functionality. You are not sure if it is implemented correctly or not.


Do you know the requirement and understand the intended functionality?

If the answer is No : are you assuming the functionality of application based on your past prejudices? Are you generalizing your understanding to apply the same logic everywhere? Are you being ignorant? Is your knowledge of knowing things from past experiences sufficient enough to know the desired goal in current situation? Are you limiting your knowledge? If you haven’t asked questions to stakeholders or hasn’t gone through oracles, you may be making a big mistake to pass the System  without the knowledge of knowing it. And that’s the first sign of danger.

Continue reading

Brace Yourself With Learning New Skills Automation

The world is changing and with changing times, it has become all more necessary to evolve. Rise of technology has improved lives and made impossible possible. Newer and better Systems is making way for automation, doing work faster and better. Work that was done few years back by hundreds of people is now done by machines in no time. Remember the rise of calculators. it changed the way we did calculations. Gone are the days when you needed a dedicated person to maintain balance sheets and look after the business critical transactions. No more punching numbers on paper and solving business transactions by crunching numbers. Computers replaced those men as they did the same job in seconds. Nowadays companies are relying more and more on machines (Automation) to do most of their transactions. Recently it was in news, a girl in Australia sent her Robot to Apple store that stood in the queue at 6:30 AM to buy an iphone 6 for her.

Continue reading

Bug Advocacy For Incomplete Bug Reports

How 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