Glossary

Study as flashcards →

56 terms

API testing: Automated testing of application programming interfaces, built on knowledge of API connections and documentation; often extended with contract testing.
Architecture transparency: A testability aspect: the SUT's architecture documentation provides clear, understandable components and interfaces that give observability and controllability at all test levels.
Assertion: An executable check used by a test tool to compare specific elements of the actual result against the expected result and determine pass or fail.
Behavior-driven development (BDD): Expressing desired behavior as Given/When/Then acceptance criteria stored in feature files, which a BDD tool can execute as automated test cases.
Capture/playback: An automation approach that records manual interactions with the SUT and produces replayable test scripts; easy to start with but hard to maintain and scale.
CI/CD pipeline: A continuous integration / continuous delivery pipeline into which automated tests are integrated at different test levels, acting as quality gates and enabling unattended execution.
Clean code principles: Programming standards for test automation maintainability: meaningful naming, logical project structure, avoiding hardcoded values, keeping methods short, using logging, and applying design patterns.
Configuration management: Managing test environment configuration, test data, and test suites so that automation works reliably across multiple environments and SUT versions.
Contract testing: Integration testing that verifies services can communicate and that shared data follows an agreed contract; consumer-driven or provider-driven.
Controllability: A testability aspect: the SUT provides interfaces that let the test automation drive actions and control the SUT's state during testing.
Correlation ID: A unique identifier added to an interaction and propagated through subsequent calls, letting testers trace system behavior across logs when analyzing results.
Data-driven testing (DDT): An approach built on structured scripting where test scripts are fed test data from external sources (e.g. CSV files), so the same script runs with many data sets.
Failure recovery: A TAS capability to recover from a failure during test suite execution so testing can continue with the next test, including performing SUT recovery actions (e.g. reboot) when feasible.
Feature toggle: A configuration mechanism that determines which features are active per release or test environment, enabling the testware to select which test suites to execute on a given release.
Flow model pattern: An expansion of the page object model adding a facade that stores user actions interacting with page objects, improving abstraction and reuse of test steps.
Generic test automation architecture (gTAA): A high-level abstract design describing how test automation communicates with the SUT and with project, test, and configuration management, via the capabilities of test generation, definition, execution, and adaptation.
GUI testing: Automated testing through the graphical user interface, interrogating controls to read state and drive actions; sensitive to locator changes.
Keyword-driven testing (KDT): An approach where test cases are tables of test steps built from user-perspective keywords operating on test data, often layered on data-driven testing.
Linear scripting: Writing or modifying test scripts directly without custom test libraries; easy to begin but hard to maintain, scale, and evolve.
Measurement: Information recorded and logged before, during, and after test execution — supported by test-tool scripting languages — that feeds test reporting.
Metric: A measure derived from test automation data, such as the test success rate trend across runs, used in analysis and reporting.
Model-based testing: Generating test cases automatically from a test model; model-based testing tools can support the optional test-generation capability of a test automation architecture.
Observability: A testability aspect: the SUT provides interfaces that give insight into its internal state so that test cases can verify results.
Page object model: A design pattern that keeps each screen's locators and access logic in one class, so SUT structure changes require updating only the page model, not every test.
Pilot project: A short, scoped trial of test automation that evaluates programming languages, tools, test levels, selected test cases, and the development approach to set guidelines before full deployment.
Quality gate: A checkpoint in a pipeline where automated tests (e.g. component tests during the build) must pass for the build or deployment to proceed.
Risk: A factor in the future that could result in negative consequences for the test automation project; deployment risks include technical factors (packaging, logging, test structuring) and infrastructure factors (firewall openings, resource utilization).
Schema validation: Checking that an API response or database content matches its specified schema (mandatory elements, types, value rules) without writing individual assertions.
Self-healing: An AI/ML-based capability where tools detect changed UI locators using image recognition and automatically update selectors, fixing broken test cases and reporting the changed locators.
Static analysis: Inspecting test automation code with automated scans to identify vulnerabilities and defects, prioritize findings, and improve code quality.
Structured scripting: An automation approach that introduces test libraries with reusable elements, test steps, and user journeys, separating business logic from the test scripts.
System under test (SUT): The system that the test automation interacts with and evaluates — with or without a UI, including mobile apps, services, and protocols.
TAS failure: A failed test outcome whose cause lies in the test automation solution rather than the SUT; it should be defined clearly and reported distinctly from a genuine SUT failure.
Test adaptation layer: The part of a framework that provides adaptors to connect automated tests to the SUT via APIs, protocols, and services.
Test automation: Using purpose-built software tools to control and set up test suites, execute tests automatically, and compare actual results to expected results.
Test automation architecture (TAA): The technical design of a test automation solution, covering tool selection, components, connectivity, and integration with management systems.
Test automation engineer (TAE): The role responsible for designing, implementing, and maintaining a test automation solution, including selecting suitable test tools for the SUT.
Test automation framework (TAF): The foundation of a test automation solution: typically the test harness (runner) plus test libraries, test scripts, and test suites, often organized in layers.
Test automation solution (TAS): The complete realization of test automation for a project: the framework, testware, tools, and adaptors needed to automate the testing of the SUT.
Test environment: The systems, servers, and configuration on which the TAS is deployed; it must support repeatable, systematic setup and teardown across environments.
Test fixture: Items in the test harness that control the test environment and test data, defining preconditions and postconditions so automated tests are repeatable and atomic.
Test harness: The test runner and supporting items (e.g. fixtures) that must be available for automated tests to execute.
Test histogram: A visual report of test result data over time that reveals trends and helps identify fragile test cases worth refactoring.
Test intrusiveness: The degree to which a tightly coupled TAS alters the SUT's behavior during testing, potentially causing failures that do not occur in production and eroding confidence in the automation.
Test log: A chronological record of test execution — the test case run, start and end time, status, significant test steps, and SUT information — used to analyze defects in both the TAS and the SUT.
Test logging: The chronological recording of test execution information at severity levels (fatal, error, warn, info, debug, trace), providing audit trails for analyzing defects in the TAS and the SUT.
Test oracle: A source of expected results against which automated tests verify actual results; automation can only check outcomes a test oracle can interpret.
Test progress report (TAS): A published summary of automated test results, SUT information, and test environment documentation, tailored to management, operational, and technical stakeholders.
Test repeatability: The property that repeated execution of the same automated test always produces the same result; tests that fail intermittently should be isolated and analyzed separately.
Test script: Automation code that provides a test case repository and calls the business logic layer (test steps, user flows, API calls) — never the core libraries directly.
Test step: An individual action or verification within a test case; significant test steps are logged with timing so a failure can be traced to where it happened.
Test suite: A set of automated test cases or scripts executed together in a test run, managed and versioned as part of the test automation framework.
Test-driven development (TDD): A development approach where a failing test is written first, then code to satisfy it, then the code is refactored — the red, green, refactor cycle.
Testability: The degree to which the SUT supports testing, designed in via observability, controllability, and architecture transparency.
Testware: The work products created for testing — test scripts, test data, test suites, and libraries — which sit at the core of a test automation solution and can be enhanced to record information about their use.
Wait mechanism: A synchronization technique used in test automation: either a hard-coded fixed delay, a dynamic polling loop that checks for a state change with timeout, or an event-subscription with timeout.