One of the tasks of the software tester is to tell bug occurrences to the software developer. A bug is bad news. And just like other bad news, people tend to avoid it. Some people will feel uneasy if they hear that there is bad news in the code.
The wrong communication feedback will bring a wrong response. Of course, we are familiar with defensive responses like, — “It is working on my machine.”, “It must be from another service, go check somewhere else.” , “It didn’t happen when I follow your step to reproduce.”— and something similar. Those reactions could affect the productivity of a company.
As software testers, we don’t want to get a reaction similar to that or even worse, make it. So, what is the better communication approach? How to tell bad news without making any anxiety?
I’m proposing the use of the Situation-Behavior-Impact framework.
What is the Situation-Behavior-Impact framework?
It is a direct, non-judgmental, and widely-recognized model for delivering feedback. Situation-Behavior-Impact or SBI is proven to reduce the anxiety of delivering feedback and also reduce the defensiveness of the recipient.
The Situation-Behavior-Impact method is simple and direct: You capture and clarify the Situation where bugs occur, describe the specific Behaviors observed, and explain the Impact of the behavior of the bug on the software.
How You Can Use Situation-Behavior Impacts to tell bug occurrence?
1. Situation:
Describe the specific situation/environment in which the bug occurred. Avoid generalities, such as “in my browser…, in my machine…” as that can lead to confusion. Often bugs only happen in certain environments so it is good to be as specific as possible. Make sure to list the operating system or browser you are using, and if applicable, which version of software and hardware you are using.
- Example: “In Firefox browser version 105.6.1 64 bit…”
2. Behavior:
Describe the actual, observable behavior. Keep to the facts. Avoid using ambiguous terms such as “not working, broken”. Be more specific, write every detail that you can get.
- Example: “…When I click the ‘search’ button the browser is not responding.”
But don’t forget to write down the expected behavior.
- Example: “…When I click the search button, the item I’m looking for should appear.”
3. Impact:
Describe the results of the behavior. Because you’re describing exactly what happened and explaining the real impact of the bug, a developer will be less likely to feel offended and react positively.
So how to state the impact of bug behavior? You can follow this example.
- Example: “…When I click the ‘search’ button the browser is not responding. It causes memory usage to spike sharply.”
The success of the Situation-Behavior-Impact will minimize the negative reaction. If the reaction is positive, then productive cooperation can be continued. And you can resolve the bug along with the software developer rather quickly and with less drama.
Please bear in mind, writing bug reports follows a different format, I will write a format to create bug reports in a different story. This approach is useful to tell bug occurrence in a written form or verbally.
Follow me on
Facebook: https://www.facebook.com/mydoqa/
Instagram: https://www.instagram.com/mydoqa/
Twitter: https://twitter.com/MydoQa
0 comments:
Post a Comment