What are the QA risks in automated software release management?

I worked at a big financial firm where we wrote a lot of code. When the software release management process was streamlined, it allowed a lot more bugs through to live systems.

When you automate software release management, everything from development to retirement gets sped up, including the whole QA process. Do you want to entrust QA to automation? If you release a bug that affects 1,000 people, that's bad; If the bug affects 100,000 people, it will get noticed. It could put you on the front page of the news.

Automation of the software release management process for large-scale cloud deployments sounds great in theory. The process can save time. But only do it when you are sure you have flawless releases.

Flawless releases rely on QA intervention. The QA process should catch every defect. If you choose SaaS for application release automation (ARA), QA people should provide checks and balances.

If you verify the quality of software releases, you can still automate most of the steps, as long as you include intervention steps. To go step by step is not ideal for release speed, but if you don't put those checks in there, you will miss potential bugs. You only get to make one or two mistakes with your customers before they look for another product.

Many ARA products are not mature. When you evaluate cloud providers of automated software release management services, you will probably have to customize cloud QA checks and balances yourself. Ask an ARA vendor:

• What access do we have during the automation flow?
• Can we actually see things in the process as it goes and make adjustments?
• Is it possible to put breakpoints in the process for verification?

You want flexibility; you want automation, yes. But you still need enough control to have an intervention in the event when needed.