CTAL-AT — Advanced Agile Tester (v2.0) glossary

146 terms the exam expects you to know, defined in plain language.

A

A/B testing(a/b testing): An experimentation method that compares two versions of a system to determine which performs better.
Acceptance Criteria(acceptance criteria): Conditions that a user story must satisfy to be accepted by the product owner.
Acceptance Criteria Engineering(acceptance criteria engineering): The practice of ensuring user stories have clear, testable conditions of satisfaction.
Acceptance Test-Driven Development (ATDD)(atdd, acceptance test-driven development): A practice suitable for Scrum's sprint planning and review, where tests are defined before implementation.
Acceptance test-driven development(acceptance test-driven development, atdd): A development practice where acceptance tests are defined before coding begins to guide development.
Active Listening(active listening): A soft skill involving fully concentrating, understanding, responding, and remembering what is said during coaching or mentoring.
Additional Test Levels in SAFe(safe test levels): System integration testing and other levels introduced when scaling agile frameworks beyond single-team Scrum or Kanban.
Automated Decision-Making in CI/CD(automated decision-making): The use of objective test data to make fast, consistent go/no-go decisions.
Automated Risk Analysis Tools(automated risk analysis tools): Tools that analyze code changes, defect data, and coverage to dynamically adjust the test suite per build.
Automated decision-making(automated decision-making): The use of objective data from tests and analysis to make fast, consistent go/no-go decisions.
Automated risk analysis tool(automated risk analysis tools): A tool that analyzes code changes, historical defects, and coverage to dynamically adjust the test suite for each build.

B

Balance Between Strictness and Practicality(balance between strictness and practicality): A principle for designing effective quality gates that are neither too lax nor too restrictive.
Behavior-Driven Development (BDD)(bdd, behavior-driven development): A practice that aligns with Scrum ceremonies and can be applied incrementally in Kanban.
Behavior-driven development(behavior-driven development, bdd): A development practice where tests are defined in a natural language format based on behavior scenarios.
Business Impact Analysis(business impact analysis): Analysis used to derive risk thresholds from business priorities and historical data.

C

CI/CD Pipeline(ci/cd pipeline): Automated pipeline with quality gates that enforce risk thresholds for deployment.
CI/CD Pipeline Integration(ci/cd pipeline integration): The incorporation of test automation into continuous integration and deployment pipelines for continuous testing.
Canary releases(canary releases, canary deployment, canary): A deployment strategy where a new version is gradually rolled out to a subset of users.
Chaos Engineering(chaos engineering): The practice of intentionally injecting failures into systems to test resilience.
Coaching in Agile Teams(coaching): A practice focused on helping team members develop specific skills or solve immediate problems through guided questioning and feedback.
Code Coverage(code coverage): Metric measuring the percentage of code exercised by tests, used as a risk threshold criterion.
Common Test Data Management(common test data management): Management of test data that is shared across teams to avoid duplication and ensure consistency.
Continuous Delivery(continuous delivery, cdel): A software development practice where every change is automatically built, tested, and prepared for release to production, but the final deployment is a manual business decision.
Continuous Delivery pipeline(pipeline): A pipeline that uses automation and metrics to enable fast and reliable releases.
Continuous Deployment(continuous deployment, cdepl): A software development practice where every change that passes automated tests is automatically deployed to production without human intervention.
Continuous Quality and DevOps Testing(continuous quality and devops testing): A topic area focused on integrating quality assurance and testing throughout continuous delivery and DevOps pipelines.
Continuous Risk Assessment(continuous risk assessment): The ongoing evaluation of risks throughout the delivery pipeline, not just at the start of a release.
Continuous Testing(continuous testing): The practice of running automated tests throughout the software delivery pipeline for fast feedback.
Contract Test(contract test, contract tests, contract testing): A test ensuring services adhere to agreed interfaces in a microservices architecture.
Cross-Team Test Coordination Forum(cross-team test coordination forum): A regular meeting or communication channel dedicated to coordinating testing activities across teams.
Cross-Team Testing Coordination(cross-team testing coordination): A practice of aligning testing efforts across teams to ensure consistent quality and detect integration issues early.

D

DORA Metrics(dora metrics): Production metrics used to inform risk decisions in continuous delivery.
Data-Driven Testing(data-driven testing): An approach that uses external data sources to drive test execution, promoting test independence and reusability.
Database Snapshot(database snapshots): A technique for providing consistent test data by restoring a known database state before test execution.
Defect Prevention(defect prevention): A focus on avoiding defects rather than finding them after the fact.
Dependency Matrix(dependency matrix): A tool that maps dependencies between teams or components to manage integration testing.
Deployment Pipeline(deployment pipeline): An automated system that orchestrates the build, test, and deployment stages of software delivery.

E

Ephemeral Environments(ephemeral environments): Temporary test environments created on demand to avoid bottlenecks from shared environments.

F

False Confidence in Simulations(false confidence): The risk of misplacing trust in unvalidated virtual services leading to incorrect testing outcomes.
Feature Flags(feature flags, feature flag, feature toggle): A technique that allows enabling or disabling features in production without deploying new code.
Feature Toggle(feature toggle, feature toggles, feature flag, feature flags): A technique that decouples deployment from release by allowing incomplete features to be deployed in an inactive state and activated later.
Feature toggles(feature toggles): A technique that enables or disables features at runtime without deploying new code.
Flaky Tests(flaky test, flaky tests): Tests that intermittently pass or fail, eroding trust in the test suite and requiring prompt fixing or removal.

G

GROW Model(grow model): A structured coaching framework comprising Goal, Reality, Options, and Will to guide conversations.
Gherkin(gherkin): A structured, business-readable language for documenting examples in Given-When-Then format.
Given-When-Then Format(given-when-then, given-when-then format, given/when/then): A structured format for BDD scenarios describing preconditions, actions, and expected outcomes.
Go/No-Go Gates(go/no-go gates, quality gates): Automated checkpoints in a CI/CD pipeline that evaluate risk thresholds to allow or block deployment.
Go/no-go decision(go/no-go decision, go/no-go decisions): A binary decision to proceed or stop a build promotion based on quality criteria.
Guided Questioning(guided questioning, open-ended questions): A coaching technique using open-ended questions to encourage self-discovery and critical thinking.

H

Honeycomb Model(honeycomb model): A test automation model for microservices with many integration tests, fewer contract tests, and few end-to-end tests.

I

Ice-Cream Cone Anti-Pattern(ice-cream cone anti-pattern): An undesirable test distribution where UI tests outnumber lower-level tests, causing slow and brittle suites.
Infrastructure as Code(infrastructure as code, iac): Managing and provisioning test environments through machine-readable configuration files.
Integration Test(integration test, service test, integration tests): A test verifying interactions between components, often using test doubles.
Integration Tests(integration tests): A testing level where individual units are combined and tested as a group to identify interface defects.
Integration testing (SAFe)(integration testing, system-level validation): Coordinated testing across multiple teams at the end of a Program Increment to validate system-level integration.

K

Kanban Flow-Based Testing(flow-based testing, demand-driven testing): A continuous testing approach triggered by work item demand without fixed iterations.
Kanban continuous testing(continuous testing, kanban continuous testing): A testing approach in Kanban where testing is performed continuously throughout the development process without fixed timeboxes.

L

Living documentation(living documentation): Documentation that stays up-to-date because it is derived from executable specifications and tests.

M

Mentoring in Agile Teams(mentoring): A longer-term relationship where an experienced tester shares knowledge and career guidance with a less experienced colleague.
Mob Testing(mob testing): A collaborative testing practice where the entire team tests software together.
Multi-Framework Artifact Sharing(multi-framework artifact sharing): Using common repositories for consistency across frameworks.
Multi-Framework Test Artifact Sharing(test artifact sharing across frameworks): The use of a common repository and standardized templates to share test cases and defect reports across teams using different frameworks.
Multi-framework sharing(multi-framework sharing): A practice of using common repositories for test artifacts across multiple testing frameworks.

O

Observability(observability): The ability to infer internal system state from external outputs, relying on monitoring, logging, and alerting.
Observability and monitoring(observability and monitoring, observability, monitoring): The practice of extending testing into production through data collection to enable rapid detection and response to defects.
Observability in Testing(observability into the testing strategy, integrating observability into the testing strategy): The practice of incorporating observability into testing to achieve continuous quality and faster feedback loops.
One-Size-Fits-All Test Strategy Mistake(one-size-fits-all test strategy): The error of applying the same test strategy across frameworks without adapting to their rhythms and practices.

P

Page Object Model(page object model, pom): A design pattern for UI test automation that encapsulates page elements and actions to improve maintainability.
Pair Testing(pair testing): A collaborative testing practice where two team members work together to test software.
Parallel Test Execution(parallel test execution): Running multiple tests simultaneously to reduce feedback time in continuous testing.
Parameterized Tests(parameterized test, parameterized tests): A technique that runs the same test logic with multiple sets of input data to reduce duplication and improve coverage.
Performance Benchmarks(performance benchmarks): Quantitative criteria for performance metrics like response time, used as risk thresholds.
Periodic Validation Against Real Services(periodic validation against real services): A quality assurance practice that compares virtual services with real ones to maintain fidelity.
Pipeline Go/No-Go Decisions(pipeline go/no-go decisions, pipeline go/no-go decision, go/no-go decisions): Decisions based on risk thresholds to determine whether to deploy or roll back.
Potentially releasable increment(releasable increment, sprint increment): A product increment produced by a sprint that is ready for release after testing and validation.
Production Monitoring(production monitoring): The practice of monitoring software in production to detect issues, complementing pre-release testing with real-world observation.
Production feedback loop for risk adaptation(production feedback to inform risk decisions, feedback loops and risk adaptation): The process of using production monitoring data to update risk assessments and adjust the test strategy accordingly.

