Test Improvement is choosing

For me personally, one of the most difficult things in life is choosing. Especially because I don’t know what would have happened if I had chosen differently… And in the back of my mind, that “what if” game is constantly played. 

keep-calm-and-choose-wisely-33So my expert advice in test improvement is to choose wisely and consider several (all?) options. Don’t make choosing an everlasting process, just make sure you choose what helps. To be able to choose, knowledge about and experience with several approaches and models is necessary. Try to find a way that enables you to compare them and find the combination that suits the context and the purpose.

What usually helps is looking at aspects like:

  • Testing only?
    Is the scope of the model testing-only or does it consider a broader area?
  • Training?
    Is training available to ensure that everyone involved has the opportunity to learn about it.
  • Staged or continuous?
    Is the model prescribing a standard sequence of improvements in (big) steps or does it give free choice in the sequence of improvements in (small) steps.
  • SPI related?
    Is the approach or model linked to a Software (Process) Improvement model or approach that is already used within the organization or linked to a SPI approach that would help to improve more than just testing.
  • Scalability?
    Can you apply it to help a single project? A team? A department? A complete organization?
  • Are improvement suggestions “included”?
    Some models and approaches focus on finding the current status of testing and the required status; several include concrete improvement actions and highlight enablers
  • Required budget / investment?
    How much time/effort is required for preparation, execution and implementation of the implementation. What is the claim on the organization? Especially since you take into account that Business as Usual will always need to continu. And that the required budget needs to be available; in other words, your approach has to be fit for budget as well.
  • Top down? Bottom up? A mix?
  • Alignment with current test and development approaches, e.g. waterfall, iterative, incremental, Agile, Scrum, DevOps.
  • Culture
    Align your improvement approach with the culture of the organization and its peopke; although this is not typically something that is defined in a SMART way, this is key to success.
  • People
    Do the people in the organization like the improvement approach and are they willing to change in line with it. Again not typically something that can be defined in a SMART manner…

When I choose based on these – or similar – aspects, I tend to organize a walkthrough of my approach with experienced fellow testers. For me, it softens the “what if” voice in the back of my head.

Peer review gone wrong

Thank you Cyanide & Happiness!

The models and approaches to choose from are plentiful, probably worth (yet) another blog post.

Advertisements

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!