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.
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…
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.
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:
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.