Skip to main content
QA Glossary

DevOps & CI/CD glossary.

22 devops & ci/cd terms every QA engineer and SDET should know, each defined with a real-world example and an interview tip.

Browse the full QA glossary
Continuous TestingContinuous testing is the practice of executing automated tests at every stage of the CI/CD pipeline, providing immediate feedback on the risk level of each code change as it moves toward production.
Test EnvironmentA test environment is the configured infrastructure (servers, databases, services, and network settings) where tests are executed, designed to simulate production conditions at the appropriate fidelity for each testing level.
Test Data ManagementTest data management is the practice of creating, maintaining, and governing the data used in testing, ensuring tests have reliable, realistic, and compliant data across all environments.
Canary DeploymentA canary deployment is a release strategy that rolls out changes to a small subset of users or servers first, monitors for issues, and gradually expands to the full user base only after confirming stability.
Blue-Green DeploymentBlue-green deployment is a release strategy that maintains two identical production environments (blue and green), deploys the new version to the inactive environment, and switches traffic from the active to the inactive environment once verification is complete.
Feature FlagsFeature flags (also called feature toggles) are conditional switches in code that allow teams to enable or disable features at runtime without deploying new code, supporting controlled rollouts, A/B testing, and quick rollback.
ObservabilityObservability is the ability to understand the internal state of a system from its external outputs, primarily through three pillars: structured logs, metrics (time-series data), and distributed traces.
TestOpsTestOps is the discipline of applying DevOps principles, automation, continuous delivery, infrastructure as code, and observability - specifically to the management, execution, and maintenance of test infrastructure and test pipelines.
Docker for TestingDocker for testing is the practice of using Docker containers to create isolated, reproducible, and disposable test environments that ensure tests run consistently across local machines, CI/CD pipelines, and team members.
GitHub Actions for TestingGitHub Actions for testing is the use of GitHub's built-in CI/CD platform to automatically run test suites on code changes, triggered by pushes, pull requests, or schedules - with support for parallel execution, artifacts, and environment management.
Synthetic MonitoringSynthetic monitoring runs scripted, automated checks against a live system on a schedule to verify that critical user journeys and endpoints work and meet performance targets, before real users hit a problem.
IdempotencyAn operation is idempotent if performing it multiple times has the same effect as performing it once.
Service Level Objective (SLO)A Service Level Objective (SLO) is a target value or range for a measured aspect of service reliability, for example "99.
Error BudgetAn error budget is the amount of unreliability a service is allowed over a window, the gap between its Service Level Objective and 100%.
Continuous Integration (CI)Continuous Integration (CI) is the practice of merging code changes into a shared branch frequently, where each change automatically triggers a build and an automated test suite so integration problems are caught within minutes instead of at the end of a release.
Continuous Delivery (CD)Continuous Delivery (CD) is the practice of keeping software in a releasable state at all times through an automated pipeline, so that any build that passes all stages could be released to production at the push of a button.
Continuous DeploymentContinuous Deployment is the practice of automatically releasing every code change that passes the automated pipeline straight to production, with no manual approval step.
Service Level Agreement (SLA)A Service Level Agreement (SLA) is a formal, often contractual commitment to customers about the level of service they will receive, such as 99.
Dark LaunchA dark launch is the practice of deploying a feature to production but keeping it hidden from users (or running it in the background without exposing its output), so the team can test it under real production load and data before an actual user-facing release.
Rollback TestingRollback testing verifies that a system can be safely reverted from a new version or change back to the previous known-good state, restoring correct functionality without data loss or corruption, so a bad deployment can be undone with confidence.
Environment ParityEnvironment parity is the degree to which non-production environments (development, test, staging) match production in configuration, data, dependencies, and infrastructure, the closer the parity, the more reliably tests predict real production behavior.
The Four Golden SignalsThe four golden signals, popularized by Google's SRE practice, are latency, traffic, errors, and saturation: the core set of metrics that, monitored together, give a high-level picture of a production service's health and user experience.
FREE TOOLS  /  no signup

Free QA career tools, no account needed

Instant and private, everything runs in your browser. Try them before you sign up.

EXEC.NOW

Ready to Ace Your QA Interview?

Practice with AI that asks real questions about the concepts that matter.

Join 1,200+ QA engineers already practicing with AssertHired.

Start your free QA interview
FREE.TO.START  ·  7.DAY.TRIAL ON PAID PLANS
Written by Aston Cook, Senior QA EngineerStart a free mock interview