CI/CD interview questions for testers

Testers are asked about CI/CD because tests that do not run automatically are tests nobody trusts. You do not need to be a DevOps engineer. You need to explain what the pipeline does with your tests, why a build fails, and how you would make it faster and more reliable. Examples use the free ShopLite practice app.

The basics

1. What is CI/CD?

CI (continuous integration) means developers merge their changes into the shared code often, and every merge is automatically built and tested, so a break is found in minutes. CD stands for continuous delivery (every change that passes is ready to release, with a person pressing the button) or continuous deployment (every change that passes goes to production automatically). The three are compared in CI vs delivery vs deployment.

2. What is a pipeline, and what are its usual stages?

A pipeline is the automated sequence that takes a code change to a result. Typical stages: get the code, install dependencies, build, run fast tests (unit, static checks), run slower tests (API, then a few UI journeys) against a deployed copy, publish reports, and deploy. Each stage can stop the pipeline if it fails.

3. Why does a tester care about CI/CD?

It decides when and how often your tests run, how fast failures are seen, who sees them, and whether a failing test blocks a release. A test suite that runs only on a tester's laptop finds problems late and is easy to forget. In CI it protects every change.

4. What is the difference between a build, a job and a stage?

A build is one run of the pipeline for a particular change. A stage is a named phase inside it (build, test, deploy). A job (in GitHub Actions, GitLab and others) is a unit of work that runs on one machine and can run in parallel with other jobs. Terminology differs by tool; check which words yours uses.

5. What is shift-left testing?

Moving testing earlier in the process: reviewing requirements, writing tests while the code is written, and running them on every change instead of at the end. The earlier a defect is found the cheaper it is to fix. CI is how shift-left is made real.

Tests in the pipeline

6. Which tests would you run on every pull request, and which nightly?

On every pull request: fast checks that give feedback in minutes, such as linting, unit tests, API tests and a small smoke set of UI tests. Nightly or before a release: the full regression, cross-browser runs, performance and longer end-to-end suites. Say the rule: the slower a test is, the less often it runs, and the more it must be worth running.

7. What is a quality gate?

A rule that must be true for the pipeline to continue: all tests pass, no critical static-analysis issues, code coverage not falling below an agreed level, no known vulnerable dependencies. A gate turns "we should" into "the build will not pass otherwise". Gates need to be few, clear and fair, or people learn to work around them.

8. A test passes on your machine and fails in CI. Where do you look?

Compare the environments. Typical causes: a different browser or window size, a different operating system or time zone, missing environment variables or secrets, a slower machine exposing a missing wait, test data that exists locally but not in CI, tests that depend on running order, and the app not being ready when the tests start. Read the log, look at the screenshot or trace the pipeline saved, and reproduce with the same container or settings locally.

9. How do you handle flaky tests in a pipeline?

Measure them (a test that fails then passes on retry is flaky), quarantine the worst so they stop blocking everyone while still running, give each an owner and a deadline, and fix the cause rather than raising timeouts. Do not hide them behind automatic retries. There is a full walk-through in finding and fixing flaky tests.

10. Should a pipeline retry failed tests automatically?

A limited retry in CI (once or twice) is reasonable to absorb real infrastructure hiccups, as long as retried passes are reported as flaky and tracked. Blind retries of everything hide real intermittent bugs in the product as well as in the tests, and slow every build.

11. How do you run tests in parallel in a pipeline?

Two levels. Inside one machine, the test runner uses several workers (for example Playwright workers or TestNG parallel). Across machines, the pipeline splits the suite into shards and runs them as parallel jobs, then collects the results. Both need independent tests: no shared accounts, data or order dependence.

12. How do you publish and read test results?

Have the runner write a standard report (JUnit XML is understood by nearly every CI tool, plus an HTML report for people). The CI tool shows pass and fail counts and trends, and the full HTML report, screenshots and traces are saved as artifacts attached to the build. A failure with no evidence attached costs hours.

13. What is an artifact?

A file produced by a build that you want to keep: a test report, screenshots, a trace, logs, a built package. CI tools store artifacts with the build so you can download them after the machine that created them is gone.

Jenkins

14. What is Jenkins, and how is it different from the tools built into GitHub or GitLab?

Jenkins is an open-source automation server you install and run yourself. It is very flexible, with a huge plugin ecosystem, and works with any source control. The price is that you maintain it: updates, plugins, agents, security. GitHub Actions and GitLab CI are built into the platforms that host your code and run workflows from files in the repository. The two are compared in Jenkins vs GitHub Actions.

15. What is a Jenkinsfile, and what are declarative and scripted pipelines?

A Jenkinsfile is the pipeline definition stored in the repository, so it is versioned and reviewed like code. A declarative pipeline has a fixed, readable structure (pipeline, agent, stages, post) and is the usual choice. A scripted pipeline is plain Groovy with more freedom and more ways to make a mess. Example of declarative:

pipeline {
  agent any
  stages {
    stage('Test') { steps { sh 'npm ci && npm test' } }
  }
  post { always { junit 'results/*.xml' } }
}

