Are these really lame reasons not to hire tester? (part 2)

This is the second part of my blog series looking at the “lame” reasons why companies do not hire testers as published by bughuntress. You can see the original post here:- LINK.

just to remind you, or if you have not read part 1; the general gist of the post by bughuntress is giving details of 5 lame reasons why companies do not hire competent testers. Through this series of blog posts I will look at each of those 5 “Lame” reasons and assess whether they are as lame as proclaimed by the original post.

This post I look at:

We don’t need to test a product until it is finished.

What bughuntress says:

Waiting for product to be finished is not rational, as it becomes more expensive and too difficult to make changes. The sooner you find and fix bugs the less expenses you will have and the better your reputation will be. Even if you release Beta versions before the final one, your customers would not be pleased by the product full of lags and defects. Do you need to take such a risk to lose your precious customers? Hardly.

OK, so lets start with the positives. I agree with the sentiment of the title, testing certainly does not need to wait until the product is finished. Testing can be, and often should be involved as early as possible in my view, although in my experience this does have its limits which I wont go into details here, but I may in a future post.

Now for the negatives. Firstly I have never in my life heard this given as an excuse for not hiring testers, so I am going to have to take their word for that. My bigger problem is with what the actual details of this section on their site is stating.

The details go into the old view point that defects found late in the development lifecycle cost more. If I said this was being excessively generalised I feel I would be being overly nice. People much more knowledgeable and qualified to explain why this is not (always) true have written plenty on this and a quick Google will find information on it, but to say that all defects found late in the process cost x times more to the project is just as incorrect as saying all defects found early in the life cycle cost x times more.

I would say that a more valid reason for wanting to start testing as early as possible is to allow for more opportunity to examine and find out useful information about the product. This can then feedback into the process which will help shape and maximum value the product provides to those that will use it. Might it save you some cost and headaches by finding something earlier than if you found it later? possibly but that is not always going to be the case.

My Verdict: A lame excuse (if it were used).  Not hiring a tester because you are not going to test until everything is completed does seem to me an ill-informed reason, which is probably why in 15 years I have never heard it being used as one. This excuse is more likely to be used as one for not hiring “right now” on a project. Do I agree with Bughuntress justifications for testing early? No, but I do agree there are benefits to be had by testing early.

Are these really lame reasons not to hire tester? (part 1)

I came across the following post the other day via a link on Linked in that a friend posted. you can see the original post here:- LINK

The general gist of the post by bughuntress is giving details of 5 lame reasons why companies do not hire competent testers, but while reading through it I could not help but feel that maybe the post was being a bit harsh by calling them lame. Therefore over the next few blog posts I will look at each of those 5 “Lame” reasons and assess whether they are as lame as proclaimed by the original post.  This post we look at lack of time or budget.

Lack of budget or time.

What bughuntress says:

Usually this excuse leads to making programmers do testers’ work. Indeed, testing by programmers themselves can save you some money. But you should take into the consideration, that hiring a tester is cheaper than hiring a programmer of the same level, so you will pay programmers for work that testers can do for less salary.

Another obvious thing is that when testing their own code programmers tend to miss some errors which testers wouldn’t. All in all, while developing a complex project it will become clear that testers are more of an investment than useless spending of money

So is lack of budget or time a lame excuse for not hiring testers? in my opinion the answer is a very short one. two letters short.. its “NO”.

Getting into the specifics of what bughntress is saying; I agree that when you don’t have dedicated testers, but you do wish to perform some form of testing, then there is a good chance that the testing will be done by your developers, or maybe your analysts, or BA’s or stakeholders. Are testers cheaper than these other people? probably, but are your testers (should you hire them) going to be always 100% utilised as testers?  if they are not then there will be time when they will be burning cost without adding value, unless they bring other skills in which case your still using one of those resource I mentioned a minute ago.

Also, I think that the view a developer testing their own code are more likely to miss an error that a tester would not is a little old fashioned and a bit of a myth in my experience. Even if they were the case just because you don’t have a dedicated test team, does not mean that a developer has to “mark his own homework”; peer reviews or any of the other roles I mentioned above could add a different viewpoint on the product being tested and add value. With these other things some pretty descent testing can still be achieved without the additional outlay for a dedicated tester in my opinion.

My Verdict: Not a lame excuse. There are very valid reasons why time or budget restrictions would mean that it was not viable or indeed sensible to hire a dedicated tester, and to assume that developers cant test is both wrong and disrespectful in my opinion.

No really its OK to blame

“It’s not a blame culture that we work within, but at the end of the day it will always be someone’s fault”….

I used to say this phrase a lot tongue in cheek when someone started talking about the “no blame culture”; in fact I still do; but I always believed that laying blame was a non-productive action, and only served to demoralise. My view however seems to have changed on this subject, and although I cannot pinpoint when they changed, it was brought to my attention after reading the following tweet from Jari Laakso:

My immediate response to this was that although I do not agree with giving a tester (or anyone else for that matter) the Guy Fawkes treatment, I did find myself thinking that there may be a valid reason that blame might lay at the door of the tester, or more likely at the door of the test department/team. So I  respond with the following tweet:

Off the back of this tweet I got some response about how blaming a person or team is never the answer. Blaming is bad! I did not agree with this sentiment, yet I felt uncomfortable because it went against what I had thought in the past for such a long time, and I could not articulate even to myself why I now felt so different.

I also noticed on twitter last week that another discussion had broken out about the subject of blame, which had a number of people involved including, but not limited to @JariLaakso, @michaelbolton, @kinofrost, and @maaretp. Again on reading these tweets my initial feeling was that some of these people were getting a little overly sensitive about the “Blame” word.

As my feelings were confusing me I was compelled to try to understand what I really feel about this and why; the following is what I have concluded.

  • In my experience when people refer to blame they are using the negative and informal definition of the word, which is to blast or damn.
  •  If we think of blame in this way then I agree that this is never a desired approach in any situation, and in my opinion unprofessional.
  •  The more formal definition of the word blame is to place responsibility for a fault or error, and this seems to me like a more constructive definition.
  • Saying that there is a no blame culture is basically saying that no one or team is ever responsible for things that are wrong or mistakes that are made. If I said we work in a no accountability culture would you think that was a good thing? I don’t.
  • In most of the situations where I have personally seen blame (using the more formal definition) attributed to a person or team it has appeared to me to be fair and correctly attributed. (in the situations where it has not, it is almost always been because of a snap judgement without doing sufficient investigation… also a bad practice in my view)
  • Assigning responsibility for a fault to a team or person in my opinion is perfectly acceptable, and in fact necessary to ensure that learning’s can be acquired and improvements to process or skills can be achieved.
  • Because people are so afraid to blame, things don’t change. This is a negative result because people think that being critical of someone or their team is a negative thing.
  • Blame does not create and us vs. them situation as was suggested to me on twitter. Us vs. Them situations are created by a lack of respect for each other, a lack of trust, and in some cases a fear of being “found out” by the other.

I don’t buy into this notion that to lay blame somewhere is a bad thing. I do think that it is unprofessional to berate, ridicule, degrade, or make an example of in front of others, but if they were responsible for the fault then I think it is OK to blame them for it, i.e. assign the responsibility to them, once you are convinced that sufficient investigation has been done to identify where the fault originated, because although I think blaming is perfectly fine, blaming the wrong person or team is not!