While raising bug scenario mentioned shall be specific or not?

Question

When Bugs are raised there can be multiple scenarios in which the particular functionality is verified just to make sure is it really a bug or not. While mentioning the scenario if that functionality is failing in each scenario then shall we raise a different bug for each scenario or shall we mention all in one bug or no need to mention all scenarios.

Answer 1

Well, the answer is, it depends...

It depends on:

• whether your investigation reveals it's the same bug that shows up in different scenarious => then I find it unnecessary, or even duplicate, to fill in more than one bug report; I'd, however, mention that this bug manifests itself in more than just one scenario
• your company policy; it could not be up to you to decide, you might have some strict policy in place
• how well you know the rest of the team => I find it unnecessary to raise (multiple) bug reports if I know programmers well and we sit in the same office and I know that they will work on the bug right now or in a couple of minutes. Sometimes it's not even necessary to raise a bug at all in such a situation (if your company permits, see the previous point), because part of my job is to make their job easier, so any written report they have to read (instead of me just saying/showing them) is gonna slow them down no matter how well structured the my bug report is

What I know from talking to devs I've worked with, there're a couple of things you should definitely not do if you want them to work (quickly, with interest etc.) on your bug reports:

• filling in a bug report that actually mentions more than one problem
• filling in a bug report that's not clear, where crucial information is missing, a bug report that is poorly worded and/or wrongly structured
• filling in a bug report that's too long; how long is too long you might ask... if unsure, ask devs you work with, they are the group of people you want feedback from

These are some general guidelines. Maybe if you give us an example of in which situation you had to decide whether to raise one or multiple bug reports, we might be able to answer better.

Answer 2

For this Bug Advocacy question, I would suggest reading Lessons Learned in Software Testing chapter on the subject.

In summary, you can see bug reports as a communication and sales tool. You are trying to convenience somebody of the importance of tackling something you consider problematic. As with any sale, you have to structure your words and tools to your audience.

As an example given in the book is a boundary problem:

Say an input takes integers from 1 to 99. You have found an error when entering 99 and fills a bug describing it. A programmer may reply that your bug is valid, but not so important because entering 99 is very rare.

You can then do a follow-up testing and demonstrate that the error appears in any value between 20 and 99. Now you have a way more powerful story.

On the other hand, if the problem happens indeed only at 99, you may be facing a "small" problem with bigger consequences. You can show that the few cases of entering 99 cause massive disruptions on the system. This is a way better story than what you had initially.

Sales / Bug reporting is all about telling stories. Tell your story in accordance with your audience and you will be effective, because you will be saving their time, directing them to a valuable problem to solve.

In your example, you may create the two versions and talk to the developers, asking how they prefer to organize these documents.