Skip to main content

The Girl Who Cried Wolf - Picking Your Battles

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?



Image source: http://www.keepcalmandposters.com/poster/keep-calm-and-pick-your-battles

Comments

Popular posts from this blog

A reflection on Let's Test 2015: Part II

Here's the link to A reflection on Let's Test 2015: Part I The sessions (Part II) Below does not include all of the sessions I went to nor all aspects of the session I mention Visual Creativity: Using Sketchnotes and Mindmaps to aid your agile testing - Dan Ashby and Christina Ohanian Before this session I stumbled upon Christina drawing out her sketch notes from the previous session and marvelled at how fascinating it was. Sketch notes were only something I'd only ever seen on the net. They were gorgeous and a clever way to communicate information. When she told me that she was going to have a session on this - I was all in. We 'warmed up' by drawing whichever image came to mind when Dan said a word. It was interesting to see how a lot of people could interpret the same word differently. For example: "Time" could be a clock, a watch or an hourglass.

Getting started on a testing project

I started on a new project a few weeks ago and thought it would be a good idea to share a checklist for what new testers on a project need and some good starting questions when you, as a tester, are new on a project Checklist for what new testers on a project need (Note, your project may not include all of the below) Note to check if user credentials are needed for any of the below

My Most Used Test Heuristics (with examples)

First, what is a heuristic? A heuristic is a guideline ,  it is fallible.  Therefore, it will give you a good idea of what behaviour you should see BUT it isn't definitely what should happen - it's up to you to confirm that the behaviour you are seeing is correct.  In a previous blog post I shared a step by step guide on  how to test without requirements/little requirements.    But I figured it's good to share my most used test heuristics that I use for testing without requirements. They are: Consistency with History Consistency with User Expectations Consistency within Product Let's take a look at each of them along with some examples to illustrate the concept. 1. Consistency with History  The feature's or function's current behaviour should be consistent with its past behaviour, assuming there is no good reason for it to change. This heuristic is especially useful when testing a new version of an existing program. (Source: developsense) Example: Whitcoulls, a