How do we apply lean thinking in testing?

I read the scrum guide again lately and it talks about how it is founded on empiricism and lean thinking. I was interested in the lean thinking part and what it means for us as testers.

“Lean thinking reduces waste and focuses on the essentials”

How could we apply lean thinking in testing?

1 Like

I could think of one area - selecting tests in regression.

Sometimes, teams tend to ‘just run’ all the regression tests
without due consideration of the tests’ importance to the
coverage at hand. It’s a huge waste of time, resources, and

By carefully selecting the tests that need to be regressed
for a particular context, one could achieve reduction in waste,
achieving lean.


Optimisation can sometimes be a dirty word, when used against you. But let’s be honest, getting things done more effectively and in a good order is a wonderful thing, things like automating the right things, shorter and more specific meetings, fast delivery (releases) etc. can all be applied to how we think about testing and software development as a whole!


I used to work next to a production floor and they were applying lean thinking in everything that they do. They were always looking to continuously improve, they held regular kaizen events, which I found really interesting.

I tried to blog about change, touching on kaizen specifically, a few years ago.

1 Like

The definition of testing from Cem Kaner actually includes this word: ‘technical empirical investigation for evaluating a product, done on behalf of the stakeholders’
This one is quite straightforward - question everything others tell you, what you have, see, do, experiment, and explore - in order to make your own observations, model what you know, infer what could be useful/wrong/weird (combined it a bit with James Bach’s definition of testing).

“Lean thinking is a way of thinking about an activity and seeing the waste inadvertently generated by the way the process is organized. It uses the concepts of: Value, Value streams, Flow”

Without overthinking it I’d give some examples that you could be reviewing as a tester:

  • fastest way to reach some mission? If you take a day at this point to evaluate a feature; can you find ways in which you can reduce that time? - better data setup, faster env. spin, create a build package by yourself or start it locally without waiting for others or pipelines, understand some concepts that slow you down, find a tool or build a script that can help with similar things in the future…
  • efficient/valuable way to reach some mission?
  • how you can be most cost-effective as a test department/team, or product team, or business? - you might be having some business alignment problems - so your testing could be missing the target most of the time - you find issues, but not the ones that matter to the business; or you test things that you believe are interesting or important but business does care about;
  • how to get rid of waste? e.g. - you might write documentation that no-one reads;
  • how can you better communicate and make understood the evaluation you’re doing highlighting risks found; managers or colleagues you report to might ignore most of what you say, because you’re not being precise, or you’re talking on subjects they are not interested in, or you’re not focused on what they asked you to, or you can’t explain in simple manner the problems you have found, their impact or how you found them;
  • question a mission when it’s being given to you if you believe there are some aspects that have not been considered;
  • question a strategy that you believe is going to waste time and not actually help in designing the tests that matter and could find the worst problems fastest;
  • question the automation checks usefulness; maybe you’re spending too much time maintaining the wrong scripts instead of building other tools or scripts that could be of use to you now, or you have checks that find so minor bugs that none would even care if they are present in the product;
  • question the builds you receive from developers and their way of empirically checking the product by themselves; I’ve worked with many developers that leave crappy products for testing, and we go in a few weeks of feedback circles - just because they don’t even review the basic things of what they build.

I believe due to the way the testing has been developed over the past 30 years, that lots of wasteful methodologies and standards have forced managers and testers into being opposite to lean…

The business is spending money on you to get some value. How can you better provide value for yourself?
A related talk about waste and lean, that I like from Keith Klain: All Your QA is Hate You (Software Quality Anti-Patterns in Testing) Quality Jam London 2018 - YouTube

1 Like

I saw a talk by Mike Harris recently about Deming’s influence on how we think about quality, and concerning lean thinking and testing, I think Deming’s 14 principles for quality management are pretty good starting point for reducing waste and focusing on the essentials. You can read about them here if you like.

1 Like

In one agile team a scrum master was doubtful about manual test cases:
“Who will maintain them? When will you know, when they are outdated? How do people know where to find them?”

He preferred automated tests. The moment they failed, there was something to investigate.
In his opinion manual test cases required a lot of time and effort. Looking at lean he might call it overproduction.

Sidenote: he hired me for exploratory testing.

In the same company there was a time people walked to the system administrators to request a test environment. According to me this is a waste of motion and time.

The developers looked at the steps and decided to automate this. So a separate CI/CD line for test environments was created. So as a tester I could roll out my preferred test environment with a few clicks:

  • name environment
  • name software
  • version
  • and deploy.

There were still people waiting for test environments like the PO and analysts. So they got their own CI/CD pipeline.

Another thing I needed was a fast way to determine the version number of the installed software. Also known as “Am I testing the right version?”
The advantage of the CI/CD line was that enough information about the deploymment was logged. A quick look at the version number saved me a redeployment or a waste of overprocessing.

1 Like

Looking forward to taking some time to read and digest these learnings over the weekend :smiley: