The lift to work: an estimation story

I have a little story to share with you.

Brian is sitting at home watching the football with a beer one Sunday afternoon, when in the middle of the second half the phone rings.

Slightly disgruntled at the interruption, Brian answers the phone to find his best friend and co-worker Simon on the other end. After some some catch up chit-chat Simon asks if Brian can drive him into work the following morning.

Brian agrees to giving lift to Simon. but then the following conversation happens:

Simon: Brian, how long will it take to drive from your home into work?
Brian: 45 minutes.
Simon: Hmm that’s not going to do, I need you to drive it in 30 minutes maximum, can you drive in that time?
Brian: No Simon, like I said the journey takes 45 minutes.
Simon: Can you do it in 30 mins if you leave at a different time?
Brian: Well maybe, but I need to be into work at my normal time so that’s not an option, but I could leave earlier if you need to be there 15 minutes earlier than I normally get into town; would that help?
Simon: No its not the time that I get there, I don’t want the drive to last more than 30 minutes. What if you used a faster car?
Brian: Given the time of day the heavy traffic will mean that a faster car will make no difference.
Simon: But Brian, I was talking with Stacy at a BBQ yesterday afternoon, and she told me that the journey should take no longer than 30 mins
Brian: Simon, Stacy cycles into work, she does not even drive!
Simon: Brian, that really not good enough. unless you can dive it in 30 minutes don’t bother.

In this little story Simon is being very unreasonable. He is taking advice from someone who does not have any experience in this Journey, but is not listening to advice from someone who does.

This story is obviously made up, but if you replace Brian with one of my test leads, and Simon with one of my Project managers then it becomes a real conversation I over heard last week. The subject was not  drive to work however, it was a test estimate for a well known piece of software.

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.