Lesson 1 of 86 min read
What CI/CD really means for testers
Almost every QA job description now mentions CI/CD, Jenkins or GitHub Actions. CI/CD is simply the automated path from a developer's commit to a running release — and testing is the part that decides whether that path is safe. This lesson explains CI, Continuous Delivery and Continuous Deployment in plain words and shows exactly where a tester fits.
Key takeaways
- 1Continuous Integration (CI): every push or pull request automatically builds the code and runs tests, so problems are found within minutes, not at the end of the sprint.
- 2Continuous Delivery: every change that passes the pipeline is ready to release, but a human clicks 'deploy to production'. Continuous Deployment: it goes to production automatically with no manual step.
- 3A pipeline is an ordered list of automated steps: checkout → install → build → unit tests → deploy to test env → API/UI tests → deploy to production.
- 4Testers own the quality gates: which tests run at which stage, what blocks a merge, how failures are reported, and how flaky tests are handled.
- 5Shift-left: fast checks (lint, unit, API smoke) run on every commit; slower full regression runs nightly or before release.
A typical web app pipeline, step by step
Developer pushes branch feature/coupon |
[1] Checkout code
[2] Install dependencies (npm ci / mvn install)
[3] Lint + unit tests ~2 min -> fail = PR blocked
[4] Build app / Docker image
[5] Deploy to QA environment
[6] API smoke tests ~3 min -> fail = stop
[7] UI smoke tests (Playwright) ~6 min -> fail = stop
[8] Publish HTML report + screenshots
|
PR approved + merged to main
|
[9] Deploy to staging -> full regression (nightly)
[10] Manual approval -> deploy to production
[11] Production smoke test + monitoring
Tester decides: what runs in 6 and 7, what counts as 'fail', who gets notified, and what the report shows.
Go deeper
Expert notes beyond the basics
- 01
Why CI exists: the 'integration hell' problem
Before CI, developers worked on separate branches for weeks and merged at the end. Merges broke the build, features conflicted, and testers received a big unstable build days before release. CI flips this: small changes merged often, each one built and tested automatically. A bug found ten minutes after a commit is cheap — the developer still remembers the change. The same bug found three weeks later in system testing is expensive and slows the whole release.
- 02
What changes in a tester's daily work
With CI/CD, you're no longer waiting for a weekly build. New builds reach the QA environment many times a day. That means: automated smoke tests decide whether a build is even worth testing manually; you test smaller changes more often; you review pipeline failures as part of daily work; and you collaborate with developers on PRs. Manual exploratory testing still matters — CI frees your time from repeating the same regression checks so you can explore risky new areas.
- 03
CI/CD vocabulary you'll hear in stand-ups
Build: compiled/packaged version of the app. Green/red build: pipeline passed/failed. Broken build: main branch failing — top priority to fix. Artifact: output files (app package, Docker image, test report). Environment: a running copy of the app (dev, QA, staging, prod). Deployment: putting a build onto an environment. Rollback: going back to the previous version. Feature flag: switch that hides unfinished features in production. Blue-green / canary: release strategies that limit risk by switching or gradually shifting traffic.
- 04
Popular CI/CD tools and how they compare
GitHub Actions: built into GitHub, YAML, huge marketplace of actions — common in startups and open source. Jenkins: open-source, self-hosted, Groovy Jenkinsfile, very common in enterprises and service companies. GitLab CI: built into GitLab, .gitlab-ci.yml. Azure DevOps Pipelines: common in Microsoft-stack companies. CircleCI, Bitbucket Pipelines and TeamCity also appear. The concepts transfer completely: learn one well and you can read the others within a day — say exactly that in interviews.
Common mistakes to avoid
- - Thinking CI/CD is only a DevOps topic — testers design and own the quality checks inside it.
- - Mixing up Continuous Delivery (manual production approval) and Continuous Deployment (fully automatic).
- - Running every slow test on every commit, so developers stop waiting for results.
- - Ignoring a red main branch because 'it's probably flaky'.
- - Believing automation in CI replaces exploratory testing.
Try it yourself
Your team releases once a month after a two-week manual regression. The manager asks you to propose a CI/CD testing plan. Write 5 concrete steps you'd recommend, in order.
Write your answer on paper or in a sheet first, then compare.
Interview questions
How to answer like a confident QA engineer
- Q1
What is the difference between Continuous Integration, Continuous Delivery and Continuous Deployment?
Model answer
Continuous Integration means developers merge small changes often and every change automatically builds and runs tests, so integration problems are found early. Continuous Delivery extends that: every change that passes the pipeline is deployable, and release to production is a one-click manual decision. Continuous Deployment removes that manual step, so every passing change goes to production automatically. As a tester, my role is to make the automated checks trustworthy enough that the team can rely on them — fast smoke tests on every PR, broader regression before release, and clear reports when something fails.
- Q2
What is the role of QA in a CI/CD pipeline?
Model answer
QA decides what quality checks run at each stage and makes them reliable: smoke tests on every PR, API and UI regression after deployment to QA or staging, and production smoke tests after release. We define pass/fail criteria, maintain the automated suites, investigate failures, manage flaky tests, make reports readable, and still do exploratory testing on new features. Essentially we turn 'is this build good?' into fast, trustworthy, automated answers.
- Q3
What does 'shift-left testing' mean?
Model answer
Moving testing earlier in the development cycle: reviewing requirements and acceptance criteria before coding, unit and API tests running on every commit, testers involved in PR reviews, and static analysis catching issues before a build is deployed. The earlier a defect is found, the cheaper it is to fix. CI is the main tool that makes shift-left practical.
- Q4
What happens when the main branch build is broken?
Model answer
Fixing it becomes the team's top priority, because every new change is built on a broken base and nobody can trust the results. The person whose change broke it usually fixes it or reverts the commit quickly. As a tester I check whether it's a real product bug, a test problem or an environment issue, and communicate that clearly so the right person acts.
Knowledge check
+5 points
In Continuous Delivery, how does a change reach production?