Q

Quality Gate(quality gate, quality gates, gate): A set of criteria that must be satisfied before a build can proceed to the next stage in a deployment pipeline.
Quality Gates(quality gates): Checkpoints in a continuous delivery pipeline that enforce quality criteria before promoting changes.

R

Refactoring(refactoring): A team practice that improves code quality without changing its external behavior.
Refactoring Test Code(test code refactoring, refactoring test code): Improving the internal structure of test code without changing its external behavior to enhance readability, reduce duplication, and improve maintainability.
Refactoring in Safe Steps(small safe steps, small safe steps refactoring, refactoring in safe steps): Performing refactoring changes in small, incremental steps with continuous verification to avoid introducing errors.
Risk Thresholds(risk thresholds): Quantitative criteria reflecting the team's risk appetite for key quality metrics.
Risk Thresholds for Pipeline Gates(risk thresholds): Agreed-upon criteria that determine deployment decisions in the continuous delivery pipeline.
Risk threshold(risk thresholds): A predefined level of acceptable risk used by the pipeline to make automated decisions about test execution and deployment.
Risk-Based Test Prioritization(risk-based test prioritization, prioritizing tests based on risk): Ordering tests based on risk level to ensure critical tests run first within time constraints.
Risk-Based Testing(risk-based testing, rbt): Prioritizing tests based on risk to optimize coverage and resource allocation.
Risk-Based Testing in Continuous Delivery(risk-based testing in continuous delivery): A testing approach that continuously assesses risks and adjusts the test strategy based on pipeline feedback.

S

SAFe Program Increments(program increments, pis, program increment, pi): Fixed timeboxes in the Scaled Agile Framework that align testing across multiple teams at program and portfolio levels.
SAFe program increment(program increment, pi): A time-boxed planning interval in SAFe that coordinates testing across multiple teams.
Safe Refactoring Steps(refactoring in safe steps): Incremental code changes made with passing tests to avoid introducing defects.
Scrum Sprint(sprint, scrum sprint): A fixed-length iteration (1–4 weeks) that constrains development and testing to produce a potentially releasable increment.
Scrum Time-Boxed Sprints(time-boxed sprints): Fixed-length iterations in Scrum that constrain test activities to fit within the sprint duration.
Security Scan Results(security scan results): Outcomes of security scans, used as criteria for risk thresholds in deployment gates.
Separating Refactoring Commits(separating refactoring commits, separate refactoring commits): The practice of not refactoring tests and production code in the same commit to isolate issues.
Separation of Concerns(separation of concerns): An architectural principle that improves maintainability by isolating different aspects of a test automation framework.
Separation of Concerns in Test Automation(separation of concerns, separation of concerns in test automation): An architectural principle that isolates different aspects of a test automation framework, improving maintainability and reuse.
Service Tests(service tests, api tests): Tests that verify interactions between components via APIs, offering a balance of speed and coverage.
Service Virtualization(service virtualization): A testing technique that simulates unavailable or costly real components.
Shared Responsibility for Test Quality(team ownership of tests, shared responsibility for test quality): The practice where the whole team collectively owns and maintains the test suite with the same care as production code.
Shared Test Environments(shared test environments): Test environments that are used by multiple teams to run their tests.
Shared Test Responsibility(shared test responsibility): The practice where the whole team collectively owns the test suite, treating it with care like production code.
Shift Left Testing(shift-left testing, shift testing left, shift-left, shift left testing): A practice that integrates quality activities throughout the entire software lifecycle from requirements to production.
Shift-Left Quality(shifting left): A DevOps practice of catching quality issues early in the development lifecycle through automated gates.
Shift-right testing(shift-right testing): A software testing approach that extends testing into the production environment using real-world data and conditions.
Soft Skills, Communication, and Team Dynamics(soft skills, communication, and team dynamics): A topic area addressing interpersonal skills, effective communication, and collaboration within software teams.
Specification by Example(sbe, specification by example): A technique using concrete examples to define requirements and tests simultaneously.
Staged Pipeline(staged pipeline): A pipeline with fast smoke tests early and longer regression suites later to keep feedback loops short.
Synchronized Release Schedules(synchronized release schedules): Coordinated release timelines across teams to manage dependencies and avoid conflicts.
Synthetic monitoring(synthetic monitoring): A technique that simulates user interactions to monitor application performance and availability.
System demo(system demo, demo): An event at the end of a PI where teams showcase integrated work from the increment.

