What is CI/CD and why is it important for QA?

CI (Continuous Integration): developers merge code frequently, automated builds and tests run on every merge. CD (Continuous Delivery/Deployment): code automatically progresses through stages to production. For QA: CI/CD means faster feedback (know within minutes if a change breaks something), consistent test execution (no "works on my machine"), and the ability to test every commit rather than a batch of changes. QA's role shifts from "gatekeeper" to "quality enabler" — building test automation that runs in the pipeline.

How do you design a test pipeline in GitHub Actions or Jenkins?

Typical stages: (1) Lint + unit tests (fast, fail early). (2) Build application. (3) Deploy to test environment. (4) Integration/API tests (parallel if possible). (5) E2E/UI tests (parallel shards). (6) Performance smoke test (optional). (7) Report results, upload artifacts (screenshots, videos). Key decisions: when to run (every PR, main only, nightly), parallelism (matrix strategy for browsers), and failure handling (block merge vs. warning). Cache dependencies between runs for speed.

How do you handle test environment management in a CI/CD pipeline?

Options by maturity: (1) Shared staging — simple but tests conflict with each other. (2) Ephemeral environments — spin up a fresh environment per PR (Vercel preview deployments, Docker Compose, Kubernetes namespaces). (3) Service virtualization — mock external dependencies. Best practice: ephemeral environments with database seeding, destroyed after pipeline completes. This gives isolation without maintaining permanent test environments. For external services, use sandboxes or mocks.

What is Docker and how is it used in testing?

Docker packages an application and its dependencies into a lightweight, portable container that runs consistently everywhere. For testing: (1) Consistent test environments — same container runs locally and in CI. (2) Dependency isolation — run a Postgres, Redis, or Elasticsearch container for tests without installing them. (3) Parallelism — spin up multiple isolated containers for parallel test execution. (4) Clean state — destroy and recreate containers for fresh test environments. Docker Compose orchestrates multi-container setups.

How do you optimize CI pipeline execution time for a large test suite?

Strategies: (1) Parallelism — shard tests across multiple CI runners (Playwright: `--shard=1/4`). (2) Selective testing — only run tests affected by changed files (using test impact analysis or path-based filtering). (3) Caching — cache node_modules, browser binaries, Docker layers between runs. (4) Fail fast — run smoke tests first, stop early on failure. (5) Tier tests — fast tests on every PR, full suite nightly. (6) Optimize test setup — API-based data seeding instead of UI-based, reuse auth state. Target: PR feedback in <10 minutes.

What is shift-left testing and how do you implement it?

Shift-left means moving testing earlier in the development lifecycle — finding bugs when they're cheapest to fix. Implementation: (1) Pre-commit — linting, type checking, unit tests. (2) PR-level — automated test suite, code review with testability focus. (3) Design phase — QA reviews designs and writes test scenarios before development starts. (4) Requirements — QA participates in story grooming, identifies edge cases. (5) Developer testing — encourage developers to write tests, provide easy-to-use test infrastructure. The goal: bugs found in code review, not in production.

How do you implement test reporting and notifications in CI/CD?

Reporting: use standard formats (JUnit XML, Allure) that CI tools can parse. Allure provides rich HTML reports with screenshots, steps, and history. Upload test artifacts (screenshots, videos, traces) as build artifacts. Notifications: Slack/Teams integration for failures — include test name, error message, and link to report. PR comments with test summary (GitHub Actions: dorny/test-reporter). Dashboard: Grafana for trend visualization — track test pass rate, duration, and flaky test rate over time.

What is infrastructure as code and how does it relate to test environments?

IaC defines infrastructure (servers, databases, networks) in version-controlled configuration files (Terraform, CloudFormation, Pulumi). For testing: (1) Reproducible environments — spin up identical test infrastructure on demand. (2) Environment parity — test environments match production configuration. (3) Self-service — QA can create/destroy environments without DevOps bottleneck. (4) Cost control — destroy environments when not in use. (5) Audit trail — all changes are reviewed and tracked in Git. Test environments should be defined in IaC alongside the application code.

How do you manage secrets and sensitive data in test pipelines?

Never hardcode secrets in test code or config files. Use: (1) CI secret management — GitHub Secrets, Jenkins Credentials. (2) Environment variables — injected at runtime, not stored in code. (3) Secret managers — AWS Secrets Manager, HashiCorp Vault for dynamic secrets. (4) Test-specific credentials — separate from production, rotated regularly. (5) Mask secrets in logs — most CI tools auto-mask, but verify. Common mistake: committing .env files or screenshots containing tokens. Add .env to .gitignore and scan for secrets in pre-commit hooks.

How do you implement feature flags and how do they affect testing?

Feature flags allow toggling features without deployment (tools: LaunchDarkly, Unleash, or simple config). Testing implications: (1) Test matrix expands — each flag combination is a potential state. (2) Focus on critical combinations, not all permutations. (3) Test flag default state AND enabled state. (4) Test flag transitions — what happens when a flag is toggled in production? (5) Clean up old flags — untested dead code paths. (6) Use flags for canary releases — roll out to 5% of users, monitor, then expand. QA should be involved in flag rollout plans.