The QA Engineer's Role in CI/CD

If you learned QA in a traditional environment, CI/CD can feel like it's shrinking your role. Tests run automatically — so is there less QA work? The answer is no, but the work is different. The tools change. The timing changes. The deliverable shifts from "sign-off on a release" to "build and own the automated safety net." This lesson makes that shift concrete.

The traditional QA model

In a waterfall or late-stage QA model, the sequence looks like this: developers code for two to six weeks, hand a build to QA, QA runs a manual test cycle for another one to two weeks, bugs are filed, developers fix them, QA retests, and eventually a release is signed off. The QA engineer is the last human gate before production.

This model has a real strength: it catches a lot of bugs before they ship. It has real weaknesses too: it's slow, it bottlenecks at QA, and it creates an adversarial dynamic where developers see QA as the team that holds up releases. The later a bug is found, the more expensive and disruptive the fix.

The CI/CD QA model

In a CI/CD team, the sequence is parallel rather than serial. QA doesn't wait for a complete build — QA is involved from the start.

In sprint planning, QA reviews user stories and acceptance criteria. Ambiguities in requirements are caught here — before a line of code is written. This is the cheapest possible bug fix.

During development, QA writes automation alongside the feature. When a developer opens a pull request, the automated tests already exist, and they run immediately as part of the CI pipeline. The PR cannot merge if tests fail.

In the pipeline, QA owns the test stage. Which tests run? In what order? What triggers the nightly regression? What's the retry policy for flaky tests? These are QA engineering decisions, implemented in pipeline YAML.

At release time, QA's role is to confirm the pipeline is trustworthy — not to run manual tests that have already been run automatically 50 times on the same code.

What stays the same

The core QA craft doesn't change:

• Test strategy — deciding what to test, at what depth, and with what priority. Automation doesn't make this decision — a QA engineer with domain knowledge does.
• Risk-based thinking — identifying what's most likely to break and most important to verify.
• Exploratory testing — structured exploration still finds bugs that no automated script would predict. This becomes more valuable in CI/CD, not less, because it's the work automation genuinely can't do.
• Bug advocacy — articulating the impact of defects and prioritising them with product and development teams.
• Test design — writing automation that's durable, readable, and actually validates the right things.

What's new in CI/CD

Pipeline configuration. You will write YAML. In this course, that means GitHub Actions workflows. In other organisations it might be Jenkinsfiles, GitLab CI YAML, or Bitbucket Pipelines. The syntax differs; the concepts don't.

Test environment management. In CI, tests run against dynamic environments — staging, preview deployments, Docker containers. QA engineers manage test data, environment variables, and the seeding scripts that make these environments testable.

Test execution optimisation. A 45-minute test suite is a broken test suite for CI purposes. QA engineers optimise: parallelise jobs, shard long suites, tag smoke tests, cache dependencies. Chapter 4 covers this in full.

Production monitoring as a QA input. In teams doing Continuous Deployment, QA engineers track error rates, latency, and user-reported issues in production. These signals feed back into the test suite — a production bug that wasn't caught is a missing test.

The SDET and Quality Engineer titles

"Software Development Engineer in Test" (SDET) and "Quality Engineer" are two titles that have emerged to describe the CI/CD QA role. They signal that the job blends QA knowledge with engineering skills: writing production-quality automation code, configuring pipelines, maintaining test infrastructure.

You don't need to hold these titles to do this work. Many teams simply call the role "QA Engineer" and expect these skills. But if you see these titles on job descriptions, you now know what they're describing.

⚠️ Common mistakes

• Waiting for the "QA phase" that never comes. In a CI/CD team, there is no dedicated QA phase. If you're waiting for a complete build to test against, you've already missed most of your opportunities to catch bugs cheaply.
• Treating pipeline config as someone else's responsibility. If your test suite runs in CI but you've never read the workflow file, you're missing the context to debug failures, tune performance, or add new test jobs. Own the pipeline.
• Abandoning exploratory testing because "we have automation." Automation verifies what you thought to test. Exploratory testing finds what you didn't think to test. Both are essential — they're not substitutes.

🎯 Practice task

Do a role audit — 20 minutes.

1. List the last five bugs your team shipped to production that your automated tests missed. For each one: should a unit test have caught it? An integration test? An E2E test? Or was it something only exploratory testing would find?
2. If your team has a CI pipeline, open the workflow file. Find the test step. Do you know what command it's running? Do you know how to add a new test job?
3. If your team doesn't have a CI pipeline, identify one: the single most-run manual test your team does. That test is your first CI automation candidate.
4. Stretch: find a QA engineer who works on a team doing Continuous Delivery or Continuous Deployment (a conference talk, a blog post, a colleague). What does their day look like compared to a traditional QA role? What surprises you?

In the next chapter, you'll stop reading about CI and start writing it. Chapter 2 is entirely hands-on: GitHub Actions workflows, PR status checks, matrix builds, secrets, and artifact uploads. The command from your lesson 1 practice task goes into a YAML file in lesson 2.