EuroSTAR 2015 Opening

I promised to share the opening of EuroSTAR 2015 with you. That’s why I’ve created a subset of slide images and share them in this image-blog.

Thanks for the many positive reactions I have received on the 2015 event.
Cheers
Ruud

PS As soon as I’ve recovered, I’ll share more insights and thoughts on the EuroSTAR 2015 conference through this blog.EuroSTAR 2015 - Opening.001 EuroSTAR 2015 - Opening.002 EuroSTAR 2015 - Opening.003 EuroSTAR 2015 - Opening.004 EuroSTAR 2015 - Opening.005

EuroSTAR 2015 - Opening.006 EuroSTAR 2015 - Opening.007 EuroSTAR 2015 - Opening.008 EuroSTAR 2015 - Opening.009 EuroSTAR 2015 - Opening.010 EuroSTAR 2015 - Opening.011 EuroSTAR 2015 - Opening.012

Advertisements

Why I chose a Coldplay song

When I was invited onto the stage at EuroSTAR 2014 in Dublin, they asked me what song I would like to accompany me. They suggested “Bonfire Heart” by James Blunt.
Maybe because I’m Dutch and we Dutch tend to be blunt?

I really like that song, but it had to be something by Coldplay. Reason is simple: ever since I was at the Mylo Xyloto concert they gave in The Hague, I’m a big fan. Not just because I like their music, also because they perform with enthusiasm, spirit and are doing everything they can to make sure that the crowd really enjoys the concert. A bonus for me is that their lyrics resonate with me.

Take for instance “Paradise”.

Schermafbeelding 2014-12-19 om 22.06.31

Funny thing is that, by changing a few words, I can actually make it a test song:
Imagine the “girl” is a tester at the start of his career or a senior tester implementing a new and better approach. Both are “expecting the world”.
Isn’t it great to be naive and innocent?
They discover pretty soon that the world is not ideal; in the real world testing as well as changing the “way we work” is an ordeal. The message I hear, if I continue replacing words in the lyrics, is that a tester needs to keep dreaming of that ideal world in any situation, to be inspired and motivated to overcome whatever he needs to overcome to achieve his goals.

If this test-lyric is in line with your test-story, I know you have a great story to tell to our community. And it’s perfectly aligned with “Walking the testing talk” since that is what it’s all about. Your story is all about good and bad experiences, lessons learned and almost forgotten are shared. You have tips, tricks, and good practices to share as well as the passion for our testing craft.
Take this opportunity to tell your story and submit it to EuroSTAR. The worst that can happen is that you have to speak in Maastricht in November…

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

Not AcceptableThe 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…

Estimation Philosophy 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.

Question marks

…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?

Register for my track at EuroSTAR

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!

Register for my track at EuroSTAR

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!