Whether you specialise in automation or focus on exploratory testing, this article will help you understand CI/CD pipelines and how you can make an impact.
What You’ll Learn:
What CI/CD pipelines are and why they’re important.
How CI/CD pipelines can benefit your testing efforts, from faster feedback to improved quality.
How you can contribute by reviewing automation, identifying gaps, and focusing on non-functional testing.
Why your role as a tester is essential in ensuring reliable and effective pipelines.
After reading, share your thoughts:
How do you add value to CI/CD pipelines in your current role?
What challenges have you faced when working with pipelines?
What’s one tip you’d share with testers looking to get involved in CI/CD?
It’s jarring that there’s a quote at the beginning, but I have no idea who is being quoted.
To answer your actual questions though:
I work closely with devs and DevOps to keep tests running, as well as change which tests we run, and when, for our various pipelines.
There’s real hardware behind the scenes of pipelines, and those can cause noise in test results.
Remember that you don’t need to be doing everything involving the tests in CI/CD. It’s perfectly okay to hand off pieces that others can do, especially if you need to focus on something that requires your expertise.
Hi @tybar, I think the quote you see at the top of an MoT article would usually be coming from the article itself. Basically, it is meant to signal the main message of the article if that helps?
There’s an important consequence of the reduction in risk, time and effort between a developer working on some code and it being in production (that pipelines can give you). It lets you work in small batches. By that I mean you can have many small releases rather than fewer releases that are each bigger.
Working in small batches in turn has two consequences:
There’s less that’s new or changed per release
The highest priority / most useful changes can get into users’ hands immediately, rather than having to wait until the time for the next scheduled, e.g. quarterly, release
The first one is more obviously a tester thing as it changes the risks associated with each release, which informs what a tester should look at. The second one is more of a quality engineer thing, and I recommend you watch the first 15 minutes (or all) of this video by Jez Humble, who co-wrote one of the standard books on CI/CD: https://www.youtube.com/watch?v=2zYxWEZ0gYg
There’s an important and confusing detail in the CD part which, among other things, allows the techniques and benefits from Ady’s article and the comments to apply in more situations.
As Ady says, there are two meanings of CD:
Continuous delivery = getting a release candidate, i.e. code that you could put into production if you wanted to
Continuous deployment = putting the release candidate into production
It’s easy to default to thinking that all software is web-based Saas, with the economics, constraints etc. that go with that. However, you might be working on software that e.g. controls a steel plant. In that context you can’t push new code into production several times a day (like e.g. Amazon does) because there’s a physical production line that must be kept running.
However, even though you can’t do continuous deployment to the steel plant, you could still do continuous delivery. That means, among many other things:
There’s always a version of the software that could be deployed
Changes to a pre-production test or staging environment can still be made often, in small batches
So even if you can’t deploy more often than once a year (for instance), you can still be updating a staging environment frequently, via helpful automation as described in Ady’s article. As with all tools and approaches, you need to work out how to apply CI/CD/CD to your context, to get as many of its benefits and avoid as many of its drawbacks as possible.
Re. the benefits and drawbacks point at the end of my previous comment, a small DevOps / QE point. Given that CI/CD means you could have frequent releases, it can be hard to work out which version of the software produced a given line in a log e.g. in production. This can make it hard to investigate and report production incidents.
As part of CI/CD it’s worth putting in a bit of effort into linking software version to logs in some way - the details of this will vary by context. Where I work, the build version is part of the meta data attached to each log line, and this happens automatically rather than developers having to remember to add something to each call to the logger:
It’s me who is being quoted. It’s the last paragraph of the article at the end. I apologise you found it jarring and I’ll consider adding my name if I use that technique again.
What CI/CD pipelines are and why they’re important.
How CI/CD pipelines can benefit your testing efforts, from faster feedback to improved quality.
How you can contribute by reviewing automation, identifying gaps, and focusing on non-functional testing.
Why your role as a tester is essential in ensuring reliable and effective pipelines.