Automating tests is half the journey. The other half is making them run at the right time, automatically, for everyone. That's where CI/CD comes in, and where QA stops being a bottleneck at the end of the process and becomes part of the flow.

CI and CD, without the confusion

• CI (Continuous Integration): every push triggers a build plus tests, integrating code frequently and catching problems early.
• CD (Continuous Delivery/Deployment): whatever passes the tests moves on automatically to staging or production.

Where each test fits in the pipeline

The rule is simple: the faster the test, the earlier it runs. Fast feedback is what keeps the team productive.

1. Lint + unit tests — seconds, run on every commit.
2. Integration and API tests — minutes, after the build.
3. E2E tests — the slowest, run in parallel and on critical flows.
4. Quality gates — minimum coverage, zero critical vulnerabilities, and so on.

Example with GitHub Actions

name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm ci
      - run: npm run lint
      - run: npm test -- --coverage
      - run: npx playwright test

QA's role in the pipeline

It's not enough to write the tests; you have to make sure they're reliable. A flaky test that fails at random makes the team lose trust in the pipeline and start ignoring red builds, which is the worst of all worlds.

A green pipeline has to mean "it's safe to ship". If the team doesn't trust the green, CI has become theater.

Conclusion

Well-done CI/CD turns quality into something continuous and visible. The modern QA designs quality gates, looks after the health of the suite, and uses the pipeline as their main prevention tool.