CI/CD & DevOps for QA

Blue-green deployment testing verifies a release strategy where two identical production environments (blue and green) exist, with live traffic on one while the other receives the new release — testing the new version in isolation before switching traffic over, and enabling near-instant rollback by switching back.

A Build Verification Test (BVT) is a minimal, fast set of automated checks run against every new build to confirm it's stable enough to proceed to further testing — closely related to smoke testing, and often used interchangeably with it in CI/CD contexts specifically.

Canary release testing validates a new version by rolling it out to a small percentage of real production traffic first, closely monitoring for errors or performance regressions, before gradually increasing the rollout to the full user base — catching problems while the blast radius is still small.

Chaos engineering deliberately injects failures — killing servers, adding network latency, exhausting resources — into a system, often in production, to proactively discover weaknesses before they cause a real, unplanned outage. It treats resilience as something to continuously verify rather than assume.

A CI/CD pipeline is the automated sequence of steps — build, test, and deploy — that takes code from a commit to a running release, typically triggered automatically on every push. It's the infrastructure that makes continuous integration and continuous delivery/deployment actually operational, not just a philosophy.

Continuous delivery ensures code is always in a deployable state after passing through the automated pipeline — built, tested, and ready to release at any time — though the actual release to production still requires a manual trigger, distinguishing it from continuous deployment, which releases automatically.

Continuous deployment automatically releases every change that passes the pipeline's automated tests directly to production, with no manual approval step — the most advanced end of the CI/CD spectrum, requiring very high confidence in the automated test suite, since there's no human safety net before release.

Continuous Integration (CI) is the practice of merging code changes into a shared codebase frequently — multiple times a day — with each merge automatically built and tested, catching integration problems within minutes of them being introduced rather than days or weeks later.

DevOps testing integrates testing throughout the entire software delivery lifecycle — development, deployment, and live operation — rather than treating it as a separate phase handled solely by a distinct QA team after development finishes. It's a cultural and process shift as much as a technical one.

Feature flag testing verifies that toggling a feature flag correctly enables or disables the associated functionality, that different flag combinations don't produce unexpected interactions, and that flags can be safely turned off in production without requiring a full redeploy if something goes wrong.

GitOps for QA applies GitOps principles — infrastructure and configuration defined declaratively in version control, changes applied automatically through pull requests — to test environments and testing infrastructure, keeping environment configuration reviewable, versioned, and reproducible rather than manually configured and drifting.

A quality gate is a defined checkpoint in a development or deployment pipeline that a change must pass before proceeding — a minimum test pass rate, a code coverage threshold, zero critical vulnerabilities — automatically blocking progress if the criteria aren't met, rather than relying on someone remembering to check manually.

Shift-left testing means moving testing activities earlier in the development process — writing tests alongside code, running static analysis on every commit, and involving QA in requirements and design — instead of testing only after development is "done." The goal is catching defects when they're cheap to fix, not after they've compounded downstream.

Shift-right testing extends verification activities into production itself — monitoring real user behavior, canary releases, synthetic monitoring, and chaos engineering — treating production as a legitimate place to continue testing, not just where testing stops and operations begins.

Synthetic monitoring runs scripted, simulated user transactions against a live production system on a regular schedule — logging in, searching, checking out — proactively detecting outages or performance degradation before real users report them, rather than waiting for actual user complaints.

Test orchestration coordinates the execution of many different tests — across suites, environments, and stages — managing scheduling, parallelization, dependencies between test stages, and result aggregation, so a complex pipeline of tests runs efficiently and reliably rather than as a fragile, manually sequenced process.