(508) 250-0159
In an earlier article, I argued that Quality Assurance (QA) and the revived role of Quality Engineering has largely been ignored or considered an afterthought during companies’ transitions from Waterfall to Agile.
The growing use of the term “DevOps” perfectly illustrates the industry’s continued neglect or, rather, lack of, appreciation that these Quality roles have on this development process.
Check out this definition I copied straight from TheAgileAdmin.com website explaining DevOps:
“DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.”
I’m sure the business view of DevOps is more about how to deliver software as fast and as efficient as possible with, of course, the highest quality at the lowest cost. And the sound of DevOpsQA or DevQAOps just doesn’t roll off your tongue quite like DevOps does. Maybe we can call it Q’devOps using a French accent to emphasize: A delicious recipe for perfection!
Regardless, here is my revised definition:
“DevOps is the practice of operations, development, and quality engineers participating together in the entire service lifecycle, from design through the development process to production support.”
What a difference one word makes!!!
DevOps Applied
I see 2 main USE cases for DevOps. I’m sure there are many more.
- Continuous Integration & Continuous Deployment
- IT Operations developing applications
Both areas are trying to improve their efficiency by integrating best practices from each other while increasing their level of agility.
For DevOps to Work, You Need a Sound Quality Engineering Strategy
My recommendation for DevOps is you need quality engineers embedded on your Agile teams. These professionals should be responsible for the test automated framework, and they should develop and enable development of automated test cases that are combined, integrated, version controlled and deployed alongside your software.
You also need quality assurance folks testing the pre-final deployed version prior to releasing your software to production.
The QA DNA
As much as everyone would love to have developers and ops folks testing all their own software, generally speaking, they just don’t think the same way as someone that has the QA DNA.
They can and should create some automated tests, preferably on other team members’ software. But leave the bulk of the testing to the devious, non-trusting (in a good way) quality minded folks. I’m sure the same can be said for the ops folks crossing over the development lines and vice versa, to some degree.
Better call “Zoll”!!
(Pronounced Zaul. Ok, I know this is a “play” off the AMC hit TV series and only my high school friends know that was my nickname, but I thought it was funny).
So if your DevOps process looks anything like this:
- Deploy it live and wait for customer feedback.
- Throw it “over the wall” to a separate QA team for manual testing.
I think you could really benefit from integrating a more agile quality engineering strategy into your overall software development life-cycle process.
Here are five ingredients that I recommend you take to ensure your Agile team is testing its software in the right way:
1. Automate Test Deployment to the Test Environment
Automated tests should deploy alongside your software every time it is loaded to your test environment. The embedded quality engineer is usually the one who creates or enables the creation of these tests.
2. Run Test Automatically With Deployment
Tests should run automatically when you deploy the software. No one on your team should have to sit and manually execute a series of tests. Nor should anyone have to manually test features “to see if anything that use to work, breaks.”
3. Build or buy a Test Automation Framework
A test automation framework sets the rules for how your tests will be run. As your developers build the product, your QE staff will be building new test cases for all the new features. Over time, you’ll develop a library of regression tests to run against your software.
A good test automation framework will allow you to reserve your test environment, choose which tests or suites to run, provide error escalation methods, manage test data, log results, and provide execution visibility.
4. Make Sure Your Team is Completely Committed to Testing
Testing must be a baked-in part of what you and your team do. Include it in your definition of “done.” If it’s not, you won’t build up the automated test library you need to ensure quality software. Unless, of course, you use your customers for test purposes.
5. Test Continuously
Building automated tests directly into your deployment process means you’re going to be testing your software all the time.
There will never be a deployment that will not go through your test automated framework. Sorry for the double negatives, but I hope you get my point. You need discipline.
Adding testing to DevOps Makes Everything Work Better
Your goal shouldn’t be to only develop and release “usable software” often. It should be to develop and release software that’s meets or exceeds customer expectations free of any defects.
Agile is not an excuse to throw away testing. On the contrary, automated testing is even more important in a high-velocity, continuous-release environment.
Your Customers really don’t care about your development process, whether you are agile or waterfall, whether your IT folks have suddenly become QA engineers, or your developers have become experts in operations, etc.
They just want your fully featured product to work—flawlessly.
What’s been your experience with DevOps and QA?