The Awful Truth About Test Estimation – discussed

At EuroStar I faced the challenge of discussing estimation and the awful truth about it. To make my live a bit easier I decided to use Prezi. If you Google-Fu, you’ll end up with all kind of stories (I’m deliberately not referring to them as presentations). Some of them are really great and if you look at them, they take you by the hand and tell you a story. Hopefully the story that the creator wanted to tell you…

Why mention it in this blog? Because the challenge was not in telling the story but in estimating the time required to tell my story. My ‘historical data’ is based on PowerPoint-slides, including animation, that help me tell my story step by step. Including details. Prezi is different, it’s like the red line. Not too many details, just some info to support the story. Mainly graphics, not text. So, I know how much time a PowerPoint deck takes, based on the number of slides. Now translate that into how much time a Prezi- flow takes!

I guess it was a combination of experience, knowing what I wanted to tell, trial runs, experience and luck that made it happen exactly as I estimated: after 30 minutes, it was up to the audience and my moderation skills, to have a good discussion about… estimation! Which lasted – as planned – the rest of the available time.

My point is that, even if you change the “tool” (from PowerPoint to Prezi), and the context (from a talk into a question session), you can use your experience and understanding of the “new context” to come up with an estimate. Also for your next test assignment.

Effort estimation is a necessary evil and will never go away…

The reason for any tester to get sucked into test estimation is a simple one. Your manager at some point in your career, will ask you how much time it will take to test the next release, project, product. You’ll probably do what I did: check what is – planned to be – in it, compare it to the previous thing you tested and come up with a number. A bit less than before if you’re more comfortable with the way of working and the system under test. A bit more if you’re feeling unsure about the quality. As a result, your manager won’t like it and you’ll probably get less than you’re asking for. Maybe, because it is an experienced manager that tricks you into believing this release is less complex or critical. Maybe because you’re not able to substantiate your estimate. Call it character, call it ambition, when this happened to me, I was not happy so I started my “quest” for a more reliable effort estimate. This quest is still going on…

I do realize that there is a discussion “against” test effort estimation in the traditional form, maybe even in “any” form. The arguments are valid as many start with “I don’t know…” (see one of my previous posts). On the dots you can put any item: my team, the product, the development team, the business, the business case, the target, the aspects to tests, where the defects are, what the deadlines are, … This is a non-limitative list and I know you can come up with many more items.

The awful truth is that we have to come up with an estimate anyway. Either we need to tell our manager what time we need to test or we need to show him what we can do within the available time. Including a high-level description of how, when, what, …. Whether we want to or not, because if we don’t do it, he will. Since I believe that craftsman are able to better estimate their work and to discuss, argument and agree about it, I think testers should do it themselves. It’s better than being told and sigh…

Especially for a tester, an estimate is an approximation, nothing more or less. We know that all kinds of things will happen that will disrupt progress, require additional time to investigate or explore, lead to a major change in the scope of the project and/or the product. I know we don’t control most of the factors that influence the required effort. But that doesn’t mean we can’t take them into account! In my opinion, we need to “collect” these factors and show the impact on the test estimate.

And by the way, against all current discussions and opinions, I do believe there is a “best practice” in estimation: you need to discuss, monitor, update, change and adapt your effort estimate continuously.

The awful truth about estimation revisited

Last Friday I submitted my presentation The Awful Truth About Test Estimation – Have I been wrong all along? to EuroSTAR. Turns out there is a lot to say, discuss, consider, think, explore,… about estimation and that 45 minutes, including loads of interaction, is pretty short.

Awful truth?

According to wikipedia, “Estimation is the process of finding an estimate, or approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable. The value is nonetheless usable because it is derived from the best information available.” To make life a little easier, wikipedia explains that “An approximation is anything that is similar but not exactly equal to something else. The term can be applied to various properties (e.g. value, quantity, image, description) that are nearly but not exactly correct; similar, but not exactly the same.”

So in fact, test effort estimation is a the process of defining a number – hours, man days, lapse time, … – that is nearly but not exactly correct AND is based on incomplete, uncertain and unstable information.
For me that is awful yet true.

Should we stop doing it?

Unfortunately, for most of us that is not an option. We need to provide some insight into the necessary effort for testing, because (project)management needs it to establish a budget request, (line)management wants insight into the resources needed for a project, et cetera.

…if you don’t know what to do

…if you don’t know how to do it

…if you don’t know who will do it

…if you don’t know where to do it

…if you don’t know with what to do it

…if you don’t know when to do it

…if you don’t know when to stop

…if you don’t know what to do first, last, in between

We should however always treat it as an estimate: nearly but not exactly correct, based on incomplete, uncertain and unstable information. And share the uncertainties, instabilities and incompleteness!

You should never stop doing it!

One of the most important lessons to learn about estimation is that you’re never done with it. Each day one of the uncertainties can become a certainty, decisions are made that remove instabilities, etcetera. As a tester you should continuously look at your estimates and adjust them to the new situation.

Biggest challenge: you need to convince (project)management that an estimate is an incomplete, uncertain and unstable number. And that fixed deadlines sometimes just mean that not all of the testing work is done… You could compromise but my suggestion is to do the best you can within the given restraints. And be open and honest about it. One of the best results I got was in a project where the project manager decided to stop detailing the requirements and start coding immediately to save time and effort on the development side (approximately 200 man hours). I did not complain or blame. I just told him that I expected that as a consequence the test effort would go up by at least 300 man hours due to the fact that we needed to find out about the requirements ourselves now and we expected more defects… After a prolonged discussion, he withdrew his decision.

See you in Gothenburg?

If you are coming to Gothenburg and are interested in attending my talk, please register here

You can also do so by visiting this page on the EuroSTAR website: “W9 – The Awful Truth About Test Estimation“

The awful truth about estimation – EuroSTAR 2013

I’m invited by EuroSTAR this year to give a challenging talk about estimation.

The Awful Truth About Test Estimation – Have I been wrong all along?

Abstract
Throughout my career, I tried to make effort estimation reliable.
With colleagues, I created a formal approach linked to function point analysis. That didn’t catch on. Was it too difficult? I worked on an informal approach based on questions about size, strategy, resources, and etcetera. Still only small successes. Does “Garbage in, garbage out” apply? Have I been asking the wrong questions?

Please join me in my quest for the right questions to ask. Help me to deal with this once and for all and solve this issue through our collective experience and do what testers are good at: asking questions in search for an answer.

Video message
A new phenomenon is that you promote your talk in a video message. For those of you who do not follow EuroSTAR or visit the website regularly, please check my message here:

 

See you there!

If you are coming to Gotenborg and are interested in attending my talk, please register here

You can also do so by visiting this page on the EuroSTAR website: “W9 – The Awful Truth About Test Estimation”

Hope to see you in Gotenborg!

STAREast 2013: April 28th – May 3rd

Looking forward to the STAREast conference where I’ve been invited to present.

Track: Reports of the Death of Testing Have Been Greatly Exaggerated

Due to the success of Martin Pol‘s lightning strikes the keynote contribution, I’ve taken on the challenge on presenting a track that is rowing against the current. The title does cover my message. Hope to see you there and discuss about the future of testing!

Tutorials

I’ve also been invited to present the tutorials Test  Management for Cloud-based Applications and High-flying Test Design Techniques again.

Successful webinar at EuroSTAR

On Thursday April 12th, I gave a 30 minute webinar followed by a Q&A session. The title “Moving into the Cloud? Make sure your test apporach is cloud proof!” attracted at least 150 delegates…

For those of you that were not able to attend or want to listen in again, please check this recorded version at the EuroSTAR website or follow this link.