CI/CD questions show whether you can operate in a real development workflow or just run tests from your IDE. Even if you are not a DevOps engineer, you must know how your tests fit into the pipeline. Mention specific tools: Jenkins, Git, Maven, Docker.
Q: What is CI/CD? How do automated tests fit into it?
A: CI (Continuous Integration) — developers merge code frequently into a shared repository with automated builds and tests on every merge. CD (Continuous Delivery) — after tests pass, the application can be deployed to staging or production. Automated tests fit at every stage: unit tests run on every commit (seconds), API and integration tests after the build (minutes), UI smoke tests after deployment to QA (minutes), full regression nightly (hours). In my project: developer pushes code > Jenkins triggers build > unit tests run > app deploys to QA > smoke suite runs (15 minutes, 20 critical tests) > if smoke passes, regression runs nightly (200 tests, 1.5 hours). If any stage fails, pipeline stops and Slack notification goes to the team with the failure details and report link.
Q: How do you integrate Selenium tests with Jenkins?
A: Setup: (1) Install plugins — Maven Integration, Git, TestNG Results, Allure. (2) Create a Pipeline job. (3) Jenkinsfile stages: Checkout (git clone), Build (mvn clean compile), Smoke Test (mvn test -DsuiteXmlFile=testng-smoke.xml), Regression (mvn test -DsuiteXmlFile=testng-regression.xml — runs only if smoke passes), Report (allure generate), Notify (Slack message with results). (4) Triggers: GitHub webhook for push-triggered smoke, cron "H 2 * * 1-5" for nightly regression. (5) Environment: tests run headless on the Jenkins agent with Chrome installed, or in Docker containers. (6) Parameters: browser choice, environment, suite file — so the same pipeline works for different configs. The key point: CI integration is not optional. Tests that only run locally are tests that get forgotten.
Q: What does your Jenkins pipeline look like?
A: pipeline { agent any; parameters { choice(name: "BROWSER", choices: ["chrome","firefox"], description: "Browser"); choice(name: "ENV", choices: ["qa","staging"], description: "Environment"); }; stages { stage("Checkout") { steps { git branch: "main", url: "repo-url" } }; stage("Smoke") { steps { sh "mvn test -DsuiteXmlFile=testng-smoke.xml -Dbrowser=${BROWSER} -Denvironment=${ENV}" } }; stage("Regression") { when { expression { currentBuild.result == null } }; steps { sh "mvn test -DsuiteXmlFile=testng-regression.xml -Dbrowser=${BROWSER}" } }; stage("Report") { steps { allure(["allure-results"]) } } }; post { failure { slackSend(message: "Tests failed: ${BUILD_URL}allure") }; success { slackSend(message: "All tests passed") } } }. Regression only runs if smoke passes. Reports are always generated. Notifications go either way.
Q: What Git branching strategy do you follow?
A: Simplified Git Flow: main — always stable and deployable, only updated via pull requests. develop — integration branch where features merge after review (some teams skip this). feature/* — created from develop for new work: feature/add-cart-tests, feature/update-login-page. hotfix/* — created from main for urgent fixes. My workflow: create feature branch, develop and test locally, push to remote, create pull request, get code review, merge to develop (or main). Key rules: never commit directly to main. Always pull latest before creating a branch. Write descriptive commit messages: "Add login validation tests for empty fields" not "update tests". In smaller teams, we merge features directly to main after review — the develop branch adds overhead when the team is small.
Q: What Git commands do you use daily?
A: git clone <url> — clone the repo first time. git pull — get latest changes. git checkout -b feature/add-login-tests — new branch. git status — see changed files. git add . — stage changes. git commit -m "Add login validation tests" — commit. git push origin feature/add-login-tests — push branch. git merge main — keep my branch updated. git stash / git stash pop — save and restore uncommitted work. git log --oneline — view history. git diff — see changes. For conflicts: open the conflicted file, resolve the <<<< ==== >>>> markers manually, then git add and git commit. For undoing mistakes: git checkout -- filename to discard changes, git reset HEAD~1 to undo the last commit (keeping changes). These commands cover 95% of my daily Git usage.
Q: How do you use Docker with Selenium?
A: Docker provides consistent, isolated environments for running tests. I use official Selenium Docker images: selenium/standalone-chrome for single-browser execution, selenium/hub + selenium/node-chrome + selenium/node-firefox for Grid setup. Docker Compose: services: chrome: image: selenium/standalone-chrome; ports: 4444:4444. Tests connect via RemoteWebDriver to http://localhost:4444. Benefits: (1) Same Chrome version everywhere — no "works on my machine" issues. (2) Easy parallel scaling — spin up multiple containers. (3) No need to install browsers on CI server. (4) Clean state every time — containers are disposable. In my Jenkins pipeline: docker-compose up -d starts containers, mvn test runs tests, docker-compose down tears everything down. I also use Docker for the application itself — docker-compose runs both the app and the test containers.
Q: What is Maven? Why do you use it in your framework?
A: Maven is a build automation and dependency management tool. I use it for: (1) Dependency management — declare Selenium, TestNG, Allure, Apache POI, RestAssured in pom.xml, Maven downloads everything from Maven Central. No manual JAR management. (2) Standard project structure — src/main/java, src/test/java, src/test/resources. Everyone knows where to find things. (3) Build lifecycle — mvn clean compile, mvn test, mvn install. (4) Surefire Plugin — runs TestNG suites: <suiteXmlFiles><suiteXmlFile>${suiteXmlFile}</suiteXmlFile></suiteXmlFiles>. (5) Profiles — mvn test -Pqa activates QA-specific configuration. (6) CI integration — Jenkins and GitHub Actions both support Maven natively. The most important file: pom.xml. Every dependency, plugin, and configuration lives there.
Q: What is GitHub Actions? How is it different from Jenkins?
A: GitHub Actions is CI/CD built into GitHub. Workflows defined in YAML (.github/workflows/tests.yml). Key differences: (1) GitHub Actions is cloud-hosted — no server to maintain. Jenkins is self-hosted — you manage the infrastructure. (2) GitHub Actions uses YAML, Jenkins uses Groovy Jenkinsfile. (3) GitHub Actions is free for public repos with generous limits. Jenkins is free but you pay for the server. (4) GitHub Actions integrates natively with GitHub events. Jenkins needs webhooks. (5) GitHub Actions has a marketplace of pre-built actions. Jenkins has plugins. A basic workflow: on: [push]; jobs: test: runs-on: ubuntu-latest; steps: - uses: actions/checkout@v4; - uses: actions/setup-java@v4; - run: mvn test. I use GitHub Actions for open-source and small projects, Jenkins for enterprise projects with complex pipelines and on-premise requirements.
Key Point: CI/CD is not optional for QA automation. Know how to integrate your tests into a pipeline, trigger them on code changes, and generate reports automatically.