CI/CD
CI/CD Testing Explained: Automatic Checks on Every Change
Learn what CI/CD means in plain words, how automated tests run in a pipeline, which checks belong at which stage, and how to keep the pipeline fast and trusted.
- Published
- Reading time
- 6 min read
- Difficulty
- Beginner
- Audience
- For Student, Manual tester, QA engineer, Developer, QA lead
Article overview
What you will learn
- What CI, CD, and a pipeline actually are
- Why running tests automatically changes how a team works
- Which tests belong at which stage
- How to keep pipeline feedback fast and trustworthy
- What to do when the pipeline goes red
Before you begin
Prerequisites
- A rough idea of how code changes get released
CI/CD in plain words
Picture a bakery. Every batch of dough goes past the same station on its way to the oven: someone weighs it, checks the temperature, and rejects anything wrong before it gets baked into a thousand loaves. Nobody has to remember to do it — the station is simply on the path, and nothing gets past it.
A CI/CD pipeline is that station for software. Every code change, from every person, automatically goes through the same set of checks before it can reach users. The alternative — hoping each developer remembers to run the tests — fails for exactly the reason you would expect.
Why it matters
The cost of a bug rises with the distance between causing it and finding it. Caught in the pipeline nine minutes after a change, the developer still remembers exactly what they did and fixes it in ten minutes. Caught three weeks later by a customer, it costs a support ticket, an investigation, a hotfix, a release, and someone's trust.
| Who | What the pipeline gives them | Plain version |
|---|---|---|
| A developer | Fast confirmation the change is safe | You find out in minutes, not next month |
| A tester | A stable, already-checked build to test on | You stop wasting days on broken builds |
| A manager | A repeatable, recorded release process | Releases stop depending on one person's laptop |
| A customer | Fewer regressions in production | The thing that worked last week still works |
Key terms, made simple
| Term | What it means | Everyday comparison |
|---|---|---|
| Build | Turning source code into something runnable | Baking the raw ingredients |
| Job / stage | One step of the pipeline | One station on the production line |
| Runner / agent | The machine that executes the steps | The worker at that station |
| Artifact | A file the pipeline produces and keeps — a report, a screenshot, an app package | The receipt and the finished product |
| Green / red build | All checks passed / something failed | Traffic light for the change |
| Gate | A check that can block a release | The bouncer at the door |
Which tests belong at which stage
Not every test should run on every change. The rule of thumb: the faster and cheaper a check, the earlier and more often it runs. The slower and more realistic it is, the later and less often.
| Stage | Typical checks | Target time | Runs on |
|---|---|---|---|
| On every change | Linting, unit tests, component tests | Under 5 minutes | Every push and pull request |
| After merge | API tests, integration tests, a small browser smoke suite | Under 15 minutes | Every merge to the main branch |
| Before release | Full browser suite, accessibility, visual comparisons | Under an hour | Release candidates |
| Scheduled | Performance, long endurance runs, full cross-browser matrix | Any | Nightly or weekly |
Example: a pipeline that runs on every change
name: Tests on: push: branches: [main] pull_request: jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 20 cache: npm - run: npm ci - run: npm run lint - run: npm test - name: Upload test report if: always() uses: actions/upload-artifact@v4 with: name: test-report path: test-results/In English: whenever someone pushes to the main branch or opens a pull request, start a fresh Linux machine, fetch the code, install Node and the project's dependencies, check the code style, run the tests — and keep the report afterwards even if the tests failed. That last part matters most: if: always() is what gives you evidence to investigate a red build instead of guesswork.
Your first week
- Get *one* thing running automatically on every change — even just the unit tests. Something beats nothing.
- Make the result visible where people already look: on the pull request itself.
- Save reports, screenshots, and logs as artifacts from the first day.
- Measure how long the pipeline takes. Write the number down.
- Add your one most important browser journey as a smoke test after merge.
- Agree a team rule for red builds: who fixes, and how quickly.
- Review the slowest step and the flakiest test before adding anything new.
Trust is the whole point
A pipeline is only useful if a red result means something. The moment a suite fails randomly, people start re-running it until it passes — and at that point a real defect will be re-run away just as easily. Flakiness is not a minor annoyance; it is the thing that quietly turns a safety net into decoration.
Common mistakes
- Running the entire test suite on every keystroke-sized change until the pipeline takes an hour
- Letting the main branch stay red for days
- Tests that depend on a shared environment other tests are also changing
- Hard-coded credentials or real customer data in pipeline configuration
- No artifacts, so every failure investigation starts from zero
- Treating deployment automation as done while testing stays manual
Key takeaways
- CI/CD puts your checks on the path every change must take, so nobody has to remember them.
- Fast, cheap checks run early and often; slow, realistic ones run later.
- Feedback under about ten minutes is what keeps developers in the loop.
- Artifacts turn a red build into a diagnosis instead of a mystery.
- A pipeline nobody trusts is worse than none, because it creates false confidence.
Frequently asked questions
What is the difference between continuous delivery and continuous deployment?
Continuous delivery means every change is *ready* to release, with a human choosing when. Continuous deployment goes one step further and releases automatically once the checks pass. Delivery is the common choice; deployment demands much stronger automated testing.
Do we need CI/CD if we are a small team?
Small teams often benefit most, because there is nobody spare to catch mistakes manually. Start with one automated check on every change; you do not need a sophisticated pipeline to get most of the value.
Should all tests run before every merge?
No. Run the fast, reliable ones on every change and push the slow ones later in the pipeline or onto a schedule. A pipeline people wait an hour for is a pipeline people work around.
Who is responsible when the pipeline is red?
By convention, whoever made the change that broke it, and immediately — before starting anything else. A shared branch that is red blocks everyone, so treat it as the highest-priority interruption.
References and further reading
- Understanding GitHub ActionsGitHub Docs · Verified 2026-07-19
- Continuous integration in the CI/CD pipelineGitLab Docs · Verified 2026-07-19
- Continuous integrationPlaywright documentation · Verified 2026-07-19
