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

quality assurance

World Quality Report 2018-19: Key trends podcast

Sathish Natarajan
Date icon October 3, 2018

This podcast will take you through the key findings of the World Quality Report 2018 and also...


Enterprise’s valuable resource is data in the digital world

Shivakumar Balasubramaniyan
Date icon September 27, 2018

Data is a vital resource for an enterprise. Read this blog to learn more about the economics of...


Do you feel that agile is losing you?

Date icon September 19, 2018

Quality is the correct expression of a project well done. But how do the testers put it at the...


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