Automation Testing · Glossary 2026

Automation Testing Glossary: 50 Terms You Must Know in 2026

SECTION 01Fundamentals (Terms 1–15)

These are the core concepts every automation tester must understand before touching a framework.

• 1. Test Automation: Using software tools to execute pre-scripted tests on an application automatically, without manual intervention.
• 2. Test Script: A set of coded instructions that performs actions on an application and verifies the expected result.
• 3. Test Suite: A collection of test cases or test scripts grouped together, usually by feature, module, or purpose.
• 4. Test Case: A specific scenario with defined inputs, steps, and expected outcomes that verifies a particular behaviour.
• 5. Assertion: A check that compares an actual result to an expected result. If they differ, the test fails.
• 6. Test Runner: The component that discovers, executes, and reports on test scripts. Examples: Jest, pytest, TestNG.
• 7. Test Pyramid: A model showing the ideal distribution of tests: many unit tests, fewer integration tests, and even fewer end-to-end tests.
• 8. Unit Test: A test that verifies a single function, method, or component in isolation.
• 9. Integration Test: A test that verifies how multiple components or services work together.
• 10. End-to-End (E2E) Test: A test that simulates a real user flow across the entire application, from UI to database.
• 11. Regression Test: A test that verifies existing functionality still works after a code change.
• 12. Smoke Test: A quick, shallow test that confirms the critical functionality of a build works before deeper testing.
• 13. Flaky Test: A test that sometimes passes and sometimes fails without any code change. The most common automation pain point.
• 14. Test Coverage: The percentage of code or functionality exercised by your test suite. Higher is not always better.
• 15. False Positive / False Negative: A false positive is a test that fails when the application is fine. A false negative is a test that passes when there is a real bug.

SECTION 02Frameworks (Terms 16–30)

These are the tools, patterns, and design concepts used to build maintainable automation.

• 16. Test Framework: A set of guidelines, tools, and libraries that structure how tests are written, run, and reported.
• 17. Selenium: The most widely used open-source tool for browser automation. Supports multiple languages and browsers.
• 18. Cypress: A JavaScript-based end-to-end testing framework with automatic waiting and time-travel debugging.
• 19. Playwright: Microsoft's cross-browser automation framework with auto-waiting, trace viewer, and parallel execution.
• 20. Locator: A selector that identifies an element on a web page. Examples: ID, CSS selector, XPath, role, test ID.
• 21. Page Object Model (POM): A design pattern where each page of the application is represented as a class, separating page structure from test logic.
• 22. Page Factory: A Selenium pattern that initialises page object elements automatically using annotations.
• 23. Auto-Waiting: A framework feature that waits for elements to be actionable before interacting — reducing flakiness without manual sleeps.
• 24. Explicit Wait: A wait that pauses execution until a specific condition is met, with a timeout.
• 25. Implicit Wait: A global wait applied to all element lookups, telling the driver how long to wait before throwing an error.
• 26. Fixture: A reusable setup or teardown block that provides test dependencies, like a browser session or database connection.
• 27. Data-Driven Testing: A pattern where the same test logic runs against multiple sets of input data.
• 28. Keyword-Driven Testing: A pattern where tests are defined as sequences of keywords, allowing non-programmers to write tests.
• 29. Behaviour-Driven Development (BDD): A collaboration approach where tests are written in plain language using Given / When / Then syntax. Tools: Cucumber, SpecFlow.
• 30. Test Doubles: Stand-in objects used in testing. Types include mocks, stubs, spies, fakes, and dummies.

SECTION 03CI/CD and data (Terms 31–42)

Modern automation runs in pipelines against realistic data. These terms cover that layer.

• 31. CI/CD: Continuous Integration and Continuous Delivery/Deployment. Automatically building, testing, and deploying code on every change.
• 32. Pipeline: A defined sequence of stages (build, test, deploy) that runs automatically when code changes.
• 33. Headless Browser: A browser that runs without a graphical interface, used for faster test execution in CI.
• 34. Parallel Testing: Running multiple tests simultaneously to reduce total execution time.
• 35. Test Sharding: Splitting a test suite across multiple machines or workers to run it faster.
• 36. Test Data: The input data used by tests. Managing it well is one of the hardest parts of automation.
• 37. Test Data Management (TDM): The practice of creating, masking, and provisioning realistic test data safely.
• 38. Mocking: Replacing a real dependency with a controlled fake, often to simulate API responses or external services.
• 39. Stubbing: Providing a fixed response to a specific call, usually simpler than full mocking.
• 40. Service Virtualisation: Simulating the behaviour of unavailable or costly dependencies, like third-party APIs or mainframes.
• 41. Contract Testing: Verifying that two services agree on the shape and behaviour of their API. Tools: Pact.
• 42. Test Report: The output of a test run, showing passed, failed, and skipped tests with details. Examples: JUnit XML, Allure.

SECTION 04AI and modern testing (Terms 43–50)

These are the newer terms shaping automation testing in 2026.

• 43. Self-Healing Tests: Tests that automatically update their locators when the UI changes, reducing maintenance.
• 44. Visual Regression Testing: Comparing screenshots of the UI against a baseline to detect unintended visual changes.
• 45. AI-Assisted Testing: Using AI tools to generate test cases, suggest locators, or predict high-risk areas of change.
• 46. Test Impact Analysis: Determining which tests need to run based on the code that changed, to speed up pipelines.
• 47. Chaos Testing: Deliberately introducing failures to verify system resilience — used in distributed systems.
• 48. Synthetic Monitoring: Running automated tests against production at intervals to catch issues before users report them.
• 49. Observability-Driven Testing: Using production telemetry (logs, traces, metrics) to inform what to test and where failures occur.
• 50. Shift-Left Testing: Moving testing earlier in the development lifecycle — writing tests alongside code, not after.

Pro tip: Mention self-healing tests and shift-left testing in interviews. They show you understand where the industry is heading.

SECTION 05How to use these terms in interviews

Knowing the terms is not enough. You need to use them correctly and confidently.

• Explain, don't define: Instead of reciting a definition, describe how you have used the concept. "Our suite was flaky, so we added auto-waiting and replaced CSS selectors with test IDs."
• Connect terms to outcomes: Link terminology to business value. "Parallel testing cut our pipeline from 45 minutes to 8 minutes."
• Show depth on one or two terms: Going deep on test doubles or the test pyramid beats shallow coverage of ten terms.
• Be honest about gaps: If you have not used chaos testing in production, say so and explain what you understand about it.
• Use the right term: Saying "mock" when you mean "stub" reveals gaps. Precision matters.
• Ask questions back: "How does your team handle test data management?" shows you think in terms of practice, not just vocabulary.

SECTION 06Common terminology mistakes

These mix-ups are common — and they cost candidates interviews.

• Confusing mocks and stubs: A stub returns a fixed value. A mock also verifies that it was called correctly.
• Saying "test case" when you mean "test script": A test case is a scenario. A test script is the code that automates it.
• Mixing up implicit and explicit waits: Implicit waits apply globally. Explicit waits target specific conditions.
• Calling all tests "unit tests": Unit, integration, and E2E tests are different layers with different purposes.
• Confusing CI and CD: CI is integration (build and test). CD is delivery or deployment (release to environments).
• Using "regression suite" and "smoke suite" interchangeably: Smoke tests are quick and shallow. Regression tests are broad and deep.
• Thinking test coverage equals quality: 100% coverage with weak assertions still misses bugs.

SECTION 07Quick reference table

Here is the full list in one place for quick revision.

SECTION 08Test yourself — Automation Testing Terms

SECTION 09Frequently asked questions

SECTION 10Related reads