There is a complete one in the Jenkins tutorial.

16. What are the controller and agents in Jenkins?

The controller (older name: master) schedules builds and serves the web interface. Agents (older name: slaves, now also called nodes) are the machines or containers that actually run the work. Keep builds off the controller: more agents let more tests run in parallel, and a build that goes wrong cannot take down the controller.

17. How do you trigger a Jenkins build?

By a webhook from the code host on every push (best: immediate), by polling source control on a schedule (works behind firewalls, slower and wasteful), by a cron schedule (cron('H 2 * * *') for nightly runs), by another job finishing, or by hand. The H in a cron expression spreads load by choosing a hashed minute.

18. How do you keep passwords and tokens safe in a pipeline?

Never in the repository or the log. Store them in the CI tool's credential store and inject them only into the step that needs them; the tool masks them in the output. In Jenkins use withCredentials; in GitHub Actions use encrypted secrets.

withCredentials([string(credentialsId: 'api-token', variable: 'API_TOKEN')]) {
  sh 'npm run test:api'
}

Also give test accounts only the access tests need, and rotate secrets that leaked.

19. What are Jenkins parameters, and when would a tester use them?

Inputs a person (or another job) supplies when starting a build, declared in the Jenkinsfile. A tester uses them to choose an environment, a browser, a tag or a single suite without editing code.

parameters {
  choice(name: 'ENV', choices: ['staging', 'qa'], description: 'Where to run')
  string(name: 'GREP', defaultValue: '@smoke', description: 'Test tag')
}

GitHub Actions

20. What are a workflow, a job, a step, an event and a runner in GitHub Actions?

A workflow is a YAML file in .github/workflows/. An event (a push, a pull request, a schedule, a manual run) starts it. A workflow has jobs; jobs run in parallel unless you order them with needs. A job runs on a runner (a machine, such as ubuntu-latest) and is made of steps, each either a shell command (run) or a reusable action (uses). The GitHub Actions tutorial walks through a real file.

21. How do you run tests on several browsers or versions in GitHub Actions?

With a matrix: the job runs once for each combination.

strategy:
  fail-fast: false
  matrix:
    browser: [chromium, firefox, webkit]
steps:
  - run: npx playwright test --project=${{ matrix.browser }}

fail-fast: false lets the other combinations finish so you see all the failures at once.

22. How do you save a test report when the run fails?

Upload it as an artifact in a step that runs even after a failure.

- name: Keep the report
  if: always()
  uses: actions/upload-artifact@v4
  with:
    name: playwright-report
    path: playwright-report/

if: always() runs the step whatever happened before; if: failure() only on failure.

23. How do you speed up a workflow?

Cache dependencies (actions/setup-node can cache npm with cache: npm), run independent jobs in parallel, cancel superseded runs with concurrency, run a small set on pull requests and the rest on a schedule, shard long test suites across a matrix, and avoid installing things you do not use (install one browser instead of three).

24. How do you run a workflow on a schedule, or by hand?

on:
  schedule:
    - cron: '30 20 * * *'      # 20:30 UTC, which is 02:00 in India
  workflow_dispatch:

Cron in GitHub Actions is in UTC. workflow_dispatch adds a "Run workflow" button.

25. How do you stop a broken change from reaching the main branch?

Require the pipeline to pass before merging: branch protection (or a ruleset) with "require status checks to pass" and a required review. Then a red build cannot be merged by accident.

Docker, environments and deployment

26. Why do testers use Docker in CI?

A container gives every run the same, clean environment: the same browser, the same dependencies, a database that starts empty. It removes "works on my machine" and makes it easy to start the app and its database for a test run. Playwright, for example, publishes images with the browsers pre-installed.

27. How do you test an application in a pipeline when it needs a database?

Start the dependencies as containers for the run (services in GitHub Actions, a Docker compose file in Jenkins), seed known data, wait for health checks before the tests start, and throw everything away afterwards. Never point a pipeline at a shared database that other people use.

28. What are blue-green, canary and rolling deployments?

Blue-green keeps two identical environments and switches traffic from the old one to the new, so rollback is switching back. Canary sends a small share of users to the new version first and watches for problems before widening. Rolling replaces instances a few at a time. Testers contribute smoke tests after each step and the checks that decide whether to go on.

29. What are feature flags, and how do they affect testing?

A switch that turns a feature on or off without a deployment. They let code reach production unfinished and be released gradually. Testers must test both states and the switch itself, and remove tests with the flag when it is retired.

30. How would you measure how well a team does CI/CD?

The four DORA metrics: deployment frequency, lead time for changes (commit to production), change failure rate (how often a release causes a problem), and time to restore service. For tests add pipeline time, flaky-test rate and how often a failing build is fixed within the hour. Use them to find bottlenecks, not to compare people.

Practise it

Take the free ShopLite app and its starter tests, put them in a new GitHub repository and follow the GitHub Actions tutorial. Then break a test on purpose and read the failure the way a teammate would.