Quality processes in Continuous Integration/Deployment

In traditional waterfall and agile processes we implement a test strategy to set expectations (and receive feedback) on approach for a release (multiple sprints of work) and test summary to capture results of the execution (functionl, security, and performance testing).

In a a CI/CD model when we have a 2 week sprint and plan to deploy every 2 weeks it seems a bit cumbersome to do a strategy and summary every 2 weeks. Ideally the summary could be pulled from an automation tool and produced to a dashboard so that should not be too bad.

Is there a different approach to the strategy?

Are there other quality tollgates (maybe a bad choice of words) that we should consider?

From a quality process audit perspective is there anything else to consider?

Any feedack appreciated.

-Jeff

I would add that having a long-term strategy should not be incompatible with 2-week release periods unless you are releasing something brand new each time. So this depends on a scope of each release. Release scope defines the scope of testing as well: usually it is quite a challenging task to test absolutely everything for short release periods. Of course the bigger the better, but some priorities must be established.

Sure, automated testing tools seem to be the best way to deal with the lack of time here - given that you have such a solution which is compatible with CI and at the same time can perform regression testing properly. By the way, if you need to run some UI regression tests, I would suggest you trying Screenster, a visual testing tool which was designed to help with UI testing in CI environment.

I'm not sure what you mean by setting a strategy and summary, but it sounds like you mean writing something. Strategies (and other common test artifacts) don't have to be heavy things that drag you down. If they aren't helping you do a good job testing, or release more often, I would encourage you to abandon them.

Regarding CD, not to be dismissive of your point, but releasing every two weeks isn't close to continuous delivery. This is the standard compressed waterfall interpretation of agile that many companies take. The more often you want to release software, the more crucual it becomes to have useful quality percieving activities like pairing, layering of automation, build pipeline automation, and monitoring. It also means your testers must be technical for some definition of the word technical.

To start with though, I'd encourage you to reevaluate what strategy and summaries are, and why you need to create them every two weeks.

2 Answers

To start with though, I'd encourage you to reevaluate what strategy and summaries are, and why you need to create them every two weeks.