CI/CD & DevOps for QA Interview Questions for 5 Years Exp (2026)

Short answer: fastest and most reliable checks first, slow ones later, and each stage blocks the next.

pull request : lint -> unit -> API/contract -> UI smoke   (minutes, blocks merge)
main branch  : full API + UI regression in parallel       (blocks deploy to staging)
after deploy : smoke against the deployed environment      (blocks promotion)
nightly      : long suites, cross-browser, performance baseline

The goal is fast feedback on the change a developer just made, not running everything everywhere.

name: e2e
on: [pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        shard: [1, 2, 3, 4]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: npm }
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test --shard=${{ matrix.shard }}/4
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: report-${{ matrix.shard }}
          path: playwright-report/

Key points: fail-fast: false lets every shard finish so you see all failures; if: always() uploads the report even when tests fail; cache: npm speeds up installs.

Short answer: shard it. Playwright has --shard=x/y built in; for other runners, split by file and balance using previous run times. Merge the results afterwards (Playwright supports a blob reporter plus merge-reports).

Sharding only helps if tests are independent - shared accounts or order-dependent tests start failing as soon as you split.

Short answer: start dependencies inside the job (service containers or Docker Compose) or create a short-lived preview environment per pull request. Seed known data, run, then throw it away.

services:
  postgres:
    image: postgres:16
    env: { POSTGRES_PASSWORD: test }
    ports: ["5432:5432"]
    options: >-
      --health-cmd pg_isready --health-interval 5s --health-retries 10

The health check stops tests starting before the database is ready - a frequent cause of "first test always fails".

Short answer: allow at most one automatic retry, and report tests that passed on retry as flaky rather than hiding them. Confirmed flaky tests move to a non-blocking quarantine job with an owner and a ticket. A test that stays quarantined for weeks is either fixed or deleted.

Retries without tracking turn a failing signal into noise, and real intermittent bugs (race conditions) get missed.

Short answer: store them in the CI system's secret store, pass them as environment variables, give test accounts the minimum rights, and never print them. GitHub Actions masks registered secrets in logs, but transformed values (for example base64) are not masked automatically.

- run: npx playwright test
  env:
    TEST_USER_PASSWORD: ${{ secrets.TEST_USER_PASSWORD }}

Secrets are not passed to workflows triggered from forks by default - plan for that in open-source projects.

• Publish JUnit XML so the CI shows failed tests by name.
• Attach evidence per failure: screenshot, trace or video, request/response logs.
• Include the environment, build number and commit in the report.
• Write assertion messages that say what was expected and what happened.
• Track failure history per test, so "new failure" and "known flaky" are easy to tell apart.

Short answer: measure first, then cut the biggest costs.

1. Get per-stage and per-test timings from the existing reports.
2. Cache dependencies and browser downloads.
3. Shard the slowest stage.
4. Replace UI setup (login, data creation) with API calls.
5. Move checks that a unit or API test can do out of the UI suite.
6. Run only affected suites on pull requests where the tooling supports it, and the full set on main.

Report the before and after times you actually measured.