T

Test Automation Architecture(test automation architecture): The structural design of a test automation framework that supports reuse, separation of concerns, and CI/CD integration.
Test Automation Ice-Cream Cone(test automation ice-cream cone): An anti-pattern where over-investment in UI automation leads to a top-heavy, slow, and brittle test suite.
Test Automation Pyramid(test automation pyramid, test pyramid): A model that guides the distribution of automated tests across unit, service, and UI layers for fast, reliable feedback.
Test Automation in Agile Environments(test automation in agile environments): A topic area covering strategies and practices for automated testing within agile software development.
Test Data Factories(test data factories): Design patterns that create consistent test data objects for use across different test layers.
Test Data Factory(test data factories): A pattern to generate test data programmatically, ensuring consistent and isolated data for automated tests.
Test Data Management(test data management): Strategies such as data-driven testing, test data factories, and database snapshots to maintain consistent, isolated test data.
Test Debt(test debt): The accumulation of deferred or skipped tests that must be managed to avoid increased risk over time.
Test Double(test double, test doubles): A substitute for a real component used in integration tests to isolate interactions.
Test Doubles(test doubles): Objects that replace real dependencies in tests to isolate the unit under test, such as mocks and stubs.
Test Impact Analysis(test impact analysis): Analyzing code changes to run only tests affected by those changes.
Test Maintenance(test maintenance in agile): The continuous activity of updating, removing, or adding tests as the system and requirements change in agile environments.
Test Maintenance in Agile(test maintenance in agile, test maintenance): Continuous activity of updating, removing, or adding tests as the system and requirements change.
Test Pass Rate(test pass rate): Metric measuring the percentage of test cases that pass, used as a risk threshold criterion.
Test Pyramid(test pyramid, classic test pyramid): A model for test automation recommending many unit tests, fewer integration tests, and few UI tests for fast feedback.
Test Roles in Kanban(tester focusing on flow efficiency): Role where the tester focuses on flow efficiency and bottleneck removal.
Test Roles in SAFe(system test engineer): Dedicated test roles, such as system test engineer, at the program level.
Test Roles in Scrum(tester as coach in scrum): Role where the whole team is responsible for quality, with the tester acting as a coach.
Test Strategy Tailoring to Agile Frameworks(tailoring test strategy to agile frameworks, test strategy tailoring, test strategy for agile frameworks, agile test strategy): The adaptation of test strategy to the unique cadence, roles, and practices of each agile framework.
Test Trophy Model(test trophy model): A modern test automation variant emphasizing integration tests over unit tests for confidence and speed.
Test automation(automated testing, automated unit and api tests): The use of automated tests to keep pace with time-boxed iterations and avoid testing bottlenecks.
Test-Driven Development (TDD)(tdd, test-driven development): A practice where tests are written before the code to ensure defects are caught early.
Testing Roles and Responsibilities in Agile(testing roles, testing responsibilities in agile): The assignment of testing tasks across the team, varying by framework (e.g., developers write unit tests).
Testing roles and responsibilities(roles and responsibilities for testing): The defined roles and responsibilities for testing that vary across different development frameworks.
Testing roles and responsibilities across frameworks(roles and responsibilities): The distinct testing duties and accountabilities that must be clearly defined for different Agile frameworks.
Three amigos(three amigos, three amigos (business, dev, test)): The collaboration of business, development, and testing roles to create and refine concrete examples.
Threshold Calibration(calibrate thresholds): The process of adjusting quality gate thresholds based on historical data and feedback to balance rigor and speed.
Time-box(time-box, timebox): A fixed duration that constrains activities and enforces prioritization and prevents scope creep.
Traditional Test Pyramid(traditional test pyramid): A testing model for monolithic applications with many unit tests and fewer integration tests.

U

UI Test(ui test, end-to-end test, ui tests): A test simulating real user interactions, typically slow and fragile.
UI Tests(ui tests, user interface tests): Tests that simulate user interactions through the graphical interface, known for being slow, fragile, and expensive to maintain.
Unit Test(unit test, unit tests): A test verifying individual components in isolation, written by developers.
User Interface Tests(ui tests, user interface tests): Tests that simulate user interactions through the graphical interface, which are slow, fragile, and expensive to maintain.

V

Version Control of Virtual Services(version control of virtual services): The practice of managing versions of simulated services to ensure accuracy.
Virtualization(virtualization): The creation of a virtual version of a resource such as a server, storage device, or network, enabling multiple operating systems to run on a single physical machine.