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


Testing of chatbots – the art of conversation, interpretation and validation

Deepika Mamnani
May 23, 2018
Chatbots are set to grow exponentially in the near future. Here’s what QA professionals need to keep in mind while building their testing strategy.

The European solar industry readies for the digitalization challenge

Marianne Boust
January 11, 2018
“Solar is now cost-competitive against other sources of power generation”—World Energy Markets Observatory, 2017

Agile means profitable

Herbert Goertz
December 1, 2017
A Capgemini ad asks the question: “What good is an ERP solution if it doesn’t increase profitability?” The answer is: “Not very good, and also not very agile.”

By continuing to navigate on this website, you accept the use of cookies.

For more information and to change the setting of cookies on your computer, please read our Privacy Policy.


Close cookie information