Lean Six Sigma for automatic testing
Six Sigma is a discipline for reducing defects by reducing variation: the same input should reliably produce the same output, and where it doesn't, that variation gets measured and root-caused rather than shrugged off. It started in manufacturing and now gets applied to any repeatable process — software delivery included.
Here's why that belongs on a testing page: manual testing is itself the variation problem Six Sigma targets. A person running the same check by hand doesn't reliably produce the same result every time — attention lapses, a step gets skipped, a borderline case gets judged differently on a Friday afternoon than a Monday morning. Turning that check into an automatic test is a direct application of the Six Sigma mindset: the same input now reliably produces the same output, every time, because a script doesn't have an off day.
That doesn't make automatic tests immune to variation — it relocates it. A flaky automatic test, one that passes and fails on the same code with nothing changed, is exactly the kind of variation Six Sigma treats as a defect worth root-causing, not a nuisance to re-run until it goes green.
Learn more at iSixSigma's getting-started guide.
Examples you can ask AI
- What does 'Six Sigma' actually mean, in plain terms, and why would reducing 'variation' matter for software testing specifically?
- How is manual testing itself a source of variation, in the Six Sigma sense, compared to an automatic test that runs the same way every time?
- How would I apply Six Sigma's idea of 'root-causing variation' to one specific flaky automatic test, instead of just re-running it until it passes?