What Is CI/CD and Why It Matters for QA

You write a test. It passes locally. You commit it, and two weeks later you discover the feature it covers shipped with a regression that nobody caught — because the test only ran on your laptop. This is the problem CI/CD exists to solve, and it's why understanding pipelines has become a core QA skill, not a DevOps speciality.

What CI/CD actually is

CI/CD stands for Continuous Integration and Continuous Delivery (or Deployment). Strip away the acronyms and you get one idea: automate the path from code commit to working software.

Without a pipeline, a typical release looks like this: a developer finishes a feature, manually builds the project, hands it to QA, QA tests for a week, bugs are fixed, QA retests, and — three weeks after the code was written — the feature ships. Bugs caught in this final stage are the most expensive ones: they have design, code, and integration layered on top of them.

With CI/CD, that same path looks like: developer commits → pipeline triggers automatically → code is built → every automated test in the suite runs → results are available in minutes → if everything passes, the code is deployable. Bugs caught in the pipeline cost a fraction of bugs caught in production.

Why QA engineers specifically care

Tests run on every commit, not on request. Without CI, tests run when someone remembers to run them. With CI, they run every single time code changes. A failing test surfaces within minutes of the commit that broke it, while the developer still remembers what they changed.

Quality gates block bad code from merging. A pull request with failing tests can be configured so it literally cannot be merged into the main branch. QA's standards become automated policy — no manual sign-off needed for each PR, no social negotiation about whether "it's good enough."

Feedback arrives in hours, not days. On a team without CI, a developer might not know their change broke the checkout flow until QA gets to it five days later. On a team with CI, they know within 10 minutes. The fix is trivial because the context is fresh.

Repetitive regression checking moves to automation. Running 300 regression tests manually before every release is the kind of work that burns out testers and gets skipped when timelines tighten. CI runs those 300 tests on every commit, every day, without fatigue.

The pipeline in QA terms

A CI/CD pipeline is a sequence of automated steps. For a QA engineer, the important stages are:

1. Trigger — something fires the pipeline: a code push, a new pull request, a scheduled time (nightly), or a manual button click.
2. Build — the application is compiled and dependencies are installed. If the build fails, nothing else runs.
3. Test — this is where QA owns the outcome. Unit tests run first (fast, cheap). Then integration tests. Then API tests. Then UI/E2E tests (slow, expensive). Faster tests fail fast; expensive tests run after the cheaper gates are green.
4. Quality checks — code coverage thresholds, static analysis, security scans. These run alongside tests and can also block merging.
5. Deploy — the artifact is deployed to a staging environment automatically. Production deploy may be automatic (Continuous Deployment) or triggered manually after review (Continuous Delivery).
6. Monitor — in production, metrics and error rates confirm the release is healthy. This closes the feedback loop.

Real numbers

A team without CI/CD might ship once a month, with a two-week QA cycle baked in. A team with a mature CI/CD pipeline ships multiple times per day. The QA team doesn't shrink — the work shifts from manual regression to owning and improving the pipeline.

QA owns the test stage

This is the most important mindset shift this course will push: the pipeline's test stage belongs to QA. Configuration of which tests run, in what order, on which triggers, with what retry and parallelisation settings — that's a QA engineering decision, not a developer or DevOps decision. You will write pipeline YAML in this course. By the end of Chapter 2 you'll have a working GitHub Actions workflow running a real test suite on every PR.

⚠️ Common mistakes

• Treating CI as "someone else's job." On most modern teams, QA engineers are expected to read, write, and debug pipeline configuration. If you've never opened a .github/workflows/ file, you're missing a core deliverable.
• Running all tests on every trigger. Running your full 300-test E2E suite on every commit creates a 45-minute pipeline that nobody waits for. Match test depth to trigger: fast smoke on every commit, full regression on PRs, complete suite nightly.
• Ignoring flaky tests in CI. A flaky test that fails 20% of the time doesn't just cause noise — it trains the team to ignore red pipelines. Fix or quarantine flaky tests before they destroy trust in the pipeline.

🎯 Practice task

15 minutes. No coding yet — build the mental model.

1. Pick any open-source project on GitHub — for example microsoft/playwright or cypress-io/cypress. Click the Actions tab. You'll see every workflow run: which triggers fired it, how long each step took, which steps failed.
2. Click into one of the recent workflow runs. Find the test step. Note how long it ran and what it reported.
3. Open the .github/workflows/ folder in the repository. Read one of the YAML files. You don't need to understand every line — just identify: the on: trigger block, the jobs: block, and where the test command is.
4. In your own test project (Selenium, Playwright, Cypress — whichever you use), answer: if someone ran your tests right now without looking at your laptop, how would they do it? Write the exact shell command. That command is what you'll put into a CI pipeline in the next chapter.

The next lesson maps your existing test suite onto the test pyramid and decides which tests belong on which pipeline trigger.