Testing Fast and Slow – Simple techniques to improve speed to test in agile projects

Publish date:

Optimizing testing effort in all ways within acceptable ranges of quality is critical.

“When faced with a difficult question, we often answer an easier one instead, usually without noticing the substitution”  – Daniel Kahneman  in Thinking, Fast and Slow

This is very relevant to the world of Agile and software testing.,

Testing is a proven bottleneck in agile delivery. As I engage with clients and  teams in this space, I notice that there is a tendency to consider Test automation as the only way to achieve speed. This is because automation is an area we are familiar with and hence viewed as the easiest way to achieve speed to market.

While automation is certainly a strong lever, there is a significant investment to build the infrastructure. Not everything can be automated particularly in legacy environments. Very often automation does not work because of environmental and data constraints.

Optimizing testing effort in all ways within acceptable ranges of quality is critical. There are very simple techniques which can help in building optimum test strategies.

Here are my top five techniques that the QA team would do well to think about to improve speed to test.

  • Use the concept of testing for minimum viable product particularly for first few sprints. A minimum viable product has just core features to deploy the product, and no more. Testing only core features is an intelligent way  to collect the maximum amount of validated learning about customers with the least effort, which in turn helps in building an optimized test strategy.
  • Calculate business value of every  feature that you are going to test. This will help determine criticality and optimal test coverage.
  • Calculate Cost of delay of every critical feature that you are going to test. This will establish priority of every feature and will give room for negotiating with the product owners, business and development team on what features will be delivered in a sprint and what can be pushed to subsequent sprints.
  • Use Work In Progress limits for test tasks.Work in progress (WIP) limits determine the minimum and maximum amount of each sub task. The sub tasks can be test requirements, test design, test script creation, automation, execution etc. Limiting the amount of WIP improves throughput and reduces the amount of work “nearly done”.WIP limits also highlight bottlenecks in a team’s delivery pipeline.
  • Take above concept one step further by mapping WIP limits to the team’s roles.In a scrum team you would ideally have a technical tester /software development engineer tester and a functional tester as core dedicated roles and performance testers, automation scripters, security testers as shared roles. Create a status specific for every role. If bottlenecks occur in a certain status (example software development engineer tester), it is an indicator to plan for additional capacity.

Intelligent testing to get a shippable product as opposed to nearly shippable in 2 to 4 weeks is the only true indicator of success. The rest is theory.

Related Posts


No one likes waiting. With Continuous Delivery, now you don’t have to!

Venky Chennapragada
Date icon March 22, 2021

Automated and on demand – here’s how, why, and when you should adopt Continuous Delivery...


How to liberate your legacy applications to unleash powerful, agile next-gen apps

Erik Haahr
Date icon March 1, 2021

Discarding the burden of an existing traditional applications landscape will bring clearer...


Re-think authority and responsibility in the agile company

Nick van Zuijlen
Date icon February 22, 2021

To be successful, teams need quick turnaround on decisions.