Wednesday, January 22, 2014

How to Insult a Tester

This post is about things that happened recently, flavored with a bit of attitude of both not believing what people say to others and laughing at how common these issues are. Put your dry humor glasses on as you read on...

There was a meeting to discuss testing with the tester, tester's personnel manager and tester's project manager. The meeting all in all was productive and took place in good spirit. Yet, it was an exemplary case of How to Insult a Tester.

Idea 1: Blame the tester for missing bugs that caused trouble in production regardless of knowing 1/3 of recommended testing was done

The meeting started off with a discussion about production problems a week before that were humiliating and should have been found. We all agree that they should have been found. But we don't agree on why they were not. As the tester, I think they were not found because they were not tested as there was not time to test those things. They were on the list of things to test, the list that none in the team can help with because they need to do other work.

Idea 2: Explain that you want Monkey testing

The project manager suggests that he would like to get more of "shallow testing" all around the product to find all the problems and that the problem is that what happens is "too in-depth". He would like tester to find all the problems in shorter time. What would be the style of testing needed is some hours on every area of the product, in a case where every area is so big to test that it would need a lot of time. Project manager continues by explaining that he wants more of monkey testing, just clicking around AND that would bring out all the bugs in a shorter time frame.

Idea 3: Explain testing belongs with the tester but developers can't help because other stuff is "more important"

The discussion continues with the 10:1 ratio of developers and tester, non-existing test automation and huge amount of features that could break with system level changes, like ones seen as problems last week. As a particular example, raising the point that testing efforts planned in the common planning have been 3 times the effort of skilled testers available, and that as a team we don't react to testing not getting done due to lack of resources. End of this: developers have so important features that just must be developed, that there is really no other choice but to get all the testing done by the tester. To soften this a little, suggestion is to try and get permission to hire/contract a second tester, but with reservation that most likely that will not be possible because "product management promised they can do monkey testing themselves". End this with "you can't work on the more important stuff coders work on, because you need to test". That end bit was from a previous discussion though, not this one.

Dear project manager, please: 

Stop blaming the tester for the bugs in production, if you refuse to invest in the testing needed to find the bugs - in particular, since the bugs would not be there if we did not create changes so hastily under stress.  I did not put the bugs in. I did not help removing them either, this time. But I did help remove quite a bunch of other bugs with the choice of how to use time you did not question beforehand, even though you were asked to.

Stop calling the work with complex results of all the relevant bugs Monkey testing. That is insulting and does not make anyone more interested in delivering the results you actually look for.

Learn to think about delivery as a whole team effort instead of working to isolate really collaborative developers and testers into separate silos with the idea of efficiency that just does not work. Let us share the work and let us take in less so that we can actually run the task through. 


  1. Hi Maaret,

    Question; are you the tester in this story? I am richt behind you, support you and wish you a lot of strength! Don't give up.

    Jan Jaap Cannegieter

    1. Yes, that's me. As this is not constant, its not that bad. I've been in worse spots over the last 18 years in testing, so there's no chance of me giving up.

      It's like an amazing play I'm watching from the outside while still in the middle of it. And it leaves me wondering if colleagues in the projects realize how bad it sometimes makes me feel when the respect for other person's skills and good intentions is missing.

      But it can be the same the other way around. The same managers tend to blame developers for creating bugs and not seeing the connection that testing has to uncovering work not done.