After my Google Hangout Interview with Katrina, I started to think about picking your battles – which she listed as an important quality of a tester. Below I’d like to talk about my experience and thoughts on this idea.
The Girl Who Cried Wolf
When I started my first (ever) project, my understanding was that the purpose of testing was to provide information with more emphasis placed on advocating for the fixing of bugs.
The thing is – I took this too far.
Part of me relished raising bugs in the Test Tool and assigning a severity and priority. The sad thing is, I thought I was a better tester when I raised bugs with a higher severity and priority. This meant I probably assigned a higher severity or priority to bugs than they actually deserved.
I’d see spelling and grammar mistakes and would make a massive deal out of it. It took a while for me to learn that my opinion mattered but wasn’t actually as important as I thought it was at the time. Looking back, I didn’t try to see if the spelling and grammar mistakes could change the meaning of text – I merely marked it as wrong. If I were to come across this situation now, I would consider the impact of meaning on whether I were to assign a higher severity/priority. (For example: Would the bad grammar lead the user to commit an error?)
Unfortunately, this led to a “boy who cried wolf” situation. I found it more difficult to get my bugs fixed partially because of the fact I placed too much importance on bugs that didn’t actually matter (and partially because of factors out of my control).
Why should you pick your battles?
- To not cause the testing profession to be seen as a a blocker of the SDLC
- To avoid a “boy who cried wolf” situation
- To ensure we (as testers) are seen as adding value to a team and not hindering the team
How can you pick your battles?
Here are a few questions you could ask yourself when advocating for a bug
- Why do I want this bug to be fixed?
- What’s the worse thing that could happen if the software went live with the bug in it?
- What’s the risk of the bug being discovered in production?
- Have I made a reasonable effort to see things from the other person’s point of view (if someone is saying the bug does not need to be fixed)?
- Looking back, are there bugs I insisted on being fixed, that were in fact not that important? (this may affect the current perception by the team)
- Have I asked the opinion of someone (honest, who won’t just blindingly agree with me) about the bug and presented the bug in an objective manner?