CTAL-ATT — Agile Technical Tester glossary

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

A

Acceptance Criteria(acceptance criteria): Clear, unambiguous, and verifiable conditions that a user story must satisfy to be considered complete.
Acceptance Test Automation(acceptance tests, acceptance test automation): Automated confirmation that software meets business requirements, often using business-facing scenarios and tools like Cucumber or FitNesse.
Acceptance Test-Driven Development(acceptance tests before implementation): A software development approach where acceptance tests are collaboratively defined before implementation to ensure shared understanding.
Acceptance Test-Driven Development (ATDD)(atdd): A collaborative practice where acceptance criteria are defined as executable tests before coding, involving developers, testers, and business stakeholders.
Agile Test Automation Pyramid(test automation pyramid): A model that prioritizes extensive unit test automation as the foundation, with diminishing automation at integration, system, and acceptance levels.
Automated Tests(automated tests, automated tests in definition of done, automated tests in the definition of done): Tests that are created and executed automatically for a story, required to be passing as part of the Definition of Done.
Automated Tests in Definition of Done(automated tests as part of definition of done): The requirement that all automated tests for a user story are created and passing before completion.
Automation Levels(levels of automation): Categorization of test automation maturity, such as unit, integration, system, and acceptance levels.
Automation Levels in Agile(automation levels, selecting automation levels): The application of test automation at unit, integration, system, and acceptance levels based on objectives, risk, and feedback speed.

B

Behavior-Driven Development (BDD)(bdd): A software development methodology using Gherkin language to write behavioral scenarios in Given-When-Then format.

C

CI/CD Integration(continuous integration/continuous delivery, ci/cd pipeline): The practice of integrating automated tests into continuous integration and continuous delivery pipelines.
CI/CD Pipeline Integration for Automation(ci/cd pipeline): The practice of integrating automated tests into the continuous integration and delivery pipeline to provide fast feedback.
Charter(charter, charters): A mission statement that defines the scope and mission of an exploratory testing session.
Checklist-Based Testing(checklist-based testing): A technique using a list of items to verify, derived from past defects, requirements, or quality characteristics.
Code Coverage Thresholds(code coverage thresholds): Minimum levels of code coverage that must be met before a product increment is considered done.
Continuous Delivery(cd, continuous delivery): The practice of keeping software in a deployable state through an automated pipeline, with manual release decision.
Continuous Deployment(continuous deployment): The practice of automatically deploying every change that passes the pipeline to production.
Continuous Deployment and Delivery(continuous deployment and delivery): A software engineering approach that automates the building, testing, and releasing of code changes to production.
Continuous Integration Pipeline(ci pipeline): An automated process that builds, tests, and validates code changes frequently, often hosting integration tests.
Continuous Testing(continuous testing): The process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on business risks.
Controllability(controllability): The ability to set up specific conditions for testing a software component.

D

Data-Driven Approach(data-driven testing): A test automation approach where test scripts read test data from external sources to vary test inputs.
Data-Driven Testing(data-driven testing, data-driven approach): A technique where test data is stored separately from the test script and used to execute the same test with multiple data sets.
Debrief(debrief, debrief in exploratory testing, debriefs, debrief after exploratory testing, debrief session): A session where the tester reports findings, coverage, and issues after an exploratory testing session.
Defect Taxonomy(defect taxonomy): A classification of defect types used to guide error guessing and risk analysis.
Definition of Done(dod, definition of done): A shared understanding of what it means for work to be complete, including verification activities beyond unit tests.
Definition of Ready(dor, definition of ready, definition of ready (dor)): A set of criteria that a user story must meet before the team can start work on it during a sprint.
Dependency Injection(dependency injection, di): A design pattern that allows injecting dependencies into a class to improve testability.
Deployment Pipeline(deployment pipeline, automated deployment pipeline): The automated sequence of stages that code changes go through from commit to production-ready.
Design for Testability(design for testability, testable design): A design approach that considers testability throughout the development process.

E

Error Guessing(error guessing): A technique relying on tester experience to anticipate where defects are likely to occur.
Experience-Based Testing(experience-based testing, ebt): A testing approach that leverages tester knowledge and intuition to find defects not caught by scripted tests.
Exploratory Testing(exploratory testing): A hands-on approach where testers simultaneously learn, design, and execute tests.
Exploratory Testing in Continuous Delivery(exploratory testing): Manual testing for complex scenarios and usability, complementing automated tests in the pipeline.

F

Flaky Test(flaky test, flaky tests): An unreliable test that produces inconsistent results, undermining trust in the pipeline.
Flaky Tests(flaky tests, flaky test): Unreliable tests that produce inconsistent results, undermining trust in the pipeline.

G

Gherkin language(gherkin): A business-readable domain-specific language for writing BDD scenarios with Given-When-Then steps and And/But for additional conditions.
Given-When-Then(given-when-then steps): A pattern for writing test scenarios in BDD specifying preconditions, actions, and expected outcomes.

