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

ADMnext

Engaging in Agile – the more the merrier?

Christo Martens
Date icon December 1, 2020

Here’s why adding the right engagement manager can help your Agile teams better focus on...

ADMnext

No nonsense Agile: Why true agility is simplicity

Rik Pennartz
Date icon October 30, 2020

When faced with increasing complexity, simplicity is still your key to agility

agile

Eliminating work silos to drive business value in your customer experience programs

David Salguero Kuiters
Date icon October 16, 2020

Introducing Agile within your (digital) organization means that new processes, practices and...