Test Case Design Techniques for SDET Interviews 2026 — How SDETs Design Test Cases Differently from Manual Testers: Automation-Conscious Test Architecture, Black-Box Techniques for SDET Interviews (Equivalence Partitioning, Boundary Value Analysis, Decision Tables, State Transition Testing, Pairwise Testing), White-Box Structural Techniques (Statement Coverage, Branch Coverage, Path Coverage, and MC/DC for Safety-Critical Systems), Experience-Based Approaches (Exploratory Testing, Error Guessing, Checklist-Based Testing, Heuristic Risk-Based Testing), How to Prioritise Test Cases When Time Is Limited (Risk-Based Prioritisation, MoSCoW for Testing, Impact Analysis), Real Interview Scenarios with Structured Model Answers, Common Mistakes Candidates Make in Test Design Interviews, and 7 Model-Answer FAQs
The definitive test case design interview guide for SDETs, QA engineers, and test automation professionals in 2026 — covering every dimension of test design methodology that interview panels probe when assessing whether you can think structurally about quality, not just write test scripts. Many SDET candidates prepare exhaustively for coding rounds — memorising Playwright selectors, practising API assertion patterns, drilling on Selenium grid architecture — but walk into the test design interview expecting it to be 'the easy round'. They're wrong. Test design is where panels separate testers who follow instructions from engineers who design quality. The question sounds simple: 'Here's a login page. Design the test cases.' But what the panel is actually evaluating is whether you can decompose a feature into testable dimensions, apply structured techniques rather than guessing at edge cases, prioritise ruthlessly when time is limited, and explain your reasoning with the vocabulary of the testing craft — equivalence classes, boundary values, decision tables, state transitions, pairwise combinations. This guide treats test case design as a methodology, not a talent: we cover how SDETs design test cases differently from manual testers (automation-conscious design that considers maintainability, data independence, and execution order from the first test case), black-box techniques (equivalence partitioning, boundary value analysis, decision tables, state transition testing, and pairwise testing — each explained with the interview scenario that triggers it), white-box techniques relevant to SDETs (statement coverage, branch coverage, path coverage, and MC/DC for safety-critical contexts — not just the definitions but the 'when would you use this?' reasoning panels expect), experience-based techniques (exploratory testing, error guessing, checklist-based testing, and heuristic risk-based testing — how to describe these in an interview without sounding like you lack rigour), prioritisation strategies (risk-based, MoSCoW for testing, and impact analysis), a detailed walkthrough of the 'design test cases for a login page' interview question with a structured model answer, and the top 7 mistakes candidates make in test design interviews with explicit anti-patterns to avoid. Every section includes the interview framing — the exact question that triggers the technique, the thought process the panel wants to see, and the follow-up questions that distinguish mid-level from senior candidates. With 7 detailed FAQs and methodology-first explanations throughout, this guide is designed to transform your test design interview from 'I'll list every edge case I can think of' to 'I'll apply a structured technique that gives me confidence I haven't missed anything' — the test design maturity that correlates with £85K–£120K SDET roles in 2026. Complement with our guides on Test Strategy and Planning Interview Questions 2026 for the strategic layer above individual test design, BDD and Cucumber Interview Questions 2026 for the behaviour-driven approach that pairs with structured test design, and SDET Behavioural Interview Questions 2026 for the communication skills you need to explain your test design thinking to panels. The SDET Interview Coach iOS app includes a dedicated Test Case Design mock interview module with AI-scored scenario exercises — you're given a feature description and asked to design test cases using specific techniques, then evaluated on coverage, technique selection, and prioritisation reasoning.
Published 30 May 2026 • By Mitchell Agoma
Picture this. You've cleared the coding round — wrote a clean Playwright spec, explained the Page Object Model with architectural precision, debugged a flaky test faster than the interviewer expected. You're feeling good. Then the panel lead slides a piece of paper across the table — or pastes a feature description into the shared editor: "Here's a login page. It has an email field, a password field, a 'Remember Me' checkbox, a 'Sign In' button, and a 'Forgot Password' link. After 5 failed attempts, the account locks for 15 minutes. Design the test cases." You pick up the pen — or your fingers hover over the keyboard — and your mind starts racing. Do I list every possible input? What about the password validation rules — they didn't specify those, should I ask? Is the interviewer expecting 5 test cases or 50? Am I supposed to mention automation here? Should I talk about performance? Security? Accessibility? What does 'design the test cases' actually mean?
This moment — the open-ended test design question — is where SDET interview panels separate engineers who think structurally about quality from testers who guess at edge cases. And here's the uncomfortable truth that most interview preparation blogs won't tell you: test design is the round that candidates most consistently underestimate. They spend weeks grinding LeetCode and memorising Selenium interview questions, assuming test design is the 'soft' round where they can just 'be thorough'. Then they sit down in front of a panel that expects a methodical, technique-driven approach — and they improvise. They list 15 test cases but miss the boundary values. They mention equivalence partitioning but can't name the partitions. They talk about coverage but don't specify whether they mean statement, branch, or path coverage. And the panel — which has seen 40 candidates that month — slots them into the 'can write tests but doesn't design them' bucket. In 2026, with AI-generated code raising the stakes on systematic quality assurance and continuous deployment reducing the safety net of manual review, the ability to design test cases with rigour — not just enthusiasm — is the skill that commands £85K–£120K SDET roles.
This guide treats test case design as a methodology, not a talent. Every technique we cover is paired with the interview scenario that triggers it, the structured thinking the panel wants to hear, and the follow-up questions that distinguish mid-level from senior candidates. We cover: how SDETs design test cases differently from manual testers (it's not just 'add an automation step' — it's designing for maintainability, data independence, and execution order from the first test case), black-box techniques (equivalence partitioning, boundary value analysis, decision tables, state transition testing, and pairwise testing — each explained through the lens of 'the interviewer says X, so I apply technique Y'), white-box techniques relevant to SDETs (statement, branch, path coverage, and MC/DC for safety-critical systems — with the trade-off reasoning panels expect), experience-based techniques (exploratory testing, error guessing, checklist-based testing, and heuristic risk-based testing — described with the rigour that prevents the panel from thinking you're winging it), prioritisation strategies (how to answer 'you only have time to test 30% of these — which 30% and why?'), and a full walkthrough of the login page scenario with a structured model answer. Complement this with our deep-dives on Test Strategy and Planning Interview Questions 2026 for the strategic framework that sits above individual test design decisions, BDD and Cucumber Interview Questions 2026 for the behaviour-driven approach that pairs structured test design with business-readable scenarios, and SDET Behavioural Interview Questions 2026 for the communication skills you need to walk a panel through your test design thinking. The SDET Interview Coach iOS app includes a dedicated Test Case Design mock interview module — you're given a feature description (login page, e-commerce checkout, API endpoint, mobile screen) and asked to design test cases using specific techniques, with AI-scored feedback on coverage completeness, technique selection, prioritisation reasoning, and the clarity of your verbal walkthrough.
How SDETs Design Test Cases Differently from Manual Testers
Before we dive into specific techniques, we need to address the framing that underpins every SDET test design interview. The panel isn't asking 'How would a tester design test cases for this feature?' — they're asking 'How would you, as an SDET, design test cases for this feature?' The distinction matters because an SDET's test cases are never just verification steps — they are the blueprint for an automated test suite that will execute hundreds of times across multiple environments, and that blueprint must account for concerns that manual testers never need to consider.
The Manual Tester's Test Case Mindset
A manual tester designs a test case as a one-time execution script: given these preconditions, perform these steps, observe this result. The test case can rely on human judgement — 'check that the page looks correct', 'verify the error message is user-friendly'. It can assume the tester will notice anomalies not explicitly listed in the expected result. It doesn't need to worry about test data cleanup because the tester is a person who can reset state between tests. It doesn't need to consider execution order because the tester decides what to run next. This is not a criticism of manual testing — it's acknowledging that manual test cases are designed for a human executor with judgement, context, and adaptability.
The SDET's Test Case Design Mindset
An SDET designs a test case as a programmatic assertion that must be repeatable, independent, and maintainable. Every step must be deterministically verifiable — 'the page looks correct' becomes 'the element with data-testid="welcome-banner" is visible and contains the text "Welcome, {username}"'. Test data must be created by the test or fetched from a known pool — the test cannot assume a user named 'test@example.com' exists unless the test created it. Test cases must be independent — Test B cannot rely on Test A having run first, because CI parallelisation means they might run in any order. And — critically — the test cases must be designed with maintenance cost in mind. A test case that validates 20 things in one flow might find bugs but will be a maintenance nightmare when any one of those 20 things changes. The SDET test design interview tests whether you think about these non-functional dimensions while you're designing the functional test cases.
Automation-Conscious Design Principles
Atomicity: Each test case should verify one logical behaviour. Not 'test the login page' — that's a test suite, not a test case. Instead: 'verify that valid credentials navigate to the dashboard', 'verify that invalid credentials display an error message', 'verify that account lockout triggers after 5 failed attempts'. Atomic tests are easier to debug when they fail, easier to maintain when requirements change, and easier to parallelise. Data independence: Design test cases that create, use, and clean up their own data. Never design a test that says 'log in with the test user that was created during setup' unless the test itself verifies or creates that setup. Execution order independence: Every test case should be able to run in isolation. If you design Test Case 7 to depend on Test Case 6 having populated the database, your test suite will fail intermittently in parallel CI. Deterministic assertions: Replace 'the error should be clear' with 'the element with data-testid="login-error" should contain the text "Invalid email or password"'. Machines don't have judgement — your test cases must translate human-quality expectations into machine-verifiable assertions. The panel wants to hear these principles in your design walkthrough, not just the functional happy-paths.
The Interview Signal: Mentioning Automation Concerns Intentionally
The strongest SDET candidates don't separate 'functional test design' from 'automation considerations' — they weave them together. When describing a test case, they might say: "I'd verify account lockout after 5 failed attempts. For automation, this means the test case needs to create a fresh user account at the start — it can't rely on a pre-existing locked account because another test might unlock it. The test would execute 5 failed login attempts, verify the lockout message on the 6th attempt, then clean up by deleting the test user. I'd make the lockout threshold configurable via an environment variable so the test doesn't break if the threshold changes from 5 to 3." This answer demonstrates that you're designing test cases as an SDET — thinking about data lifecycle, configuration, and maintainability from the moment you sketch the test scenario. It's the difference between 'I can also automate tests' and 'I design tests for automation'.
Black-Box Test Case Design Techniques — The Structured Approach to Coverage
Black-box techniques are the backbone of SDET test design interviews. They're called 'black-box' because you design test cases based on the specification and behaviour of the system — not its internal code structure. The panel presents you with a feature's external behaviour (inputs, outputs, states, rules) and expects you to derive test cases systematically, not intuitively. The candidate who says 'I'd test the login page by trying valid credentials, invalid credentials, blank fields, SQL injection, and long inputs' has demonstrated breadth of imagination but not method. The candidate who says 'I'd start with equivalence partitioning for the email and password fields, then apply boundary value analysis to the password length constraints, then model the account lockout behaviour with a state transition diagram, and use a decision table for the Remember Me × valid/invalid credentials combinations' has demonstrated that they can decompose a feature into testable dimensions using industry-standard techniques. The second candidate gets hired.
Equivalence Partitioning — Grouping Inputs That Should Behave the Same Way
What it is: Divide all possible inputs into partitions (equivalence classes) where the system should behave identically for any value within a partition. Then test one representative value from each partition. If the system handles that value correctly, it should handle all values in the partition correctly. When the interviewer triggers it: Any time the feature has input fields with validation rules — email format, password length, age range, dropdown values. The structured answer for the login page: "For the email field, I identify four equivalence partitions: (1) valid email format with a registered account, (2) valid email format with an unregistered account, (3) invalid email format — no @ symbol, and (4) empty email field. I test one representative from each. For the password field: (1) correct password for the given email, (2) incorrect password, and (3) empty password. For the 'Remember Me' checkbox: (1) checked and (2) unchecked." The follow-up that shows senior thinking: The interviewer asks: "What about email addresses with plus signs, like user+tag@domain.com?" The strong answer distinguishes between valid partitions (plus-addressing is a valid email format per RFC 5321 — it shouldn't be a separate partition unless the system specification treats it differently) and the practical testing judgement (if the system uses email as a unique identifier and plus-addressing could create duplicate accounts, it's worth an additional test case).
Boundary Value Analysis — Testing the Edges Where Bugs Live
What it is: Bugs cluster at the boundaries between equivalence partitions — not in the middle. Boundary value analysis tests values at the exact boundaries, just inside them, and just outside them. For a field that accepts values 1–100, you test 0, 1, 2, 99, 100, and 101 — not 50. When the interviewer triggers it: Any time you mention input validation ranges — password must be 8–64 characters, age must be 18–120, quantity must be 1–99. The structured answer for the login page: "If the password policy requires 8–64 characters, I'd test passwords of length 7 (just below the minimum), 8 (at the minimum), 9 (just above the minimum), 63 (just below the maximum), 64 (at the maximum), and 65 (just above the maximum). For the account lockout threshold of 5 attempts, I'd test exactly 4 (should not lock), exactly 5 (should lock), and exactly 6 (should still be locked)." The senior follow-up insight: The panel might ask: "How do you handle boundary testing when a field accepts any non-negative integer?" The answer: "There's no upper boundary in the specification, but there is a practical boundary — the maximum value the database column can store. I'd identify that from the schema. If it's a PostgreSQL INTEGER, the boundary is 2,147,483,647. I'd test that value, and I'd test 2,147,483,648 to verify the system handles overflow gracefully." This answer shows you think across the stack, not just at the UI layer.
Decision Tables — Mapping Input Combinations to Expected Outcomes
What it is: When a feature's behaviour depends on multiple conditions, a decision table systematically enumerates every combination of conditions and specifies the expected action. This prevents the 'I forgot to test what happens when Condition A is true AND Condition B is false' gap. When the interviewer triggers it: Any feature where multiple inputs interact to determine the outcome — login (valid email? × correct password? × account locked? × remember me?), e-commerce discounts (loyalty tier × coupon code × order value × seasonal promotion), or access control (role × resource × action). The structured answer for the login page: Create a table with conditions: Valid Email (T/F), Correct Password (T/F), Account Locked (T/F), Remember Me Checked (T/F). That's 2⁴ = 16 combinations. But you don't test all 16 — you apply risk-based reduction: "Some combinations are logically impossible or don't need separate test cases. If the email is invalid, whether the password is correct is irrelevant — the system won't authenticate. I'd reduce the 16 combinations to approximately 8–10 high-value scenarios: (1) all valid → success, (2) valid email, wrong password → error, (3) valid email, wrong password × 5 → lockout, (4) locked account, correct password → lockout message, (5) valid credentials, Remember Me checked → persistent session, (6) valid credentials, Remember Me unchecked → session-only, (7) empty email → validation error, (8) empty password → validation error." The senior signal: recognising that you don't need to test all 16 combinations, and being able to explain which combinations you'd drop and why.
State Transition Testing — Modelling Systems That Change Behaviour Over Time
What it is: For features where the system's response depends on its current state (not just the current input), you model the states and transitions, then design test cases that traverse each transition. When the interviewer triggers it: Any feature with a state machine — login (logged-out → logging-in → logged-in → locked-out → unlocked), order lifecycle (pending → confirmed → shipped → delivered → returned), or subscription (active → past-due → cancelled → reactivated). The structured answer for the login page: "The login feature has four states: Logged Out, Authenticated, Locked Out, and Session Expired. Transitions: Logged Out → Authenticated (valid credentials), Logged Out → Locked Out (5 consecutive failed attempts), Locked Out → Logged Out (15-minute timer expires), Authenticated → Session Expired (session timeout or manual logout). I'd design test cases for each transition: (1) successful login from Logged Out state, (2) lockout triggered from Logged Out state after 5 failed attempts, (3) attempt to log in while in Locked Out state, (4) successful login after lockout timer expires, (5) session expiry after period of inactivity." The SDET-specific extension: "For automation, I'd structure these as parameterised tests with the starting state as a parameter. The test setup would transition the system into the required starting state — for the lockout test, I'd create a fresh user and execute 5 failed logins programmatically before verifying the lockout behaviour on the 6th attempt."
Pairwise Testing — Covering Input Combinations Efficiently
What it is: When you have many input parameters with multiple possible values, testing every combination is combinatorially impossible. Pairwise testing (also called all-pairs testing) covers every pair of parameter values at least once — based on the empirical observation that most bugs are triggered by a single parameter value or the interaction of two parameters, not three or more. When the interviewer triggers it: Configuration-heavy features — browser × OS × screen resolution for cross-browser testing, or payment method × currency × country for checkout testing. The structured answer: "For a feature with 5 parameters, each with 3 possible values, exhaustive testing would require 3⁵ = 243 test cases. Pairwise testing reduces this to approximately 9–15 test cases while still covering every pair of values. In an interview, I'd describe the technique and note that tools like PICT (Pairwise Independent Combinatorial Testing) from Microsoft generate the optimal set automatically — the intellectual contribution is recognising when the technique applies, not memorising the combinations." The interview nuance: Pairwise testing is a power move in SDET design interviews because most candidates never mention it. But use it judiciously — applying pairwise testing to a login form with 3 inputs is over-engineering. Applying it to a configuration matrix with 8 parameters and 4 values each shows you can scale your test design thinking.
🎯 How to Choose the Right Black-Box Technique in an Interview
The panel won't tell you which technique to use — they'll describe a feature and ask you to design test cases. Your job is to name the technique you're applying as you apply it. This demonstrates that you're not guessing — you're using a structured method. Here's a mental decision tree: Are there input fields with validation rules? → Equivalence partitioning + boundary value analysis. Does the behaviour depend on multiple interacting conditions? → Decision table. Does the system change behaviour based on its current state? → State transition testing. Are there many configurable parameters that could interact? → Pairwise testing. Does the feature involve sequences of operations where order matters? → Use case testing or sequence-based testing. The strongest candidates name 2–3 techniques in their answer: "I'd start with equivalence partitioning for the individual fields, then use a decision table for the combinations that affect authentication outcome, and model the lockout behaviour with a state transition diagram."
White-Box Test Case Design Techniques — Designing Tests from the Code's Perspective
White-box techniques (also called structural or glass-box techniques) design test cases based on the internal structure of the code — you examine the source to identify paths, conditions, and branches that must be exercised. While black-box techniques answer 'Have we tested all the behaviours the specification describes?', white-box techniques answer 'Have we executed every line, branch, and path in the code?' For SDET interviews, the key is knowing when white-box techniques apply, what coverage level is appropriate for the context, and how to articulate the trade-off between coverage thoroughness and test maintenance cost.
Statement Coverage — The Baseline
Definition: Every executable statement in the code is executed at least once. Statement coverage = (executed statements / total statements) × 100. When an SDET should care: It's the minimum acceptable coverage for any automated unit test suite. 100% statement coverage doesn't mean the code is well-tested — it just means every line ran at least once. A function with an if-else and no test for the else branch still achieves 100% statement coverage if both branches are in the same line (e.g., ternary operator). The interview answer: "Statement coverage is a floor, not a ceiling. I use it as a gate — if statement coverage drops below a threshold (typically 80%), the CI build fails. But I don't treat 100% statement coverage as 'done testing'. I augment statement coverage with branch coverage for complex conditional logic."
Branch Coverage — Testing Every Decision Outcome
Definition: Every possible branch from each decision point (if-else, switch-case, loops) is executed at least once — both the true and false outcomes. When an SDET should care: Branch coverage catches the classic coverage gap: an if statement where both the true and false branches are on separate lines. Statement coverage only requires one branch to run; branch coverage requires both. The interview answer: "For business-logic code — authentication, payment calculation, access control — I target branch coverage. If a function has an if-else, both branches must be exercised. The key interview nuance: for switch statements with a default case, branch coverage requires testing the default case even if 'it should never happen' — because in production, unexpected things happen, and the default case is your safety net."
Path Coverage — Every Possible Route Through the Code
Definition: Every possible path through the code — every unique sequence of statements from entry to exit — is executed. Why it's rarely practical: A function with 5 sequential if-else statements has 2⁵ = 32 possible paths. A function with a loop that iterates N times has infinite paths (0 iterations, 1 iteration, 2 iterations...). Full path coverage is usually impossible. The interview answer: "Full path coverage is theoretically ideal but practically unattainable for all but the simplest functions. I use path coverage as a thinking tool — when I'm designing unit tests for a complex function, I mentally enumerate the major paths and ensure I cover each category: the happy path, each error path, each boundary path, and the null/empty input path. For the login function, the major paths are: valid credentials, invalid email, invalid password, locked account, and empty fields — that's 5 paths rather than the 32 that exhaustive combinatorial coverage would demand."
MC/DC — Modified Condition/Decision Coverage for Safety-Critical Systems
Definition: Each condition in a decision is shown to independently affect the decision's outcome. For a decision like if (A && B), you need test cases where: (1) A=true, B=true → decision true; (2) A=true, B=false → decision false (B independently affects outcome); (3) A=false, B=true → decision false (A independently affects outcome). That's N+1 test cases for N conditions, compared to 2^N for exhaustive testing. When an SDET should care: MC/DC is mandated by DO-178C for aviation software and ISO 26262 for automotive. If you're interviewing for SDET roles in aerospace, automotive, medical devices, or fintech trading systems, knowing MC/DC signals domain awareness. The interview answer: "MC/DC is the coverage criterion for safety-critical systems. It requires N+1 test cases for N independent conditions. For the login function's authentication decision — which might be if (emailValid && passwordCorrect && !accountLocked && !sessionExpired) — MC/DC would require 5 test cases to prove each of the 4 conditions independently affects the outcome, rather than the 16 required for exhaustive testing. I'd apply MC/DC when the system has a safety or financial risk profile that justifies the additional rigour." Even if the role you're applying for doesn't require MC/DC, mentioning it shows breadth of testing knowledge that most candidates lack.
🎯 The White-Box Interview Question That Trips Up Most Candidates
"Should SDETs write unit tests?" This is a trap. The wrong answer: "No, developers write unit tests — SDETs focus on integration and end-to-end." The right answer: "SDETs should be able to review unit test coverage and identify gaps — for example, pointing out that a critical payment calculation function has 95% line coverage but only 60% branch coverage because the error-handling branches are untested. Whether SDETs actually write the unit tests depends on the team's working model. In a paired-testing model, the SDET might pair with a developer to write unit tests for complex business logic. In a traditional model, the SDET's unit-testing contribution is more about coverage analysis, mutation testing, and identifying test gaps than writing the tests themselves. What matters is that I understand white-box coverage criteria well enough to have a meaningful conversation about test gaps with developers." This answer demonstrates both technical depth and organisational awareness.
Experience-Based Test Design Techniques — When Structure Meets Intuition
Black-box and white-box techniques are systematic. They're the foundation of rigorous test design. But they're not the whole story — and interview panels know it. There are testing scenarios where the specification is incomplete, the code is undocumented, or the risk profile changes mid-sprint, and you need techniques that leverage experience, intuition, and domain knowledge. The challenge in an interview is describing these techniques without sounding like you're abandoning rigour. 'I just explore the app and try to break it' is not an interview answer. 'I apply session-based exploratory testing with a defined charter, timebox, and debrief notes' is.
Exploratory Testing — Structured, Not Random
How to describe it in an interview: "Exploratory testing is simultaneous learning, test design, and test execution. It's not 'clicking around' — it's a structured approach where I define a charter (what I'm exploring, with what resources, and what information I'm seeking), set a timebox (typically 60–90 minutes), take contemporaneous notes, and produce a debrief that includes bugs found, areas of concern, and recommendations for areas that need more systematic testing." When to say you'd use it: When the feature is new and the specification is evolving, when you're investigating a bug report with vague reproduction steps, when you need to quickly assess the quality of a third-party integration, or when the sprint deadline is close and you need to focus testing effort on the highest-risk areas that haven't been systematically covered. The SDET-specific angle: "I use exploratory testing to identify which areas are risky enough to justify writing automated tests. I explore first, identify the critical paths and failure modes, then automate those. This prevents the common anti-pattern of automating tests for low-risk functionality while ignoring high-risk areas that are harder to automate."
Error Guessing — Experience-Driven Defect Anticipation
How to describe it in an interview: "Error guessing is a technique where I anticipate likely defects based on my experience with similar systems, common developer mistakes, and known failure patterns. It's not a replacement for systematic techniques — it's a supplement that catches the bugs that systematic techniques miss because they're not in the specification." Examples to cite: "I always test what happens when a user double-clicks a submit button — it's the most common race condition in web applications. I test empty search results pages — developers often design these last and they break in unexpected ways. I test with special characters in names — the apostrophe in O'Brien breaks more SQL queries than any other single character. I test date boundaries — 29 February, year 2038 (the Unix epoch rollover), and daylight saving transition days." The rigour signal: "I maintain a personal error-guessing checklist that evolves with each project. After every production incident, I ask: 'Could error guessing have caught this?' If yes, I add the pattern to my checklist. Over time, this becomes a systematic asset, not just intuition."
Checklist-Based Testing — Institutionalising Experience
How to describe it in an interview: "Checklist-based testing uses a pre-defined list of test conditions, areas, or quality attributes that must be verified. The checklist isn't the test cases themselves — it's a guide that ensures consistency across testers and prevents omissions. Think of it as the aviation pre-flight checklist — the pilot knows how to fly the plane, but the checklist ensures nothing is forgotten." What belongs on an SDET's checklist: Input validation (XSS, SQL injection, special characters, maximum lengths, Unicode), session management (timeout, concurrent sessions, logout invalidation), error handling (friendly messages, no stack traces in production, graceful degradation), accessibility (keyboard navigation, screen reader compatibility, colour contrast), performance under load (large datasets, slow networks), and data integrity (correct persistence, no data loss on error, transactional rollback). The interview answer: "I use checklists as a complement to systematic techniques — the checklist catches cross-cutting concerns (security, accessibility, performance) that aren't always captured by equivalence partitioning or decision tables, which tend to focus on functional behaviour."
Heuristic Risk-Based Testing — Following the Scent of Bugs
How to describe it in an interview: "Heuristic risk-based testing uses rules of thumb — heuristics — to identify areas most likely to contain defects. Classic testing heuristics include: recent changes (code that changed yesterday is more likely to contain bugs than code that hasn't changed in a year), complexity (cyclomatically complex functions have higher defect density), past defect history (modules that had bugs before tend to have bugs again), new technology (the first feature built with a new framework gets more testing attention), junior contributors (code written by developers new to the codebase gets extra scrutiny), and high-traffic paths (the most-used features justify disproportionate testing investment)." The rigour signal: "I combine heuristics with data. If the team has a defect tracking system with root-cause categories, I analyse historical defect distribution — which modules, which types of bugs, which conditions — and use that data to inform my heuristic model. This turns 'gut feel' into evidence-based risk assessment."
🎯 The Experience-Based Technique Trap — and How to Avoid It
The trap: describing experience-based techniques as 'I just know where bugs are'. The escape: always name the specific technique, always describe the structure you bring to it (charters, checklists, heuristics), and always position experience-based techniques as complements to systematic techniques, not replacements. The sentence that saves you: "I use systematic techniques — equivalence partitioning, boundary value analysis, decision tables — as my primary test design approach, and I layer experience-based techniques on top to catch the bugs that systematic techniques miss because they're not explicit in the specification."
Real Interview Scenario: 'Here's a Login Page. Design the Test Cases.' — A Structured Model Answer
This is the single most common test design interview question. It's asked at companies from FAANG to 20-person startups, for roles from junior QA to lead SDET. The question is deliberately open-ended — the panel wants to see your structured thinking process unfold in real time. Here's a model answer that demonstrates methodical test design across functional, non-functional, and SDET-specific dimensions.
Step 1: Clarify the Requirements (Don't Assume)
What to say: "Before I design test cases, I have a few clarifying questions. What are the password validation rules — minimum length, required character types? Is there a CAPTCHA or multi-factor authentication step? What happens after successful login — is there a redirect to a specific page? What's the account lockout policy — after how many failed attempts, and for how long? Does 'Remember Me' persist across browser sessions or just within a session? Is there a rate-limiting mechanism on the login endpoint? What's the expected behaviour for the 'Forgot Password' link — does it navigate to a new page or open a modal?" Why this impresses: The panel gave you deliberately incomplete requirements — just like real projects. Clarifying questions demonstrate that you test against requirements, not assumptions. The panel may answer your questions or they may say 'make reasonable assumptions and document them' — either way, they've seen you think before you design.
Step 2: Apply Equivalence Partitioning to Each Input Field
What to say: "Starting with equivalence partitioning for the input fields. Email field: Partition 1 — valid email format, registered account; Partition 2 — valid email format, unregistered account; Partition 3 — invalid email format (no @, no domain, empty string); Partition 4 — empty field. Password field: Partition 1 — correct password for the email; Partition 2 — incorrect password; Partition 3 — empty field. Remember Me checkbox: Partition 1 — checked; Partition 2 — unchecked. I'll test one representative value from each partition."
Step 3: Apply Boundary Value Analysis
What to say: "For the password length constraint — assuming an 8–64 character policy — I test passwords of length 7, 8, 9, 63, 64, and 65. For the account lockout threshold of 5 attempts, I test 4 failed attempts (should not lock on the 5th), 5 failed attempts (should lock on the 5th), and 6 failed attempts (should remain locked). For the lockout duration of 15 minutes, I test attempting to log in at 14 minutes 59 seconds (should still be locked) and at 15 minutes 1 second (should be unlocked) — though in practice I'd note that testing exact time boundaries requires test environment clock control."
Step 4: Create a Decision Table for the Authentication Combinations
What to say: "The login outcome depends on four conditions: valid email, correct password, account locked, and Remember Me checked. Rather than test all 16 combinations, I'll identify the high-value scenarios: TC1 — valid email + correct password + not locked + Remember Me unchecked = successful login, session cookie; TC2 — valid email + correct password + not locked + Remember Me checked = successful login, persistent cookie; TC3 — valid email + incorrect password + not locked = error message, failed attempt counter incremented; TC4 — valid email + incorrect password + not locked, 5th consecutive attempt = account locked; TC5 — valid email + correct password + account locked = error message indicating lockout; TC6 — valid email + empty password = validation error; TC7 — empty email + any password = validation error; TC8 — valid email + expired session + any password = redirected to login."
Step 5: Model the State Transitions
What to say: "The login system has these states: Logged Out, Authenticated, Locked Out, Session Expired. I design test cases for each state transition: TC9 — Logged Out → Authenticated via valid credentials; TC10 — Logged Out → Locked Out after 5 consecutive failed attempts; TC11 — Locked Out → Logged Out after 15-minute timer expiry; TC12 — Locked Out state — verify login is rejected with appropriate message; TC13 — Authenticated → Session Expired after inactivity timeout; TC14 — Session Expired state — verify redirect to login, verify that after re-authentication the user returns to the intended page."
Step 6: Add Cross-Cutting Concerns (Security, Performance, Accessibility)
What to say: "Beyond functional test cases, I'd add non-functional scenarios. Security: TC15 — SQL injection attempt in email and password fields; TC16 — XSS attempt — JavaScript in email field; TC17 — verify password is masked in the UI and not logged in plaintext; TC18 — verify the login endpoint is rate-limited to prevent brute-force attacks; TC19 — verify session token is HttpOnly and Secure. Performance: TC20 — login response time under normal load; TC21 — concurrent login attempts — verify system handles multiple simultaneous authentications. Accessibility: TC22 — verify all form fields have associated labels; TC23 — verify error messages are announced by screen readers; TC24 — verify the login form is navigable by keyboard alone; TC25 — verify sufficient colour contrast on error states."
Step 7: Address SDET-Specific Automation Considerations
What to say: "For automation, I'd structure this as a parameterised test suite with test data factories. Each test case creates its own user account at setup and cleans it up at teardown — no shared test state. The lockout threshold and timer duration are configurable via environment variables so the tests can run faster in CI (e.g., 3 attempts with a 30-second lockout instead of 5 attempts with 15 minutes). I'd use data-testid attributes for element selectors to decouple tests from CSS changes. And I'd split the test cases across test levels: the security-focused tests run in CI on every commit, the accessibility tests run nightly, and the performance tests run pre-release."
🎯 Why This Answer Works — The Panel's Perspective
This answer demonstrates six qualities that panels evaluate: (1) Methodology fluency — you named and applied equivalence partitioning, boundary value analysis, decision tables, and state transition testing. (2) Clarification instinct — you asked questions before designing, showing you test against requirements, not assumptions. (3) Breadth of thinking — you covered functional, security, performance, and accessibility dimensions, not just happy-path functional tests. (4) Automation consciousness — you addressed test data independence, configurable parameters, selectors, and test-level distribution. (5) Structured communication — you walked through your thinking step by step with numbered test cases, making it easy for the panel to follow and evaluate. (6) Pragmatism — you didn't list 100 test cases; you identified 25 high-value scenarios with clear reasoning for each. That's what a senior SDET's test design looks like.
How to Prioritise Test Cases When Time Is Limited
This is the follow-up that almost always comes after the test design question. The panel has just watched you design 25 test cases for a login page. Now they lean forward and say: "You're joining sprint planning. The team tells you there's only time to automate 8 of those test cases this sprint. Which 8 do you pick, and why?" This question tests whether you can prioritise — not just whether you can be thorough. Thoroughness without prioritisation is a mid-level trait. Prioritisation with clear rationale is a senior trait.
Risk-Based Prioritisation — The Default Approach
The framework: For each test case, assess two dimensions: Impact — if this behaviour is broken, how severe is the consequence? (Revenue loss, data corruption, security breach, regulatory violation, user frustration.) Likelihood — how likely is this behaviour to be broken? (Recent code changes, code complexity, new technology, historical defects in this area.) Multiply them: high-impact × high-likelihood test cases get automated first. The structured answer for the login page: "I'd prioritise based on risk. Highest priority: authentication logic — TC1 (successful login), TC3 (incorrect password error), TC4 (account lockout after 5 failed attempts). If authentication breaks, nobody can access the system — that's a Sev-1 incident. Next: session management — TC13 (session expiry) and TC2 (Remember Me persistence). Session bugs cause intermittent failures that are hard to diagnose. Next: security basics — TC15 (SQL injection) and TC18 (rate limiting). Finally: input validation edge cases — TC7 (empty fields). That's 8 test cases covering the highest-risk outcomes."
MoSCoW for Testing — Must, Should, Could, Won't
The framework: Must-test: Test cases that are non-negotiable — if they fail, we don't ship. These are your 8 tests. Should-test: Important but not release-blocking — automate in the next sprint. Could-test: Nice to have — automate when time permits. Won't-test (automate): Scenarios that are better tested manually or aren't worth the automation investment. The interview answer: "For the login page, Must-test includes successful authentication, incorrect credentials, account lockout, session persistence, and basic security validation. Should-test includes the full boundary value suite for password length and the state transition edge cases. Could-test includes the accessibility scenarios — important but not release-blocking for an MVP. Won't-test-automate includes the 'Forgot Password' link navigation — simple enough to verify manually unless it contains complex business logic."
Impact Analysis — What Changed and What Depends on What
The framework: When prioritising under time pressure, focus testing on: (1) code that changed in this release, (2) code that depends on code that changed (integration points), and (3) historically fragile areas. The interview answer: "If the login page was rewritten this sprint, I prioritise the entire login suite — every authentication path is new code with no production battle-hardening. If only the 'Remember Me' functionality was changed, I prioritise TC2, TC13, and TC14 (session-related tests) plus a smoke test of the unchanged authentication paths (TC1, TC3). If nothing in authentication changed but the CSS was redesigned, I prioritise the visual and accessibility tests (TC22–TC25) and run a lightweight smoke test of the authentication flow." The senior insight: "Impact analysis requires understanding the dependency graph of the system — not just the login page in isolation. If the authentication service was refactored, I need to test not just the login page but every feature that depends on authentication: the dashboard, the settings page, the checkout flow. The login page test cases are just the starting point."
🎯 The Prioritisation Answer That Distinguishes Senior from Mid-Level
The mid-level candidate lists which 8 tests they'd pick. The senior candidate explains why those 8, what the risk is of not automating the other 17, and how they'd mitigate that risk. The exact words that signal senior thinking: "The risk I'm accepting by not automating the password boundary tests this sprint is that a future password-policy change could introduce a bug at the boundary values. To mitigate this, I'd add those boundary tests to the next sprint's backlog and I'd document the gap in the sprint retrospective so there's a traceable decision. In the meantime, I'd run the boundary value tests manually before the release." This answer shows that prioritisation isn't just about choosing which tests to write — it's about managing quality risk across sprints with professional accountability.
Common Mistakes Candidates Make in Test Design Interviews
After conducting and observing hundreds of SDET test design interviews, certain failure patterns emerge consistently. These aren't knowledge gaps — they're approach gaps. Candidates who know the theory still fall into these traps because they haven't rehearsed the interview behaviour that demonstrates structured thinking. Knowing these mistakes in advance is the cheapest way to improve your interview performance — you can't fix what you don't know you're doing wrong.
Mistake 1: Diving Straight into Test Cases Without Clarifying Requirements
What it looks like: The interviewer says "Design test cases for a login page" and the candidate immediately starts listing test scenarios — happy path, invalid password, empty fields. They never ask about password policies, lockout rules, session behaviour, MFA, or any other requirement that wasn't explicitly stated. Why it fails: The panel deliberately gave you incomplete requirements. They want to see if you notice. A candidate who designs test cases against unstated assumptions is a candidate who will write tests that validate the wrong behaviour. The fix: Your first response to any test design question should be 2–3 clarifying questions. 'What are the password validation rules?' 'What's the lockout policy?' 'Is there multi-factor authentication?' If the interviewer says 'make reasonable assumptions', respond with 'OK, I'll state my assumptions as I go' — and then explicitly state each one.
Mistake 2: Listing Test Cases Without Naming the Technique
What it looks like: The candidate generates 15 good test cases but never says 'I'm applying equivalence partitioning here' or 'this is a boundary value'. The test cases are correct but the method is invisible. Why it fails: The panel can't tell if you're applying structured techniques or just guessing edge cases from experience. Guessing works for the login page — it won't work for a complex financial calculation where the edge cases aren't obvious. The fix: Narrate your methodology. 'I'll start by applying equivalence partitioning to the input fields...' 'Now I'll model the state transitions...' 'Let me create a decision table for the authentication combinations...' The technique names signal that your approach is transferable to any feature, not just the one on the whiteboard.
Mistake 3: Only Testing the Happy Path and Obvious Error Cases
What it looks like: The candidate covers valid login, invalid password, and empty fields — then stops. Why it fails: That's 3 test cases. The panel expected 15–25. You've demonstrated that you can identify the most obvious scenarios but not that you can systematically decompose a feature. The fix: Use a mental checklist: have I covered all input fields? All states? All transitions? All non-functional dimensions (security, performance, accessibility)? All integration points? All data combinations that affect the outcome? If you've checked all these boxes, you'll naturally produce 15–25 test cases for even a simple feature.
Mistake 4: Ignoring Non-Functional Testing Dimensions
What it looks like: The candidate's test cases are all functional — does it log in, does it show errors, does it lock out. No mention of security (SQL injection, XSS, rate limiting), performance (response time under load), accessibility (keyboard navigation, screen readers), or usability (error message clarity, loading states). Why it fails: SDETs are expected to think about quality holistically. A candidate who only thinks about functional correctness is operating at the manual-QA level of test design. The fix: After covering functional test cases, add a section: 'I'd also add non-functional test cases for security, performance, and accessibility' — and list 3–5 specific tests in each category. This takes 60 seconds and dramatically upgrades the panel's perception of your quality thinking.
Mistake 5: Not Addressing Automation Feasibility and Maintenance
What it looks like: The candidate designs 25 test cases that are functionally correct but some are impossible to automate (e.g., 'verify the email was received within 30 seconds'), some are fragile (tightly coupled to UI implementation details), and some create dependencies between test cases that would break in parallel CI. Why it fails: You're interviewing for an SDET role — the panel expects you to think about automation implications while you design test cases. The fix: For each category of test cases, add a brief automation note: 'These authentication tests will be automated as API-level integration tests — faster and more reliable than UI tests. The visual tests will use Percy or Chromatic for visual regression. The accessibility tests will use axe-core. Test data will be created per test, not shared.'
Mistake 6: Being Unable to Prioritise When Asked
What it looks like: The follow-up question comes: 'You only have time to automate 30% of these. Which ones?' The candidate freezes, or worse, says 'I'd automate all of them — quality is non-negotiable.' Why it fails: 'Quality is non-negotiable' sounds principled but it's professionally naive. In the real world, time is finite and you must prioritise. Refusing to prioritise signals that you can't make the hard trade-off calls that senior SDETs make every sprint. The fix: Have a prioritisation framework ready. 'I'd use risk-based prioritisation: impact × likelihood. The highest-priority test cases are authentication correctness (revenue-critical), account lockout (security-critical), and session management (data-integrity-critical). The lower-priority test cases — boundary value variations, accessibility checks — I'd schedule for the next sprint and document the accepted risk.'
Mistake 7: Not Mentioning Test Data and Environment Considerations
What it looks like: The candidate's test cases assume data exists — 'log in with a valid user account' — without addressing how that data gets created, maintained, or cleaned up. Why it fails: Test data management is one of the hardest problems in test automation. A candidate who designs test cases without thinking about data is a candidate whose tests will fail in CI because 'the test user doesn't exist in this environment'. The fix: For each group of test cases, mention the data strategy: 'I'd create test users via the API as part of test setup — each test gets a unique user with a UUID-based email to avoid collisions. For the lockout test, I'd create a user and programmatically trigger 5 failed logins before running the assertions. All test data is cleaned up in teardown. I'd avoid hardcoded credentials — test user credentials are generated at runtime.'
🎯 The Meta-Mistake: Treating Test Design as a 'Soft' Round
The single biggest mistake SDET candidates make isn't any specific technique gap — it's walking into the test design interview under-prepared because they assume 'I've been designing test cases for years, I'll be fine.' Test design in an interview is a performance. You need to demonstrate structured thinking out loud, in real time, with the vocabulary of the craft. You wouldn't walk into a coding interview without practising algorithms. Don't walk into a test design interview without practising the structured walkthrough. The SDET Interview Coach iOS app includes dedicated test design practice sessions — you're given a feature description, you design test cases, and the AI evaluates your coverage, technique selection, and verbal reasoning. Rehearse 3–5 different features (login page, e-commerce checkout, API endpoint, search functionality, user registration) until the structured walkthrough becomes automatic.
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