Agile Testing Estimation

Discussions around agile testing estimation within software development are plentiful. Many different approaches have tried – and largely failed – to make estimation more accurate. What I love about estimation within an agile approach is that the aim isn’t to make the estimation necessarily more accurate, but to find a more suitable measure.

In addition to how you’re going to estimate, the discussion around how the testing involvement fits into your estimates will inevitably crop up. Should you have a development estimate and a separate testing estimate? It’s a subject often misunderstood, and one that to explain properly, we need to explore the Agile Manifesto itself.

The key message here is to not complicate things. Estimation is an art – it’s not something that a catch-all process can help you solve alone. The best estimates, at any level, are those that have been discussed, questioned, debated and finally agreed upon; collaboratively. This can be hard enough to achieve within a group of developers, but when you add a group of testers into the mix as well, you’re dealing with a different dynamic of thinking.

And yet I’ve witnessed so many Agile teams either treat their testing estimates separately, or don’t even bother with them at all. When digging further, the reasons for this often stem from the testing element of a user story being treated as a specific phase, rather than a fundamental part of that story that must be completed for it to be successfully closed. In other words; more value placed on the process than the individuals and interactions.

Testing isn’t just a phase in Agile

I personally see testing within Agile projects not explicitly as a “phase”, but an activity that happens as part of every single user story. I’ve seen Kanban boards before, for example, with “Testing” having its own column. I’ve never liked this setup as it helps turn those invisible walls between development and test into reality and encourages an over the wall handover.

It’s easy to understand why test estimates are a secondary concern when teams run projects this way. This can quickly become a problem when you stumble on a relatively trivial development task that could have major implications on the system; thus involving significant test time upon completion of development. You’ll learn very quickly that just because something is easy to develop, does not necessarily mean it is easy to test. And visa versa.

A collaborative estimation session is essential. To avoid any major imbalances with time (after all, a task might still take longer to develop than to test), we should be basing our estimates on complexity instead. This way, both parties can input into a relative estimate that makes sense for everyone. There are many different techniques to use for relative estimation – far too many to go into detail in this post – but using user story points via the Fibonacci scale is an excellent way to estimate software development and testing tasks.

Another fundamental from the Agile Manifesto is our desire to frequently produce working software. I’ve worked in this industry long enough to hear a developer proudly proclaim that “it works on my machine”. This is not a good example of working software. To deliver things incrementally, the finished output from each sprint must be fit for purpose and tested within the environments that it will be used. This is another simple reason why the test input to estimation is so critical to a successful sprint.

Collaboration increases the value of estimation

It should go without saying that testing estimates are important. Like most things, Agile techniques don’t reinvent the wheel and don’t try anything crazy; for the most part, it just asks that you use common sense and focus on the right things.

We’re back to collaboration again and, whilst so simple, it really is the key to a good estimate. Collaboration and a mutual empathy between developers and testers is the only way an estimate can be seen even remotely accurate. Estimation accuracy is an entirely different conversation as I’ve already mentioned, but all we can do in an Agile world is everything we can to measure appropriately.

Conclusion

Ultimately, in its purest form, to run a successful Agile project we should be looking at as many ways to ensure collaborative working as possible. That starts with a vision and then leads to estimation. Getting rid of the internal departmental boundaries that so often surface is essential. Don’t treat your testing as a separate phase, but an integral part of every single user story that should be treated with the same importance as the development tasks that are spawned from it.

Understanding that an estimate is only truly established when the complexity is assessed and agreed on by all parties is the first step to building the confidence we need to make estimates truly valuable, and not just a tick box exercise.