Workload estimates and the lamb of Istanbul.
There is a fantastic restaurant called the Istanbul near where I live. They have the Chaîne des Rôtisseurs plaque on the door. Everything inside is a reflection of excellence, and their Tripadvisor rating is top notch.
One of their most popular dishes is a juicy lamb fillet fried on an open fire served with creamy caper sauce. A friend of mine was coming over from London, and I suggested we’d try the famous lamb. ‘I’m not a huge fan of lamb’ my friend admitted after a discussion ‘so how does it taste?’.
Of course, explaining it will make no difference. There is no way to know how this famous open-fire lamb tasted unless we ate the famous open-fire lamb first.
You cannot know something before you’ve experienced it.
The next day at work my client asked the same question. How can we know how long it will take to test our new release candidate? Could you give us a workload estimate?
‘The thing is, that you cannot know something unless you’ve experienced it first. There is no way to know how the Lamb of Istanbul tasted unless you ate the Lamb of Istanbul first’ I explained to the client ‘It’s the same with software too…’
I have no way to know the quality of the software when it arrives on my desk. I only know it after I’ve tested it. And guess what? The quality of the software is the defining factor on how fast or slow it is to test it.
It’s slow to work with bad software and fast to work with a good one.
So which is it? Is it good or bad? We have no way to know that, without testing the software first.
The thing with testing is that it will always fill up all the time we allow it. Give me one hour of time, and I will fill it up with testing. Give me a day, and I will fill it up with testing. Give me a week, and I will fill that too with testing.
After an extensive monologue, I finally asked the client ‘So how much will you give me?’
She gave me three days.
