CI/CD questions come up in every automation interview. They want to know that you do not just write tests — you can run them in a pipeline, generate reports, and keep the team informed. Here are the top questions with strong answers.
Q: How do you run Selenium tests in CI/CD?
A: We use Jenkins with a declarative Jenkinsfile stored in our Git repository. The pipeline has four stages: Checkout pulls code from Git, Build compiles with "mvn clean compile -DskipTests", Run Tests executes the TestNG suite in headless Chrome with "mvn test -DsuiteXmlFile=testng.xml -Dheadless=true", and Publish Reports generates Allure and TestNG reports. Tests run in headless mode because CI servers have no display. On failure, the pipeline sends an email with a link to the Allure report. We trigger smoke tests on every push via webhook and run full regression nightly at 2 AM using cron.
Q: What is a Jenkins Pipeline and how is it different from a Freestyle job?
A: A Freestyle job is configured through the Jenkins GUI — you click buttons and fill forms. Simple but not version-controlled. If Jenkins crashes, the config is lost. A Pipeline job is defined in a Jenkinsfile stored in the Git repository. It uses a Groovy-based DSL with stages like Checkout, Build, Test, and Report. The Jenkinsfile is version-controlled, code-reviewed, and reproducible. If Jenkins dies tomorrow, I create a new Pipeline job pointing to the same repo and everything works. I always use Pipeline for real projects — Freestyle is only for quick experiments.
Q: How do you schedule nightly regression tests?
A: I use Jenkins cron trigger with the expression "H 2 * * 1-5" — this runs the full regression suite around 2 AM on weekdays. The "H" hash ensures that if multiple jobs are scheduled at 2 AM, Jenkins spreads them across the hour so they do not all start at the same minute and overload the server. For on-demand runs, we have parameterized builds where anyone can select the browser, environment, and test suite from a dropdown. For fast feedback on every commit, we use GitHub webhooks to trigger smoke tests immediately.
Q: What happens when tests fail in your CI pipeline?
A: Three things happen automatically. First, the Allure report is generated with screenshots of failed tests, error messages, and step-by-step details. Second, an email is sent to the QA team and the developer who made the last commit, containing links to the report and console log. Third, a Slack message is posted to our #qa-alerts channel. I check the Allure report to determine if it is a real bug or a flaky test — Allure shows test history so I can see if a test has been intermittently failing. Real bugs are logged in Jira. Flaky tests are investigated and stabilized.
Q: What is headless mode and why is it needed in CI?
A: Headless mode means the browser runs in memory without rendering a visible window. CI servers typically run on Linux machines with no desktop environment — there is no monitor attached. If you try to open regular Chrome, it crashes because there is no display. Headless Chrome renders pages internally and executes all interactions normally. I configure it with ChromeOptions: --headless=new, --no-sandbox (required in Docker/CI), --disable-dev-shm-usage (prevents shared memory issues), and --window-size=1920,1080 (consistent viewport). My BaseTest reads a "headless" system property so the same tests work in both modes.
Q: Have you used GitHub Actions? How does it compare to Jenkins?
A: Yes. GitHub Actions is YAML-based and built directly into GitHub — no server to manage. I have created workflows that run on push and PR, with schedule for nightly regression. The concepts are identical to Jenkins: triggers, stages, reports, notifications. The main difference is infrastructure — Jenkins is self-hosted with maximum control, GitHub Actions is cloud-hosted with zero maintenance. Jenkins has a richer plugin ecosystem. GitHub Actions is simpler to set up. I use Jenkins for enterprise projects and GitHub Actions for smaller projects or open-source. Both are valuable on a resume.
Q: Explain the flow of your CI/CD pipeline end to end.
A: Developer pushes code to the main branch. GitHub webhook notifies Jenkins immediately. Jenkins pulls the latest code (Checkout stage). Compiles the project (Build stage) — if compilation fails, the pipeline stops here. Runs the TestNG suite in headless Chrome (Run Tests stage). Generates Allure and TestNG reports (Publish Reports stage). If all tests pass, a Slack message says "Build passed." If any test fails, an email is sent with links to the Allure report showing screenshots and error details. Every night at 2 AM, a cron trigger runs the full regression suite with the same flow. Parameterized builds allow manual runs with custom browser and environment settings.
Q: How do you handle flaky tests in CI?
A: First, I configure a TestNG retry analyzer that automatically retries failed tests once. If it passes on retry, the report marks it as "flaky" rather than "failed." Second, I review the Allure trend charts — if a test alternates between pass and fail across builds, it is flaky. Third, I investigate root causes: usually it is a missing wait, a timing issue, or stale element. I fix the test and monitor it over the next 10 builds. If a test is consistently flaky and unfixable, I quarantine it in a separate "flaky" group and exclude it from the main pipeline until fixed. We never ignore flaky tests — they erode trust in the entire suite.
In interviews, always speak in terms of "We do this in our pipeline" — not "I read that you can do this." Show ownership. Even if you set it up for practice, say "In my project, I configured Jenkins with..." not "I think Jenkins can...".
Key Point: CI/CD questions appear in every automation interview. Know your pipeline end to end — triggers, stages, headless mode, reports, and notifications. Speak with ownership.
Answer all 5 questions, then submit to see your score.
1. What does the "H" symbol in Jenkins cron expression "H 2 * * 1-5" do?
2. Why must Selenium tests run in headless mode on CI servers?
3. What is the main advantage of a Pipeline job (Jenkinsfile) over a Freestyle job?
4. In a parameterized Jenkins pipeline, how do parameters reach your Java test code?
5. Which trigger setup is the best practice for a production CI/CD pipeline?