How do you run automated tests in a CI pipeline?

What the interviewer wants to hear

• Trigger on pull requests and merges
• Install dependencies and browsers, often in Docker
• Start or target a test environment
• Run tests in parallel and publish reports and artifacts
• Fail the build on test failures and notify the team

Model answer

I set up a pipeline in GitHub Actions, GitLab CI or Jenkins that triggers on every pull request and on merges to main. The job checks out the code, installs dependencies, and installs browsers, often using the official Playwright or Selenium Docker image so the environment is the same everywhere. The app is either started inside the job, for example with docker compose, or the tests point to a preview environment using a base URL from environment variables, with secrets stored in the CI secret store. Tests run headless and in parallel across workers or shards. The job publishes an HTML or Allure report and uploads screenshots, videos and traces on failure. If a test fails, the build fails, so the pull request cannot be merged, and the team gets a notification. A smaller smoke suite runs on every commit, and the full suite runs nightly or before release.

More easy Automation Test Engineer questions

• Why do teams automate tests, and what should not be automated?
• Explain the Page Object Model and its benefits. Are there any downsides?
• What is the difference between implicit waits, explicit waits and auto-waiting?
• When would you write an API test instead of a UI test?
• How do you choose locators for UI tests, and what makes a locator fragile?
• Explain the test pyramid. How does it guide what you automate?
• When you automate tests for a REST API endpoint, what do you check?
• What makes an automated test good?
• Compare Selenium and Playwright. When would you choose each?