I

ISTQB Glossary Definitions(glossary definitions): Standardized definitions of testing terms used as exact wording in exam vocabulary questions.
ISTQB Sample Exam Rationale(rationale document): Document explaining why answer choices in sample exams are correct or incorrect for exam reasoning practice.
Immediate Feedback Cycle(immediate feedback, rapid feedback, immediate feedback cycle): The rapid feedback obtained from automated tests executed upon code commits or deployments.
Integration Test Automation(integration tests, integration test automation): Automated verification that different modules or services work together correctly, often as part of a continuous integration pipeline.

K

K-Levels (K2, K3, K4)(cognitive levels, k2 k3 k4): Cognitive level classifications in ISTQB learning objectives: understand, apply, analyze.
Keyword-Driven Approach(keyword-driven testing): A test automation approach where test actions are represented as keywords in a table-driven format.
Keyword-Driven Testing(keyword-driven testing, keyword-driven approach): An approach that uses action words (keywords) to represent user actions, enabling non-technical team members to create and maintain tests.

M

Maintainable Automated Tests(maintainable automated tests): Automated tests that are easy to maintain and do not reduce overall testability.

N

Non-functional Requirements(non-functional requirements): Requirements related to performance, security, and other quality attributes that must be verified as part of the Definition of Done.

O

Observability(observability): The ability to see internal states of a software component during testing.
Observability in Continuous Testing(observability, test visibility): The visibility of test results to the whole team, enabling prompt investigation of failures and monitoring of test suite health.

P

Process-Step Order(order of steps, process steps): The correct sequence of activities in a testing process, often tested in exam questions.

R

Red-Green-Refactor cycle(red-green-refactor): The core TDD cycle of writing a failing test (Red), making it pass (Green), and then improving code structure (Refactor).
Refactoring for Testability(refactoring for testability): Incremental code changes made to improve testability without altering behavior.
Refactoring in TDD(refactoring): The step in the TDD cycle where code structure is improved while keeping all tests passing.
Regression Testing(regression tests, regression testing): Testing performed to ensure that existing functionality still works after changes, required by the Definition of Done.
Risk Analysis(risk analysis): A method to identify high-risk areas for testing, often used with error guessing to prioritize test ideas.

S

Session-Based Test Management(session-based test management, sbtm): A structured approach to exploratory testing using charters, timeboxes, and debriefs.
Severity vs. Priority(severity priority distinction): Distinction between the impact of a defect (severity) and the urgency to fix it (priority).
Shared Responsibility for Quality(shared responsibility): A culture where developers, testers, and operations collaborate on test maintenance and pipeline improvements.
Shift-left Testing(shift-left mindset, shift-left approach): A mindset where testing activities are performed earlier in the development lifecycle to detect defects sooner.
Staged Test Strategy(staged test strategy, prioritizing tests): A strategy that prioritizes and stratifies tests, running fast and reliable tests first and slower tests later.
System Test Automation(system tests, system test automation): Automated end-to-end validation of the entire application to ensure it behaves as expected.

T

Test Automation Pyramid(test automation pyramid): A model suggesting most automated tests at unit level, fewer at service level, and fewest at UI level to optimize speed and maintainability.
Test Automation Trade-offs(automation effort trade-offs): The balance between automation investment and maintenance costs, warning against over-automating at the system level to avoid fragile suites.
Test Automation in Agile(test automation in agile): The practice of using automated testing tools within Agile development to verify code changes quickly and frequently.
Test Doubles(test doubles, mocks, stubs, fakes): Objects such as mocks, stubs, and fakes used to isolate units during testing.
Test Session(test session, session): A period of uninterrupted testing activity, typically 60 to 120 minutes, focused on a specific charter.
Test Suite Health(test suite health, test suite reliability): The reliability, speed, and coverage of a test suite, monitored to ensure pipeline effectiveness.
Test-Driven Development (TDD)(tdd): A test-first approach in which test cases are developed before the code and the code is developed only enough to pass the test.
Test-Driven Development (TDD) cycle(tdd cycle): A software development cycle consisting of writing a failing test, writing minimum production code to pass it, and refactoring.
Test-first approach(test-first, test-first approach): A development practice where tests are written before the implementation code.
Testability(testable, testability): The property of a user story that ensures it can be tested without delays, supported by clear acceptance criteria and available test data.
Timebox(timebox, timeboxed): A fixed duration, typically 60-90 minutes, allocated for an exploratory testing session.

U

Unit Test Automation(unit tests, unit test automation): Automated verification of the smallest code parts, such as functions or methods, providing fast feedback on code changes.

V

Validation vs. Verification(validation verification distinction): Distinction between ensuring the product meets user needs (validation) and conforms to specifications (verification).