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


For Scrum and Agile experts, starting a new assignment with the right questions is the answer

Rik Pennartz
Date icon September 10, 2020

How a measured, practical questionnaire can help you hit the ground running – every time


Site reliability engineering

Genesis Robinson
Date icon August 7, 2020

Due to the current state of how we monitor, alert, and log our digital ecosystem, it takes...


Your path to Agile at Scale: avoiding common pitfalls

Robert Wegener
Date icon August 5, 2020

How a focus on people, change management, credibility, and honesty can form your foundation...