CI/CD Concepts
What is CI/CD and Why it Matters for QA
What is CI/CD and Why It Matters for QA
Continuous Integration and Continuous Delivery (CI/CD) has transformed how software teams ship software. For QA engineers, understanding CI/CD is no longer optional — it is the environment in which your tests live and where their value is realised.
Continuous Integration (CI)
CI is the practice of frequently merging code into a shared repository, with automated builds and tests running on every merge.
Before CI: Developers worked in isolation for days or weeks. When they merged, they discovered integration conflicts and test failures that were expensive to diagnose — whose change broke what?
With CI: Every push triggers:
- Code is checked out
- Dependencies are installed
- Code is compiled/built
- Unit tests run
- Integration tests run
- Results are reported to the team
If any step fails, the merge is blocked. Problems are caught within minutes of introduction.
Continuous Delivery (CD)
CD extends CI — once tests pass, the build is automatically deployed to a staging or pre-production environment. It may require a manual approval step before production.
Continuous Deployment (a stronger form): every passing build deploys to production automatically. This requires high test confidence and feature flags for risk management.
Why CI/CD Matters for QA
-
Your tests run on every change — not just before a release. You get fast feedback instead of discovering failures after weeks of development.
-
You own the pipeline gates — a failing test blocks deployment. This is how QA has real power in a modern team.
-
Flaky tests are immediately visible — a test that fails intermittently in CI stands out. CI makes test reliability a first-class concern.
-
Environment parity — CI runs in a clean, reproducible environment. Tests that pass locally but fail in CI reveal environment-specific assumptions.
The QA engineer who understands CI/CD is not just writing tests — they are designing the safety net that the whole team relies on.
💬 Discussion
Does your team use CI? If yes, what proportion of test failures caught in CI would have reached production without it?
In a CI pipeline, what typically happens when a test suite fails on a pull request?
Next Lesson
Where Tests Fit in a Pipeline