I saw this thread from another wonderful Rosie.
And I’d love to know how other testers are managing day to day with Continuous Deployment.
How do they overcome the hurdles? The learning? What practical things can they do to become better software testers in CI/CD environments?
My two cents…
For me if you’re doing CI and CD you’ve also got to be doing continuous testing (CT), so you need to have automated tests to check regressions in the pipeline.
Over here we’re big advocates for Quality Engineering and we see quality (which includes testing) as a shared responsibility - this makes us put testing in the definition of done for everything we set out to do, and there is a team-wide discussion around that topic before any developer codes anything. So we have people (such as me) as quality coaches / strategists that help the whole team (devs, POs, UX experts, architects, etc.) in evaluating risks, come up with test strategies and understand what test automation should be put in place for each change. This lets us handle the “known unknowns” problem when building software and delivering it as fast as possible.
For the “unknown unknowns” problem though, I believe you will always have situations where you really need to do manual testing and there are ways to make that process more efficient in a CI/CD setup. Just think about how a lot of times, for testers, just the setup of a test environment takes hours or days. CI/CD processes should automate and compress the time for building such environments down to minutes or seconds, so that the manual testing activity may occur as soon as possible once a change is pushed.
There is also another thing to consider in this regard (and going back to one of the core messages from Rosie Hamilton) - when you’re doing CD and the time to push changes into production has come down to minutes, you get a different perspective over the risks involved in every change. There used to be a lot of non-critical stuff that could go wrong and you would do manual testing because everything had to be perfect on release day. But now the risk is lower in a lot of cases because you know you can react really fast if something is detected in production. This is also why observability (and monitoring) in production also becomes a really important topic here and we as quality / testing professionals should develop our understanding of such tools and processes.