QA Testing Terminology Glossary for SDET Interviews 2026 — The Complete Reference Guide to Speaking the Language of Testing Fluently: Every Term, Acronym, and Concept You Need to Define on the Spot, The Differences Between Commonly Confused Terms That Interviewers Test Deliberately, How to Explain Testing Concepts Like a Senior Engineer (Not a Textbook), Red-Flag Terminology Mistakes That Cost Candidates Offers, and 20 Years of Watching Testing Language Evolve from V-Model to AI-Driven Quality
The definitive QA testing terminology glossary for SDET interviews in 2026. Nothing exposes a candidate faster than fumbling a basic term — and nothing signals competence faster than defining one clearly, concisely, and in your own words. Mitchell Agoma has spent 20 years in software testing across HMRC, the Ministry of Defence, Nationwide Building Society, and Accenture — environments where terminology precision wasn't academic, it was the difference between a production defect caught and a regulatory breach missed. This reference guide organises every testing term you might be asked to define in an SDET interview by category: test types, test levels, automation terms, CI/CD terminology, performance concepts, security vocabulary, and accessibility jargon. It decodes the acronyms that populate SDET job descriptions — TDD, BDD, DDT, ATDD, POM, CI/CD, SUT, AUT, E2E, UAT, SLA, SLO, SLI. It walks through the commonly confused term pairs that interviewers use as litmus tests: verification vs validation, quality assurance vs quality control, smoke vs sanity, retesting vs regression, stub vs mock vs fake vs spy. It teaches the 'explain to a junior developer' framework for answering terminology questions in a way that demonstrates senior-level communication — the single skill that most reliably separates offers from rejections in behavioural and technical rounds. It catalogues the red-flag terminology mistakes that lose interviewers within the first five minutes, and it includes Mitchell's personal perspective on the terms that have changed meaning over two decades in the industry. With 8 detailed FAQs and downloadable structure, this is the glossary you read the night before your interview — and refer back to throughout your SDET career. The SDET Interview Coach iOS app includes a dedicated terminology drill module that quizzes you on definitions, acronyms, and confused-term differentiation with AI-powered feedback — so you walk into the interview knowing exactly what every term means and how to explain it like someone who's been doing this for years.
Published 3 June 2026 • By Mitchell Agoma
Here is a moment every SDET candidate dreads. The interviewer leans forward, pauses, and asks: "Can you explain the difference between verification and validation?" It's a simple question. Two terms. One sentence each. And yet — in the pressure of an interview, when your brain is already spinning through the framework design question you just answered and the coding problem you know is coming next — a surprising number of candidates freeze, conflate the two, or deliver a textbook definition so dry and memorised that the interviewer mentally checks out before the second sentence. This is the hidden power of terminology questions in SDET interviews: they look easy, which makes stumbling on them disproportionately damaging. If you can't define verification and validation clearly, what else don't you know? If you confuse smoke testing and sanity testing — two foundational quality gates — can you be trusted to design a test strategy? If you call every test double a "mock" without understanding the distinctions, have you actually worked in a serious test automation environment, or have you just watched tutorials? Terminology precision is not pedantry. It is the quickest signal interviewers have for assessing whether you understand the discipline of software testing, or whether you've just learned the syntax of a test framework.
Mitchell Agoma has spent 20 years in environments where terminology precision had real-world consequences: at HMRC, where confusing verification and validation in a tax processing system could mean incorrect tax calculations for millions of citizens; at the Ministry of Defence, where calling a security test "done" after only static analysis — while skipping dynamic penetration testing — was a career-limiting move; at Nationwide Building Society, where distinguishing between retesting and regression testing determined whether a payment bug fix was actually verified or whether related functionality was silently broken; and at Accenture, where consulting across client engagements meant speaking the precise testing language of financial services, telecommunications, and government — sometimes in the same week. The terminology you use in an interview doesn't just demonstrate knowledge. It demonstrates that you've operated in environments where precision mattered. This glossary is organised for interview preparation, not academic reference. Every term is defined the way you should define it in an interview — clearly, concisely, with context, and in your own words. If you're preparing for an SDET interview, pair this glossary with the SDET Interview Coach iOS app, which includes a dedicated terminology drill module that quizzes you on definitions, acronyms, and confused-term differentiation with AI-powered feedback calibrated to interview expectations at every seniority level.
Why Terminology Questions Are Interview Litmus Tests — And Why Candidates Underestimate Them
Most candidates prepare for coding challenges and system design questions. Almost nobody prepares for terminology questions. This is why interviewers love them — they separate candidates who have studied testing from candidates who have practised testing. The distinction matters because in production environments, terminology precision is not academic. It's operational. Here's what interviewers are actually evaluating when they ask you to define a term:
1. Precision Under Ambiguity — Can You Draw Clear Lines?
When an interviewer asks "What's the difference between smoke testing and sanity testing?", they're not just testing whether you've memorised two definitions. They're testing whether you can draw a clear, practical distinction between two concepts that overlap in many people's minds. This skill — precise differentiation — is the same skill you need when writing a bug report that distinguishes between a test environment issue and an application defect, or when explaining to a product manager why a specific edge case isn't covered by existing test coverage. Candidates who say "they're basically the same thing" or "smoke testing is just a quick sanity check" have just signalled that they either don't know, or don't value precision — both of which are dealbreakers at senior levels. Candidates who say "smoke testing verifies that the critical paths of a build are working — can the application start, can users log in, can a basic transaction complete. Sanity testing is narrower: it verifies that a specific bug fix or feature change works as expected without testing the full system" have just demonstrated the kind of operational clarity that senior SDETs bring to release decisions.
2. Communication Range — Can You Explain Complex Ideas Simply?
The best SDETs are not just technically proficient — they are communicators who can explain testing concepts to developers, product managers, business stakeholders, and junior team members at the appropriate level of detail for each audience. Terminology questions in interviews test exactly this: can you take a technical concept and explain it clearly? Candidates who recite dictionary definitions word-for-word signal that they've memorised, not understood. Candidates who say "Let me give you an example..." and use a concrete scenario signal that they've internalised the concept. Mitchell's rule from 20 years of interviewing: the candidate who can explain a technical term to a hypothetical junior developer — without jargon, with a concrete example, and in under 90 seconds — gets hired more often than the candidate with the deeper technical knowledge who can't communicate it. The SDET Interview Coach app includes behavioural interview modules that specifically train this skill — asking you to explain testing concepts to different audiences and scoring your communication clarity.
3. Experience Depth — Have You Actually Done This, or Just Read About It?
Terminology questions have a unique property: they expose whether your knowledge comes from practice or from study. A candidate who has only read about test doubles will say "A mock is a simulated object that returns predefined responses." A candidate who has actually used test doubles in anger will say "A mock is for behaviour verification — you assert that specific methods were called with specific arguments. I use them when I need to verify that my code interacts with a dependency correctly, not just that it uses the dependency's return value. For example, when testing a payment service, I mock the email notification service to verify that a confirmation email was triggered — I don't care about the email content, I care that the trigger happened." The second answer is richer because it's grounded in real decisions — "when do I use this versus that" is the experience marker. Interviewers hear this immediately. It's the difference between someone who has consumed testing content and someone who has produced testing results.
4. Industry Awareness — Do You Know How the Language Is Evolving?
Testing terminology evolves. Terms that meant one thing in 2010 mean something different — or more nuanced — in 2026. "Shift-left testing" used to mean "test earlier in the development cycle." Now it encompasses developer-owned testing, contract testing in CI, and quality gates at the pull-request level. "Test automation" used to mean "automated regression suites." Now it includes self-healing tests, AI-generated test cases, visual regression testing, and continuous testing in deployment pipelines. When an interviewer asks you to define a term, they're also testing whether your understanding is current — or frozen at whatever year you last studied testing formally. Candidates who define "BDD" as "writing Gherkin scenarios" are giving a 2018 answer. Candidates who talk about BDD as a collaboration practice that uses concrete examples to build shared understanding between business, development, and testing — with Gherkin as just one possible tool for capturing those examples — are giving a 2026 answer. The distinction sounds subtle on paper. In an interview, it's the difference between mid-level and senior.
The good news: terminology questions are among the highest-ROI areas to prepare because the knowledge you need is finite and learnable. There are roughly 80-100 terms that an SDET at mid-to-senior level should be able to define clearly. That's manageable with a few evenings of focused study. The SDET Interview Coach app makes this prep systematic — drilling you on terms, tracking which ones you've mastered, and using spaced repetition to ensure they're in long-term memory by interview day.
Part 1 — Test Types: The Categories Every SDET Must Be Able to Define
Test types describe what you're testing — the quality attribute or characteristic under examination. Interviewers expect you to know these cold, because test type classification is the foundation of test strategy: you can't plan testing if you can't articulate what kinds of testing are needed for a given system. Here are the essential test types, with interview-ready definitions.
Functional Testing
What it is: Testing that verifies the system behaves according to specified functional requirements — given input X, the system produces output Y. Functional testing answers the question: does the system do what it's supposed to do? Examples: testing that a login form accepts valid credentials and rejects invalid ones, testing that a shopping cart correctly calculates totals with discounts and taxes, testing that an API endpoint returns the correct HTTP status code and response body for each defined input. Interview tip: When defining functional testing, always contrast it with non-functional testing — it shows you understand the full testing landscape, not just one corner of it. The SDET Interview Coach terminology module drills exactly this kind of paired-definition recall.
Non-Functional Testing
What it is: Testing that verifies how the system behaves — its quality attributes rather than its specific functions. This includes performance (how fast?), load (how many users?), stress (what's the breaking point?), security (how safe?), usability (how intuitive?), reliability (how stable over time?), and scalability (how does it grow?). Non-functional testing answers the question: does the system do what it's supposed to do, well enough, under realistic conditions? Interview tip: When asked about non-functional testing in an SDET interview, be ready to discuss at least three non-functional categories in depth — performance, security, and accessibility are the highest-frequency interview topics. For a deep dive on all three, see our dedicated guides on non-functional testing interview questions, security testing interview questions, and accessibility testing interview questions.
Regression Testing
What it is: Testing that verifies existing functionality still works correctly after a change — a code modification, a configuration update, a dependency upgrade, or an environment change. Regression testing answers the question: did we break anything that was already working? This is the bread and butter of test automation: automated regression suites run on every commit, pull request, or deployment to catch unintended side effects quickly. Interview tip: Interviewers frequently ask you to distinguish between retesting and regression testing — retesting verifies that a specific bug fix works (narrow), regression testing verifies that nothing else broke (broad). Candidates who conflate the two lose credibility fast. See the "commonly confused terms" section below for the full differentiation.
Smoke Testing
What it is: A shallow, broad set of tests that verify the critical functionality of a build is working — enough to determine whether the build is stable enough for further, more thorough testing. Also called "build verification testing" or "confidence testing." Smoke testing answers the question: is this build worth testing further, or is it fundamentally broken? If smoke tests fail, the build is rejected — no further testing occurs. Interview tip: The metaphor: when you turn on a new piece of electronics and smoke comes out, you don't bother testing whether the volume knob works. Smoke testing catches the "catches fire" problems before you invest in detailed testing. Mitchell has seen builds rejected at the smoke test stage at HMRC because a database migration script failed — there was no point running 5,000 regression tests when the application couldn't even start. That's the operational value of smoke testing that interviewers want to hear.
Sanity Testing
What it is: Narrow, focused testing that verifies a specific bug fix or feature change works correctly — without running the full regression suite. Sanity testing answers the question: does this specific change work as expected, and is the application stable enough to proceed with more thorough testing? It's shallower than full regression but more focused than smoke testing. Interview tip: The key differentiator: sanity testing is performed after a specific change, smoke testing is performed on a new build regardless of what changed. If an interviewer presents a scenario — "A developer just fixed a critical payment bug; what testing do you do before deploying?" — sanity testing is the correct initial answer: verify the fix, then run a targeted regression around the payment module.
Integration Testing
What it is: Testing that verifies the interaction between two or more components, modules, or systems works correctly. Integration testing answers the question: do these pieces work together? Examples: testing that a frontend correctly calls a backend API and handles the response, testing that a service correctly reads from and writes to a database, testing that a payment service correctly communicates with a third-party payment gateway. Interview tip: In a microservices world, integration testing has become layered: component integration (within a service), service integration (between services), and system integration (end-to-end across the full system). Senior candidates can discuss which integration layer to test at for different risk profiles.
Unit Testing
What it is: Testing individual units of code — typically functions, methods, or classes — in isolation from their dependencies. Unit testing answers the question: does this specific piece of code do what it's supposed to do, independent of everything around it? Unit tests are typically written by developers (not SDETs), but SDETs need to understand them because test automation strategies are built on the testing pyramid — and the pyramid's foundation is unit tests. Interview tip: SDETs who can discuss unit testing intelligently — not just acknowledge it exists — differentiate themselves. Know the difference between solitary unit tests (isolated with mocks) and sociable unit tests (testing several units together without external dependencies).
End-to-End (E2E) Testing
What it is: Testing that verifies a complete user workflow from start to finish, across all layers of the application — frontend, backend, database, and external integrations. E2E testing answers the question: does the whole system work together to deliver the user's goal? Example: testing that a user can browse products, add to cart, enter payment details, complete purchase, and receive a confirmation email — all through the actual UI. Interview tip: E2E tests are powerful but expensive — they're slow, brittle, and hard to debug. Senior SDETs discuss the trade-off explicitly: E2E tests should cover critical user journeys (login, checkout, core workflows) but not every possible path. The testing pyramid principle — many unit tests, fewer integration tests, fewest E2E tests — is interview table stakes.
User Acceptance Testing (UAT)
What it is: Testing performed by end users or business stakeholders to verify that the system meets their needs and is ready for production. UAT answers the question: does this system solve the user's actual problem, in the way they expect? UAT is typically manual, scenario-based, and performed in a staging or pre-production environment. Interview tip: UAT is not the SDET's responsibility to perform — but the SDET's automation work should support UAT by ensuring that the build reaching UAT is stable and free of known defects. The phrase "our automation suite gates the build before UAT" signals operational maturity.
Exploratory Testing
What it is: Simultaneous learning, test design, and test execution — testing without predefined scripts, where the tester's observations during testing inform what to test next. Exploratory testing answers the question: what unexpected behaviours, edge cases, or usability issues exist that scripted testing wouldn't find? Interview tip: Exploratory testing is not "random clicking" and calling it that in an interview is a red flag. It's structured by charters (time-boxed testing missions with specific focus areas), and findings are documented with session-based test management. Even in highly automated environments, exploratory testing catches issues that scripts never would — and senior SDETs acknowledge its value rather than positioning automation as a replacement for all manual testing.
Part 2 — Test Levels: The Testing Pyramid, Trophy, and Beyond
Test levels describe where testing happens in the application architecture — from isolated code units to full-system workflows. Interviewers test your understanding of test levels because it reveals whether you can design a balanced test strategy, not just write scripts at one level.
The Testing Pyramid
The classic model: many fast, cheap unit tests at the bottom; fewer, slower integration tests in the middle; even fewer, slowest E2E tests at the top. The pyramid principle is about investment allocation: put your testing effort where tests are fastest to run, cheapest to maintain, and most precise about failures. Interview tip: In 2026, the pyramid is still valid as a principle but has been refined — for microservices, the "testing trophy" (emphasising integration tests) and the "testing honeycomb" (emphasising integrated tests that cross service boundaries) are alternative models worth knowing. Naming these alternatives shows breadth. For more depth on test strategy, see our guide on test strategy and planning interview questions.
API / Service Layer Testing
Testing at the API layer — verifying that REST endpoints, GraphQL queries, or gRPC services return correct responses, handle errors gracefully, and respect contracts. API tests are faster and more stable than UI tests, making them the sweet spot for automation coverage. Interview tip: In modern SDET roles, API testing is often the largest category of automated tests — it's where you get the best ROI: fast execution, deterministic results, and coverage of business logic without UI brittleness. For comprehensive API testing preparation, see our API testing interview questions guide.
UI / GUI Testing
Testing through the user interface — verifying that UI elements render correctly, user interactions produce expected outcomes, and the visual layer integrates correctly with backend services. UI tests are the most realistic but also the slowest, most brittle, and most expensive to maintain. Interview tip: The modern SDET approach: push as much verification as possible to the API layer, keep UI tests minimal and focused on critical user journeys, and use tools like Playwright's auto-waiting, locator strategies, and trace viewer to manage UI test brittleness.
Database / Data Layer Testing
Testing at the database layer — verifying data integrity, schema correctness, migration safety, stored procedure logic, and data transformation accuracy. Interview tip: SDETs who can discuss database testing beyond "we checked the data was saved" stand out. Talk about: verifying data integrity constraints (foreign keys, unique constraints), testing migration scripts (both forward and rollback), testing data transformations in ETL pipelines, and validating that test data factories produce valid, referentially intact data. For comprehensive database testing interview prep, see our SQL and database testing interview questions.
Part 3 — Test Automation Terminology: The Vocabulary of Automated Testing
This is the core vocabulary of the SDET role — the terms you'll use every day and the terms interviewers expect you to use precisely.
Test Automation Framework
A structured set of guidelines, tools, libraries, and coding standards that support automated test creation, execution, and reporting. A framework is not a tool — it's the architecture that organises how you use tools. Components typically include: test runner, assertion library, reporting mechanism, test data management, configuration management, and CI/CD integration. Interview tip: When asked about frameworks, don't just name tools ("I use Playwright"). Describe the architecture: how you structure test code, how you manage test data, how you handle configuration across environments, how you integrate with CI. See our test automation framework design interview guide for the complete framework design interview preparation.
Page Object Model (POM)
A design pattern where each web page or component is represented as a class, encapsulating the page's elements (locators) and actions (methods). POM separates test logic from page structure — when the UI changes, you update the page object, not every test. Interview tip: In 2026, the expectation has evolved from "I use POM" to "I use component-based POM with small, reusable abstractions for shared UI elements" — nav bars, modals, search components are modelled once and reused. Discuss anti-patterns: the "god page object" with hundreds of methods, hard-coded data in page objects, and sleep-based waits.
Screenplay Pattern
An alternative to POM that models tests as user journeys composed of actions (tasks) performed by actors (users with specific abilities). Screenplay emphasises composition over inheritance — you build tests by combining small, reusable task objects rather than inheriting from page classes. Interview tip: Mentioning the Screenplay pattern in an interview — especially if you can explain when you'd choose it over POM (complex workflows with many shared steps, scenarios where different user roles perform different actions on the same page) — signals awareness beyond the most common pattern.
Locators / Selectors
The mechanisms used to find and interact with elements on a page — CSS selectors, XPath, text content, roles, test IDs, and data attributes. Interview tip: A locator strategy question is almost guaranteed in any UI automation interview. The gold-standard answer: prefer data-testid or dedicated test attributes (they're stable across UI redesigns), then role-based selectors (accessible by default), then text content (for user-visible labels), then CSS selectors, and use XPath only as a last resort. For Playwright specifically: its locator API supports all of these and automatically waits for elements to be actionable — which changes the locator strategy compared to Selenium.
Waits — Explicit, Implicit, and Fluent
Implicit wait: A global timeout applied to every element lookup — the driver waits up to N seconds for an element to appear before throwing an error. Explicit wait: A targeted wait for a specific condition on a specific element — wait until element is visible, clickable, or contains specific text. Fluent wait: An explicit wait that polls at a defined interval and can ignore specific exceptions during polling. Interview tip: Modern frameworks (Playwright, Cypress) have largely eliminated manual wait management with auto-waiting — but interviewers still ask this question to test whether you understand the problem that auto-waiting solves. Don't just say "Playwright handles waits automatically" — explain why waits are necessary (asynchronous rendering, network latency, animations) and how auto-waiting works (actionability checks: attached, visible, stable, enabled, not covered by other elements).
Visual Regression Testing
Automated comparison of screenshots of the application UI against baseline images to detect unintended visual changes — layout shifts, styling regressions, missing elements. Interview tip: Visual regression testing tools (Percy, Chromatic, Playwright's built-in screenshot comparison) catch visual bugs that functional tests miss — a button that still works but has moved off-screen, a form that functions but has broken CSS. For deep preparation, see our visual regression testing interview questions.
Data-Driven Testing (DDT)
A testing approach where test logic is separated from test data — the same test script runs multiple times with different input data sets, each producing independent results. Interview tip: DDT is interview table stakes. The nuanced discussion: how to structure test data (external files vs inline vs factory functions), how to handle test data that requires specific states (database seeding, API preconditions), and how to avoid the anti-pattern of data-driven tests that become unmaintainable because the data and logic are too tightly coupled. The SDET Interview Coach app includes coding challenges that test exactly this — separating data from logic cleanly.
Keyword-Driven Testing
A testing approach where tests are written as sequences of keywords (high-level actions like "login", "search", "addToCart") mapped to automation code. Keywords abstract away the implementation details, allowing non-programmers to create or modify tests. Interview tip: Keyword-driven testing was popular in the 2010s (especially with tools like Robot Framework and Katalon). In 2026, it's less dominant but still appears in enterprise contexts and legacy frameworks. Know it, but also know its limitations: keyword libraries become large and unwieldy, and complex logic is awkward to express in keyword sequences. BDD with Gherkin has largely replaced keyword-driven testing for business-readable tests.
Self-Healing Tests
Tests that automatically adapt to minor UI changes — when a locator breaks because an element's ID changed, a self-healing mechanism uses AI or heuristics to find the element via alternative attributes and update the locator for future runs. Interview tip: Self-healing is a hot topic in 2026. Tools like Healenium, Testim, and some AI-augmented platforms offer self-healing. The nuanced interview answer: self-healing reduces maintenance but shouldn't mask genuine test failures — a self-healing test that silently finds the wrong element is worse than a failing test that clearly signals a problem. Always pair self-healing with human review of locator changes.
Parallel Test Execution
Running multiple tests simultaneously across different browser instances, devices, or machines to reduce overall execution time. Interview tip: Parallel execution is not just a configuration checkbox — it requires test design that supports parallelism: tests must be independent (no shared state), test data must be isolated (unique per parallel worker), and resource contention (database connections, file system access) must be managed. The phrase "we achieved a 60% reduction in suite execution time through parallelisation after refactoring test data to be worker-isolated" is the kind of quantified result that impresses interviewers.
Part 4 — Test Doubles: Stubs, Mocks, Fakes, Spies, and Dummies
This is the terminology cluster that most reliably separates candidates who've done serious test automation from those who've watched tutorials. Interviewers at mid-level and above will ask you to differentiate between test doubles. Here they are, with the distinctions that matter.
Stub
Definition: A test double that provides pre-programmed responses to calls made during the test — it returns what you tell it to return, nothing more. Stubs are used for state verification: you check that the system under test behaves correctly given the stub's responses. Example: A stub for a payment gateway's "charge" method that always returns {"status": "success", "transactionId": "txn_123"}. When to use: When you need to control the SUT's input to test a specific code path — you don't care whether the method was called, you care what the SUT does with the response.
Mock
Definition: A test double that records the calls it receives and lets you assert that specific methods were called with specific arguments and a specific number of times. Mocks are used for behaviour verification: you check that the SUT interacted with its dependency correctly. Example: A mock email service where you verify that sendConfirmationEmail(userId, orderId) was called exactly once after a purchase. When to use: When the interaction itself is what you need to verify — the SUT should trigger a specific side effect, send a specific notification, or log a specific event.
Fake
Definition: A lightweight, working implementation of a dependency that's unsuitable for production but adequate for testing. Fakes have real behaviour — they actually do something — but they take shortcuts (in-memory database instead of a real one, simple in-memory queue instead of Kafka). Example: An in-memory repository that stores entities in a HashMap instead of a real database, implementing the full repository interface. When to use: When you need the dependency to have real behaviour for the test to be meaningful, but using the real dependency would make the test too slow, flaky, or hard to set up.
Spy
Definition: A test double that wraps a real object and records calls to it — you can later inspect what was called, with what arguments, and how many times. Spies are like mocks on top of real objects: the real behaviour still happens, but you also get call recording. Example: A spy on a real logging service that lets you verify that logError() was called with a specific message, while the actual logging still writes to the log file. When to use: When you want the real object's behaviour but also need to verify interactions — often used to verify that side effects happened without replacing the side-effect-producing component entirely.
Dummy
Definition: An object that's passed but never actually used — it exists only to satisfy parameter requirements. Dummies are the simplest test double: they fill a parameter slot and nothing more. Example: A dummy User object passed to a constructor that requires a User parameter but the method under test never accesses any user fields. When to use: When a method signature requires an argument that's irrelevant to the specific test case — the dummy is a signal that "this parameter doesn't matter for this test."
🎯 Mitchell's Interview Observation: The Test Double Litmus Test
In Mitchell's experience interviewing SDETs at all levels, the test double question reveals three candidate types. Type 1 (Junior): "A mock is when you simulate something" — conflates all test doubles under one term. Type 2 (Mid-level): Can define stub vs mock correctly (state vs behaviour verification) but can't distinguish fake from stub. Type 3 (Senior): Can define all five, explain when to use each, and — critically — knows the testing philosophy that "over-mocking leads to tests that verify mock behaviour rather than actual system behaviour, creating a false sense of security." The Type 3 answer wins offers at senior level. The SDET Interview Coach app includes terminology differentiation drills that specifically test these distinctions, with AI feedback that evaluates whether your definitions are memorised or internalised.
Part 5 — Essential SDET Acronyms Decoded
SDET interviews and job descriptions are dense with acronyms. You don't just need to know what they stand for — you need to understand what they mean operationally and be able to discuss them in context. Here are the acronyms that appear most frequently, with definitions that demonstrate practical understanding.
TDD — Test-Driven Development
What it stands for: Writing a failing test before writing the production code that makes it pass, then refactoring. The cycle: Red (failing test) → Green (minimal code to pass) → Refactor (improve code without changing behaviour). Interview context: TDD is primarily a developer practice, but SDETs need to understand it because: (1) you may coach developers on TDD practices in a quality-enablement role, (2) you may be asked to write tests in a TDD style for test utilities and frameworks, and (3) it comes up when discussing test-first vs test-after approaches. For deep TDD/BDD interview prep, see our TDD and BDD methodology interview questions guide.
BDD — Behaviour-Driven Development
What it stands for: A collaborative practice where concrete examples of system behaviour are used to build shared understanding between business, development, and testing. Typically expressed in Given-When-Then format. Interview context: In 2026, BDD is understood as a collaboration practice, not a testing tool. Gherkin (the Given-When-Then syntax) and Cucumber/SpecFlow/Behave (the automation tools) are implementations of BDD, not BDD itself. A 2026 answer: "BDD is about using concrete examples to build shared understanding before anyone writes code. Gherkin is the syntax we use to capture those examples. Cucumber is the tool that automates them. The value is primarily in the conversation, not the automation." For more, see our BDD and Cucumber interview questions guide.
DDT — Data-Driven Testing
What it stands for: Separating test logic from test data so the same test can run with multiple data sets. Interview context: Covered in detail in the automation terminology section above. The acronym is worth knowing because it appears in job descriptions and technical discussions.
ATDD — Acceptance Test-Driven Development
What it stands for: A practice where acceptance criteria are defined as automated tests before development begins — the entire team (business, development, testing) collaborates to define what "done" looks like as executable specifications. Interview context: ATDD bridges BDD and TDD: it uses BDD-style collaborative specification to create acceptance tests, which then drive TDD-style development. ATDD is less commonly asked about than TDD or BDD, but knowing it — and how it relates to both — demonstrates awareness of the broader testing methodology landscape.
POM — Page Object Model
What it stands for: A design pattern where web pages are modelled as classes with locators and action methods. Interview context: Covered in the automation terminology section above. This acronym appears in virtually every SDET job description that mentions UI automation.
CI/CD — Continuous Integration / Continuous Delivery (or Deployment)
What it stands for: CI: automatically building and testing code changes when they're merged into a shared repository. CD: automatically deploying tested code to staging (Continuous Delivery) or production (Continuous Deployment). Interview context: SDETs must understand CI/CD because automated tests run in CI/CD pipelines — you need to know how to configure test execution, interpret CI results, and debug CI-only failures. For comprehensive CI/CD interview preparation, see our CI/CD pipeline testing interview questions guide.
SUT — System Under Test
What it stands for: The specific system, application, or component being tested. Interview context: This is a precision term — it distinguishes the thing you're testing from the things you're using to test it (test framework, test data, test doubles). Using "SUT" in your answers — "the SUT's response time degraded under load" rather than "the application slowed down" — signals professional testing vocabulary.
AUT — Application Under Test
What it stands for: Synonymous with SUT — the application being tested. Interview context: AUT and SUT are largely interchangeable, but some organisations distinguish them: AUT for the entire application, SUT for a specific component or service. In practice, don't stress about the distinction — using either consistently demonstrates familiarity with testing vocabulary.
E2E — End-to-End Testing
What it stands for: Testing a complete workflow across all system layers. Interview context: Covered in the test types section above. The acronym is worth emphasising because it appears constantly in discussions about test strategy, test pyramid, and automation scope. For cross-browser E2E specifics, see our cross-browser testing interview questions.
UAT — User Acceptance Testing
What it stands for: Testing performed by end users to verify the system meets their needs. Interview context: Covered in the test types section above.
SLA / SLO / SLI — Service Level Agreement / Objective / Indicator
SLI (Service Level Indicator): The actual measurement — e.g., "99.95% of API requests returned in under 200ms last month." SLO (Service Level Objective): The target — e.g., "99.9% of API requests must return in under 200ms." SLA (Service Level Agreement): The contractual promise to customers, with consequences for breach — e.g., "99.5% uptime, with service credits for violations." Interview context: These terms appear in SDET interviews at senior and lead levels, especially for roles involving observability, monitoring, and production quality. The hierarchy is: SLI measures reality, SLO sets the internal target, SLA makes the external promise. SLOs should be stricter than SLAs — you set internal targets above contractual promises to give yourself a buffer. For deeper monitoring and observability interview prep, see our monitoring and observability for SDET interviews guide.
Part 6 — Commonly Confused Terms: The Differentiation Questions That Interviewers Use as Litmus Tests
These are the term pairs where the distinction is subtle enough that candidates routinely conflate them — making them ideal interview litmus tests. For each pair, memorise not just the definitions but the operational distinction — the difference that matters in practice.
Verification vs Validation
Verification: Are we building the product right? This is about checking that the software conforms to its specifications — reviews, inspections, static analysis, unit tests that check code against design. Verification can be done without running the software (static testing). Validation: Are we building the right product? This is about checking that the software meets the user's actual needs — UAT, beta testing, usability testing with real users. Validation requires running the software and observing real user behaviour. The mnemonic: "Verification = specification. Validation = expectation." The operational difference: You can verify software perfectly against a specification that describes the wrong product — verification alone isn't enough. You can validate software that users love but that's riddled with specification violations — validation alone isn't enough. You need both. Mitchell learned this at the Ministry of Defence: a system passed every specification-based test (verification) but failed operational exercises because the specifications didn't capture real battlefield scenarios (validation failure). The system was verified but not validated — and the distinction nearly had operational consequences.
Quality Assurance (QA) vs Quality Control (QC)
Quality Assurance: Process-oriented — ensuring that the processes used to build software will produce quality. QA is proactive: defining coding standards, establishing review processes, implementing CI/CD gates, designing test strategies before development starts. QA answers: "Are we doing the right things to build quality in?" Quality Control: Product-oriented — checking that the product meets quality standards. QC is reactive: running tests, reviewing code, inspecting deliverables. QC answers: "Does this specific thing meet our quality bar?" The operational difference: QA is about preventing defects (process improvement). QC is about detecting defects (product inspection). A team that only does QC (testing) without QA (process improvement) finds the same defects release after release. A team that only does QA without QC doesn't know if their processes actually work. Interview nuance: The job title "QA Engineer" is technically a misnomer for most SDET roles — most "QA" roles are primarily QC roles. Acknowledging this in an interview shows you understand the discipline beyond the job title. Mitchell's perspective: the title "QA" has stuck because of industry inertia, but in practice, most testing professionals do more QC than QA. The SDET Interview Coach app includes terminology questions that specifically test these nuanced distinctions — the kind of depth that separates senior from mid-level answers.
Smoke Testing vs Sanity Testing
Smoke Testing: Broad but shallow — a quick check that the critical paths of a build work. Performed on every build to determine if it's stable enough for further testing. Think: "Can the application start? Can users log in? Can a basic transaction complete?" Sanity Testing: Narrow and focused — a quick check that a specific fix or feature change works. Performed after a change to determine if it's worth running the full regression suite. Think: "Does this specific bug fix work? Does this specific feature behave correctly?" The operational difference: Smoke testing is build-gating: fail → reject the build, don't test further. Sanity testing is change-gating: fail → the fix wasn't right, don't waste time on full regression for this change. The mnemonic: "Smoke = is the build on fire? Sanity = is this specific change sane?" Interview tip: This is the single most commonly confused pair in SDET interviews. Mitchell estimates 40-50% of candidates at mid-level conflate these two or define them imprecisely. Getting this pair right — with clear operational distinctions and examples — is one of the highest-ROI terminology preparations you can do.
Retesting vs Regression Testing
Retesting: Testing a specific bug fix to verify that the reported defect has been resolved — you run the exact steps that previously reproduced the bug and confirm the bug no longer occurs. Retesting is narrow: one fix, one verification. Regression Testing: Testing unchanged functionality to verify that the bug fix (or any other change) didn't break existing features. Regression testing is broad: many tests, many features, many paths. The operational difference: Retesting confirms the fix. Regression testing confirms nothing else broke because of the fix. Both are necessary before a bug can be marked as resolved. Interview tip: When a bug is fixed, the minimum testing protocol is: retest the fix (did we fix the right thing?), then run regression tests around the affected area (did we break anything?), then — if the fix touched shared code or infrastructure — run the broader regression suite. Candidates who articulate this three-step protocol demonstrate operational testing maturity.
Defect vs Bug vs Error vs Failure
Error (or Mistake): The human action that produces an incorrect result — a developer writes if (x = 5) instead of if (x == 5). Errors happen in the developer's mind or code. Defect (or Bug or Fault): The manifestation of the error in the code — the assignment-instead-of-comparison that exists in the source code. Defects exist in the product. Failure: The observable deviation from expected behaviour — the program behaves incorrectly because of the assignment bug. Failures are what users see and what tests detect. The chain: Error (human mistake) → Defect (code flaw) → Failure (observed wrong behaviour). Not all errors become defects (caught during development), not all defects cause failures (code path never executed), and not all failures are caused by defects (environment issues, data corruption). Interview tip: This chain is important because it explains why test automation can't find all bugs: you can only detect failures, but a defect that never causes a failure is invisible to testing. This is why code reviews, static analysis, and other verification techniques complement testing.
Static Testing vs Dynamic Testing
Static Testing: Testing without executing the code — code reviews, static analysis (linters, SonarQube), document reviews, walkthroughs, inspections. Static testing finds defects early, before the code even runs. Dynamic Testing: Testing by executing the code — unit tests, integration tests, E2E tests, manual testing. Dynamic testing finds failures that only manifest at runtime. The operational difference: Static testing catches syntax errors, code smells, security vulnerabilities in dependencies, and specification ambiguities — problems you can find without running anything. Dynamic testing catches runtime behaviour issues — logic errors, performance problems, integration failures. A mature testing strategy uses both: static testing in the IDE and CI pipeline (shift-left), dynamic testing at multiple levels (unit, integration, E2E).
Black-Box vs White-Box vs Grey-Box Testing
Black-Box Testing: Testing without knowledge of the internal code structure — you test inputs and outputs, treating the system as opaque. Focus: what the system does, not how. Examples: API testing against specifications, UAT, most manual testing. White-Box Testing: Testing with full knowledge of the internal code structure — you test specific code paths, branches, and logic. Focus: how the system works internally. Examples: unit tests, code coverage-driven testing. Grey-Box Testing: Testing with partial knowledge — you know the high-level architecture and data flow but not the implementation details. Focus: testing at integration points with architectural awareness. Examples: API testing where you know the database schema but not the service code, integration testing with knowledge of message queue topology. Interview tip: Most automated SDET tests are grey-box: you know the API contracts, the database schema, maybe the architecture — but not the implementation details of every service. Acknowledging this in your answer shows you understand the testing landscape, not just textbook categories.
Test Plan vs Test Strategy vs Test Case vs Test Scenario
Test Strategy: The high-level approach — what types of testing will be done, at what levels, with what tools, by whom. Strategy is project-agnostic: it defines the organisation's testing philosophy. Test Plan: The specific implementation of the strategy for a particular project or release — what will be tested, when, by whom, with what resources, and what the entry/exit criteria are. Test Scenario: A high-level description of what to test — "verify that a logged-in user can complete a purchase with a saved payment method." One scenario can cover multiple test cases. Test Case: A specific, step-by-step procedure with defined inputs, expected results, and preconditions — "Step 1: Log in as user with saved card ending 4242. Step 2: Add item SKU-123 to cart. Step 3: Proceed to checkout. Step 4: Select saved card. Step 5: Confirm purchase. Expected: Order confirmation page with order number." The hierarchy: Strategy > Plan > Scenario > Case. For deeper strategy and planning interview preparation, see our guides on test strategy planning and test case design techniques.
Part 7 — CI/CD, Performance, Security, and Accessibility Terminology
Modern SDET roles extend beyond functional automation. You need fluency in the terminology of pipeline integration, system performance, security testing, and accessibility — because these are increasingly part of the SDET's quality ownership scope.
CI/CD Pipeline Terminology
Build Pipeline: The automated sequence of steps that compile, test, and package code. Test stages are inserted at specific pipeline points: unit tests after compile, integration tests after deploy to test environment, E2E tests after full environment provision. Artifact: A packaged, versioned build output (Docker image, JAR file, npm package) that's promoted through environments. Quality Gate: A pipeline checkpoint that blocks progression if quality criteria aren't met — test pass rate below threshold, code coverage decline, security vulnerability above severity threshold. Green/Blue Deployment: A deployment strategy where two identical environments (blue = current, green = new) allow instant rollback — test the green environment, then switch traffic. Canary Release: Rolling out a new version to a small subset of users first, monitoring for issues, then gradually increasing the rollout — essentially, testing in production with a safety net. Interview tip: SDETs who can discuss pipeline terminology beyond "tests run in Jenkins" demonstrate that they understand the operational context of test automation — not just the test code itself. For comprehensive CI/CD interview preparation, see our CI/CD pipeline testing guide.
Performance Testing Terminology
Load Testing: Testing system behaviour under expected concurrent user load — verifying that response times, throughput, and resource utilisation stay within acceptable limits at normal and peak loads. Stress Testing: Testing system behaviour beyond expected capacity to find the breaking point and observe how the system fails — does it degrade gracefully or crash catastrophically? Soak/Endurance Testing: Testing system behaviour under sustained load over an extended period — detecting memory leaks, resource exhaustion, and gradual degradation. Spike Testing: Testing system behaviour under a sudden, extreme increase in load — simulating a flash sale, a viral event, or a DDoS attack. Performance Baseline: A reference set of performance metrics against which future builds are compared — if the baseline is 200ms average response time at 100 concurrent users, a build with 350ms triggers an alert. Percentiles (p95, p99): Response time at the 95th and 99th percentile — p99 = 500ms means 99% of requests completed within 500ms, and 1% took longer. Percentiles matter more than averages because averages hide outliers. For deep performance testing interview prep, see our guides on JMeter, Gatling, and k6.
Security Testing Terminology
SAST (Static Application Security Testing): Analysing source code or binaries for security vulnerabilities without executing the code — finding SQL injection patterns, hard-coded credentials, insecure cryptography. DAST (Dynamic Application Security Testing): Testing a running application for security vulnerabilities — sending malicious inputs, testing authentication bypass, probing for exposed endpoints. Penetration Testing: Simulating a real-world attack on the system to identify exploitable vulnerabilities — typically performed by security specialists, not SDETs, but SDETs should understand the output. OWASP Top 10: The Open Web Application Security Project's list of the ten most critical web application security risks — injection, broken authentication, sensitive data exposure, XML external entities, broken access control, security misconfiguration, cross-site scripting (XSS), insecure deserialisation, using components with known vulnerabilities, insufficient logging and monitoring. Interview tip: SDETs aren't expected to be security experts, but they are expected to know what SAST and DAST are, understand the OWASP Top 10 at a high level, and know how to integrate security scanning into CI/CD pipelines. See our security testing interview questions guide for comprehensive preparation.
Accessibility Testing Terminology
WCAG (Web Content Accessibility Guidelines): The international standard for web accessibility — currently at version 2.2, organised around four principles: Perceivable, Operable, Understandable, Robust (POUR). A, AA, AAA Conformance Levels: WCAG's three levels — A (minimum), AA (standard target for most organisations), AAA (highest, not always achievable for all content). Screen Reader Testing: Testing with assistive technology (VoiceOver, NVDA, JAWS) to verify that content is correctly announced and navigable. Automated vs Manual Accessibility Testing: Automated tools (axe-core, Lighthouse, Pa11y) catch 30-40% of accessibility issues — colour contrast, missing alt text, heading hierarchy. The remaining 60-70% require manual testing: keyboard navigation, screen reader experience, focus order logic, meaningful link text. Interview tip: SDETs who can discuss both automated and manual accessibility testing — and the 30-40% coverage limitation of automation — demonstrate mature understanding. For in-depth preparation, see our accessibility testing interview questions guide.
Part 8 — How to Explain Testing Terms in Interviews: The "Explain to a Junior Developer" Test
Knowing a definition is necessary but not sufficient. Explaining a term — clearly, concisely, and without relying on jargon that assumes prior knowledge — is the skill that interviewers actually evaluate. A memorised definition sounds like a Wikipedia article. An explanation sounds like someone who understands the concept deeply enough to teach it. Here's the framework Mitchell has used to coach hundreds of SDET candidates on terminology answers.
Start with the Category (Not the Definition)
Before you define a term, place it in its category. This gives the interviewer context and demonstrates structured thinking. Instead of: "Smoke testing is..." Say: "Smoke testing is a type of test level — specifically, it's a build verification activity that sits between deployment and detailed testing." This one-sentence framing tells the interviewer you understand where the concept fits in the broader testing landscape — not just its isolated definition. Practice this for every term: what category does it belong to? Test type? Test level? Design pattern? Methodology? Quality attribute?
Define in One Sentence (Your Words, Not the Textbook)
The second sentence should be your own one-sentence definition. Not the ISTQB definition, not the textbook definition — your definition, in your words. This proves you've internalised the concept. Example: "Smoke testing is essentially asking: is this build functional enough to be worth testing further, or is it fundamentally broken?" Your definition should be simple enough that a junior developer with no testing background could understand it. If your definition uses three other testing terms that also need defining, it's not a good definition.
Use a Concrete Example (The Bridge from Abstract to Real)
The third component: a brief, concrete example that makes the abstract concept tangible. "For example, when we deploy a new build of an e-commerce application, our smoke tests verify: can the application start, can users log in, can they search for a product, and can they add it to the cart? If any of these fail, we reject the build — there's no point running the 5,000-test regression suite." The example should be specific — name the application type, the specific checks, the consequence of failure. Abstract examples ("like checking if the system works") don't help. Concrete examples ("verifying login, search, and add-to-cart on an e-commerce app") demonstrate operational experience.
Contrast with a Neighbouring Concept (If the Term Has a Common Confusion)
If the term has a commonly confused counterpart — and most testing terms do — add a brief contrast. "People sometimes confuse smoke testing with sanity testing. The difference is scope: smoke testing is broad and shallow — checking the build overall. Sanity testing is narrow and deep — checking a specific change. Smoke gates the build; sanity gates the change." This contrast signals two things: you know the term, and you know the landscape around the term — you understand where the boundaries are. This is exactly the depth that interviewers are probing for.
🎯 The 90-Second Rule for Terminology Answers
Mitchell's guideline from evaluating hundreds of SDET interviews: a good terminology answer should take 60-90 seconds. Longer than that, and you're either rambling or reciting. Shorter than that, and you haven't demonstrated depth. The 90-second structure: Category placement (10 seconds) → Your definition (15 seconds) → Concrete example (25 seconds) → Contrast with neighbour (20 seconds) → Relevance to the role (20 seconds). Practice timing yourself with your phone's stopwatch. The candidates who can deliver a crisp, 90-second definition for any of the 80+ terms in this glossary — without notes, without hesitation — walk into interviews with a visible confidence that comes from knowing that no terminology question can catch them off guard. The SDET Interview Coach app includes timed terminology drills that simulate exactly this interview pressure — presenting a term and recording your answer for self-review and AI feedback.
Part 9 — Red-Flag Terminology Mistakes That Lose Interviewers
Some terminology mistakes are minor — an interviewer will mentally note the imprecision and move on. Others are red flags that fundamentally shift how the interviewer evaluates everything else you say. Here are the terminology mistakes that do disproportionate damage — not because the term itself is critically important, but because the mistake signals a gap in testing fundamentals that casts doubt on broader competence.
🚩 Red Flag 1: Confusing Verification and Validation
This is the single most common red-flag mistake in SDET interviews — and it appears across all seniority levels. When a candidate says "We verify that the software meets user needs" or "We validate the code against the specification," they've just reversed the two terms. Why this matters: verification and validation are foundational concepts in software testing — they appear in ISTQB Foundation Level, they're the basis of test strategy, and they're terminology that the interviewer almost certainly learned in their first testing course. Getting them backwards suggests either: (a) you've never formally studied testing (not disqualifying, but notable), or (b) you studied but didn't retain the fundamentals (more concerning). Either way, it's a flag. The fix: create a sticky note, put it on your monitor during interview prep: Verification = Specification. Validation = Expectation. Drill it until it's automatic. The SDET Interview Coach app includes spaced repetition for exactly this kind of fundamental terminology — the pairs that candidates most commonly reverse under pressure.
🚩 Red Flag 2: Calling Every Test Double a "Mock"
When a candidate says "We mock the database" when they mean "We use an in-memory fake," or "We mock the API" when they mean "We stub the API responses," they've signalled that they don't understand the test double taxonomy — which signals that they haven't worked in a testing environment where the distinctions mattered. Why this matters: in a serious test automation environment, the distinction between stub, mock, fake, spy, and dummy is operational. Using a mock when you need a fake leads to tests that don't catch real integration issues. Using a stub when you need a mock means you can't verify critical interactions. Using the wrong term in code review — "This test needs a mock for the payment gateway" when it actually needs a stub — leads to the wrong implementation. The fix: memorise the five types, their use cases, and practice using each in example sentences. "I stubbed the API to return a fixed response for this test." "I mocked the notification service to verify that sendAlert() was called." "I used a fake in-memory database for local development."
🚩 Red Flag 3: Saying "BDD Is Writing Gherkin Scenarios"
This definition was acceptable in 2018. In 2026, it signals that your understanding of BDD is frozen at the tool level. BDD is a collaboration practice that uses concrete examples to build shared understanding. Gherkin is a syntax for capturing those examples. Cucumber is a tool for automating them. Conflating BDD with Gherkin is like conflating "agile" with "stand-up meetings" — it misses the philosophy in favour of the mechanics. Why this matters: if an SDET candidate reduces BDD to a syntax, it raises the question: what else do they understand only at the surface level? The fix: practice defining BDD as a collaboration practice first, then mention Gherkin as the syntax, Cucumber as the tool. The order matters — it signals that you understand the why before the how.
🚩 Red Flag 4: Describing Exploratory Testing as "Random Testing" or "Ad-Hoc Testing"
This mistake signals a fundamental misunderstanding of a core testing practice — and, more damagingly, it signals that you might dismiss the testing work that doesn't involve automation. Exploratory testing is structured: it uses charters (time-boxed missions), it requires skill (simultaneous learning, design, and execution), and it produces documented findings (session-based test management). Calling it "random" in an interview is like a developer calling code review "just reading" — it trivialises a skilled activity and alienates interviewers who value it. Why this matters: many senior SDETs began their careers in manual and exploratory testing. You're potentially insulting the interviewer's own background. The fix: know the definition, acknowledge the skill, and — even if your personal focus is automation — demonstrate respect for the practice.
🚩 Red Flag 5: Using "Test Automation" and "Automated Testing" Interchangeably Without Nuance
This is a nuanced one — many interviewers won't flag it, but the best ones will. "Automated testing" is the activity — using tools to execute tests automatically. "Test automation" is the discipline — the strategy, architecture, tooling, and maintenance of the systems that enable automated testing. The distinction: you can do automated testing without test automation (running a script someone else wrote), but you can't have sustainable automated testing without test automation (the framework, CI integration, reporting, and maintenance strategy). Why this matters: conflating the activity with the discipline signals that you see test automation as a task rather than an engineering discipline. At senior levels, interviewers expect you to discuss test automation as an engineering problem — with architecture, scalability, maintainability, and team enablement dimensions — not just as script-writing.
🚩 Red Flag 6: Not Knowing What a Flaky Test Is — Or Dismissing Flakiness as "Just Happens Sometimes"
A flaky test is a test that passes and fails intermittently without any code changes — its outcome is non-deterministic. If a candidate can't define flaky tests, or — worse — dismisses them as an acceptable part of test automation, that's a significant red flag. Why this matters: flaky tests are one of the most expensive problems in test automation. They erode trust in test results, they slow down CI pipelines (re-running flaky tests), they waste developer time investigating false positives, and they lead to "test blindness" — where teams ignore test failures because "it's probably just flaky." A candidate who doesn't take flakiness seriously signals that they haven't operated in an environment where test reliability was critical — or that they were in such an environment and didn't notice the problem. For deep preparation on this topic, see our test flakiness and stability guide.
The common thread across all six red flags: they're not about obscure, niche terminology. They're about fundamental concepts that every competent SDET should know. That's why they're red flags — they signal gaps in the foundation, not missing knowledge at the edges. Drill these six areas until they're automatic. The SDET Interview Coach app specifically identifies and drills the terminology areas where candidates most commonly make these red-flag mistakes, using AI-powered feedback that flags imprecise definitions and suggests improved framing.
Mitchell's Perspective: Testing Terms That Changed Meaning Over 20 Years
Language evolves, and testing terminology is no exception. Mitchell has watched the vocabulary of software testing shift over two decades — sometimes gradually, sometimes abruptly — as methodologies changed, tools matured, and the industry's understanding of quality deepened. Here are the terms whose meanings have shifted most significantly, and what those shifts reveal about where testing is heading.
"Test Automation" — From Record-and-Playback to Engineering Discipline
2005 meaning: Using tools like QTP or WinRunner to record user actions and replay them — automation as a faster way to execute manual test cases. The "automation engineer" was often a tester who had learned a tool, not an engineer who wrote code. 2026 meaning: Test automation as a software engineering discipline — designing frameworks, writing maintainable code, integrating with CI/CD pipelines, and treating test code with the same engineering rigour as production code. The "SDET" title reflects this evolution: the "S" (Software Development Engineer in Test) signals that automation is now understood as development work applied to testing. Mitchell's observation: The most significant shift wasn't technical — it was cultural. In 2005, test automation was often an afterthought, bolted on after development. In 2026, it's treated as a first-class engineering concern, with dedicated roles, architectural decisions made before a line of production code is written, and testability considered a non-functional requirement from the start. This cultural shift — from "testing after" to "building quality in" — is the through-line of Mitchell's entire career, and it's what every modern SDET interview is fundamentally testing.
"Shift-Left Testing" — From Earlier in the Cycle to Everywhere in the Cycle
2010 meaning: Test earlier in the development lifecycle — involve testers during requirements and design, not just after development is "complete." 2026 meaning: Testing is integrated at every stage — static analysis at commit time, unit tests written before code (TDD), contract tests in CI, integration tests at pull request, E2E tests before deployment, canary testing in production. "Shift-left" has expanded from "test earlier" to "test everywhere, continuously." Mitchell's observation: The shift-left philosophy succeeded so completely that the term itself is becoming redundant — in mature organisations, testing is no longer a phase that can be "shifted" because it's no longer a phase at all. It's a continuous activity distributed across the entire delivery pipeline. The modern question isn't "When do we test?" It's "Where don't we test?"
"BDD" — From Testing Tool to Collaboration Practice
2010 meaning: BDD meant Cucumber — writing feature files in Gherkin and automating them. It was primarily a testing activity, owned by QA. 2026 meaning: BDD is understood as the "Three Amigos" practice — business, development, and testing collaborating to define concrete examples before implementation. The automation of those examples is secondary to the shared understanding created by the conversation. Mitchell's observation: This redefinition has been one of the healthiest shifts in testing methodology. When BDD was "just Cucumber," it often devolved into an extra layer of test automation that added maintenance overhead without the collaboration benefit. Now that the industry understands BDD as primarily a communication practice, it's used where it adds value — in complex business domains where shared understanding is the bottleneck, not simple CRUD applications where it's overhead. This is a lesson in how testing terminology evolves: tools come first (people need something concrete), practices mature (people realise the tool isn't the point), and eventually the definition catches up to the practice.
"Testing Pyramid" — From Doctrine to Principle with Nuance
2012 meaning: The pyramid was presented as near-doctrine: many unit tests, fewer service tests, fewest UI tests. Deviate at your peril. 2026 meaning: The pyramid is understood as a principle, not a prescription — the principle being that you should invest testing effort where tests are fastest, cheapest, and most reliable. The specific shape depends on your architecture: microservices naturally have more integration tests (the "testing trophy"), event-driven systems have more contract tests, mobile apps have more UI tests than the classic pyramid suggests. Mitchell's observation: The pyramid's evolution from doctrine to principle is a case study in how testing concepts mature. New practitioners need simple rules ("follow the pyramid"). Experienced practitioners need nuanced principles ("move tests to the lowest level where they're reliable and fast"). Interviewers at senior levels want to hear the nuance — not because the pyramid is wrong, but because understanding when and how to deviate from it demonstrates architectural judgment.
"AI in Testing" — From Science Fiction to Operational Reality
2018 meaning: AI in testing was largely aspirational — vendors claimed AI-powered test generation that mostly meant "we have some heuristics for suggesting locators." 2026 meaning: AI in testing is operational: self-healing locators, AI-generated test cases from user session data, visual anomaly detection, predictive flaky test identification, and natural language test authoring. It's not magic — it doesn't replace testers — but it meaningfully reduces the mechanical overhead of test maintenance. Mitchell's observation: The most important thing to understand about AI in testing in 2026 is what it doesn't do: it doesn't understand your business domain, it doesn't know what "correct" behaviour looks like for your specific application, and it can't replace the judgment of an experienced tester who knows which risks to prioritise. AI augments testing — it reduces the toil of maintenance, it surfaces patterns humans might miss, it generates test data and edge cases — but it doesn't replace the tester's judgment. The smartest answer to "What's the role of AI in testing?" acknowledges AI's current capabilities while being clear-eyed about its limitations. Mitchell knows that the AI hype cycle in testing has been intense, and interviewers in 2026 are looking for candidates who are neither AI-cynics nor AI-evangelists — but AI-pragmatists who can articulate exactly where it helps and where it doesn't.
"Quality" Itself — From Defect Absence to Value Delivery
2000 meaning: Quality meant conformance to requirements — the software did what the specification said it should do, with minimal defects. 2026 meaning: Quality has expanded to encompass the full user experience — performance, accessibility, usability, reliability, security, and the speed at which value is delivered. Quality is no longer just "absence of bugs" — it's "fitness for purpose" across all dimensions that matter to users. Mitchell's observation: This is the deepest shift of all, and it's the one that has redefined the SDET role. When quality meant "fewer bugs," the tester's job was finding defects. When quality means "the system delivers value reliably, securely, performantly, and accessibly to all users," the SDET's job expands to encompass the entire quality ecosystem — automation architecture, observability, performance engineering, security testing integration, and accessibility verification. This is why modern SDET interviews test so broadly: they're not assessing whether you can find bugs. They're assessing whether you can own quality across its entire modern definition. The SDET Interview Coach iOS app reflects this expanded definition of quality — its question bank spans functional automation, performance, security, accessibility, CI/CD, and observability because that's what the modern SDET role demands.
How to Use This Glossary for Interview Preparation — A 3-Day Plan
This glossary is comprehensive — 80+ terms across 9 categories. Trying to memorise it in one sitting is counterproductive. Here's a structured 3-day preparation plan that builds terminology fluency systematically:
Day 1: Foundation Terms and Confused Pairs
Focus on the terms that carry the highest interview risk — the ones that are most commonly asked and most commonly mistaken. Morning session (90 minutes): Study and self-quiz on the confused pairs (Part 6) — verification vs validation, QA vs QC, smoke vs sanity, retesting vs regression, static vs dynamic, black-box vs white-box vs grey-box. These are the highest-frequency differentiation questions. Afternoon session (60 minutes): Study test types (Part 1) — be able to define functional, non-functional, regression, smoke, sanity, integration, unit, E2E, UAT, and exploratory testing in your own words. Evening (30 minutes): Quick self-test — your partner, a friend, or the mirror. Pick 5 terms at random and deliver a 90-second definition for each.
Day 2: Acronyms, Test Doubles, and Automation Terms
Focus on the vocabulary of modern SDET practice. Morning session (90 minutes): Master the acronyms (Part 5) — TDD, BDD, DDT, ATDD, POM, CI/CD, SUT, AUT, E2E, UAT, SLA/SLO/SLI. Be able to define each without hesitation and give a brief example. Afternoon session (90 minutes): Master test doubles (Part 4) — stub, mock, fake, spy, dummy. Be able to define all five, explain the use case for each, and differentiate them from each other. Practice the "I use [double type] when I need to [purpose] — for example, [concrete scenario]." formula. Evening (30 minutes): Terminology speed round — 20 terms in 20 minutes. If you hesitate on any term, mark it for Day 3 review.
Day 3: Review, Red Flags, and Mock Interview
Morning session (60 minutes): Review the red-flag mistakes (Part 9) — make sure you can confidently define each term and avoid the common errors. Rehearse Mitchell's terms-that-changed-meaning (Part 8) — these demonstrate industry awareness and can elevate your answers from competent to insightful. Afternoon (45 minutes): Study performance, security, and CI/CD terminology (Part 7) — these are asked more frequently at senior levels. Evening (30-60 minutes): Run a mock interview focused on terminology. Use the SDET Interview Coach app's terminology drill module — it presents terms just as an interviewer would, records your answers, and provides AI feedback on clarity, accuracy, and depth. Or ask a friend to fire 10 random terminology questions at you and evaluate whether your answers pass the "explain to a junior developer" test.
A final word on terminology preparation: don't over-prepare to the point of sounding scripted. The goal is fluency, not memorisation. A candidate who delivers a perfectly memorised ISTQB definition sounds like a textbook. A candidate who says "Let me put that in my own words — here's how I think about it..." sounds like an experienced professional. The difference is detectable within seconds, and it changes how the interviewer evaluates everything else you say. The SDET Interview Coach app helps with this specifically — it evaluates not just whether your definitions are correct, but whether they sound like someone who has used these concepts, not just someone who has studied them. For broader interview strategy, pair this glossary with our SDET interview preparation plan and our behavioural interview questions guide.
Ready to Transform Your Testing?
The AI Test Automation Playbook gives you everything you need: Playwright setup, Claude AI integration, MCP deep dive, 10+ ready-to-use prompts, CI/CD pipeline setup, and a 30-day implementation roadmap.
By Mitchell Agoma, Senior SDET & AI Testing Specialist with 8+ years of experience