Automatizar testes é metade do caminho. A outra metade é fazer com que eles rodem no momento certo, automaticamente, para todo mundo. É aí que entra o CI/CD — e onde o QA deixa de ser um gargalo no fim do processo para virar parte do fluxo.

CI e CD, sem confusão

• CI (Integração Contínua): cada push dispara build + testes, integrando o código frequentemente e detectando problemas cedo.
• CD (Entrega/Implantação Contínua): o que passou nos testes segue automaticamente para staging ou produção.

Onde cada teste entra no pipeline

A regra é simples: quanto mais rápido o teste, mais cedo ele roda. Feedback rápido é o que mantém o time produtivo.

1. Lint + testes unitários — segundos, rodam em todo commit.
2. Testes de integração e de API — minutos, após o build.
3. Testes E2E — os mais lentos, em paralelo e nos fluxos críticos.
4. Quality gates — cobertura mínima, zero vulnerabilidades críticas, etc.

Exemplo com 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

O papel do QA no pipeline

Não basta escrever os testes; é preciso garantir que eles sejam confiáveis. Um teste flaky que falha aleatoriamente faz o time perder a confiança no pipeline e começar a ignorar builds vermelhos — o pior dos mundos.

Um pipeline verde precisa significar "está seguro entregar". Se o time não confia no verde, o CI virou teatro.

Conclusão

CI/CD bem feito transforma qualidade em algo contínuo e visível. O QA moderno desenha quality gates, cuida da saúde da suíte e usa o pipeline como sua principal ferramenta de prevenção.

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.