When it comes to software quality assurance, most people think of phase at the end of a project. This testing phase is usually performed by “quality assurance” testers. The traditional project delivery model is to blame for this. As someone who worked as a software tester for years, I know about the pains of doing all testing at the end.
The problem of course is that when testing happens at the end, after a development phase, it is too late. What you are doing is trying to inspect quality in, instead of building quality in.
Lean manufacturing and lean software development is about building quality in. This was one of W. Edwards Deming’s, a pioneer in the lean and quality movement, motto’s . To build quality in, testing should take place all throughout the project. Testing early reduces the cost of defects because the earlier you catch defects, the cheaper they are to fix.
For this reason, it is well advised for software delivery teams to apply lean principles and automate as much as possible. Automation shouldn’t only be a set of regression tests that run at the end. Automation should take place all throughout the entire software development and release process.
Automation can begin in development using test driven development (TDD). For more on TDD, see my post on why automated testing is needed early and often.
After TDD, automation can be applied from build and deploy to acceptance tests.
This brings us to the process of Continuous Delivery. Continuous delivery is all about creating reliable software releases through build, test, and deployment automation. Today, more software organizations are reaping the benefits of continuous delivery, yet for most it’s still a pipe dream.
People think the idea of automating everything is too daunting, or can’t be done for their application. More and more we are now seeing that continuous delivery can be done, for any application or organization, no matter the size. A good way to start is by looking at your current release process, and finding the biggest bottlenecks. You can then start to automate over time, targeting the bottlenecks first.
By automating the whole software release process, you build quality in. This makes everybody on the delivery team responsible for quality, not just a “QA” team who tests at the end. For manual software testers, continuous delivery enables them to focus on exploratory testing.
There are many other benefits to TDD and continuous delivery, but perhaps the greatest is the reduction of stress for delivery teams. If you’ve gone through a production deployment process, using manual processes and ad-hoc configuration techniques, you know what I’m talking about.
For those who already use lean development techniques this information shouldn’t be news to you. If you still work in an environment that uses SDLC processes with little to no automation, the topics I’ve covered only scratch the surface.
Some great books I recommend on lean software development and continuous delivery:
- Continuous Delivery by Jez Humble and David Farley
- Lean Software Development, An Agile Toolkit by Mary and Tom Poppendieck
- Extreme Programming Explained by Kent Beck.
By using continuous delivery and automating as much as possible, everyone on the delivery team is responsible for quality.
About the Author: Mike MacIsaac is the president and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. Follow Mike on Twitter @MikeMacIsaac or subscribe to Mike’s blog.
