BDD and Cucumber Interview Questions — What SDET Panels Ask About Gherkin, Step Definitions, and Behaviour-Driven Testing in 2026
Real BDD and Cucumber interview questions from SDET panels. Covers Gherkin syntax, step definitions, hooks, BDD vs TDD trade-offs, and the behavioural questions that separate testers who've practised BDD from those who've only read about it. Built from panels at HMRC, MoD, Nationwide, and Accenture.
Published 13 May 2026 • By Mitchell Agoma
It's 11pm. Your SDET interview is in 10 hours. You've memorised the Playwright API, you can discuss CI/CD pipeline stages in your sleep, and you've got a framework design answer polished to a mirror shine. Then you re-read the job description and your stomach tightens: "Experience with BDD frameworks — Cucumber, SpecFlow, or Behave."
You know what BDD is. You've seen Gherkin files in your team's repo. You've run Cucumber tests someone else wrote. But now you're picturing the panel asking you to write a Feature file from scratch, or explain the difference between a Before hook and a Background step, or — worst of all — defend why BDD is worth the overhead when the team could just write tests in code. And you realise you've never had to articulate BDD. You've only ever used it.
This guide is for that moment. Built from 20 years of sitting on both sides of the SDET interview table — at HMRC, the Ministry of Defence, Nationwide, and Accenture — it covers exactly what interviewers ask about BDD and Cucumber, how they separate candidates who've practised behaviour-driven development from those who've only watched a conference talk about it, and how SDET Interview Coach prepares you for BDD-specific questions so you walk into that room with structured answers, not vague recollections of a three-year-old blog post.
Why BDD Questions Are Becoming a Differentiator in 2026
Two years ago, mentioning Cucumber on your CV was enough — interviewers would check the box and move on. In 2026, they're probing deeper, and the candidates who can actually discuss BDD as a methodology — not just a tool — are pulling ahead of the pack. Here's what's changed:
- BDD has moved from a testing practice to a collaboration practice. Organisations that adopted Cucumber five years ago as a test automation tool have learned the hard way: BDD without business collaboration is just slow, verbose test automation. Interviewers at Nationwide and Accenture now probe whether you understand BDD as a Three Amigos practice — product owner, developer, and tester writing scenarios together — or whether you've only used Cucumber as a test runner. The distinction is the difference between a mid-level and a senior answer.
- AI-generated tests are putting pressure on BDD's value proposition. With LLMs now capable of generating test scripts from plain-language descriptions, the "BDD lets non-technical people write tests" argument is weakening. The 2026 interview expects you to have thought about this: when AI can write the automation code, BDD's real value shifts to shared understanding and living documentation — not test generation. Candidates who can articulate this shift demonstrate strategic thinking beyond tool proficiency.
- SpecFlow and Behave have matured alongside Cucumber. In 2026, BDD isn't just Cucumber-JVM. Interviewers at enterprise shops (particularly .NET houses and Python teams) expect familiarity with the broader ecosystem. A candidate who can discuss SpecFlow's strengths in the .NET world or Behave's integration with pytest demonstrates breadth that pure Cucumber-only candidates lack.
BDD isn't a testing framework. It's a collaboration methodology with a testing framework attached. Interviewers who've been burned by BDD-as-test-automation know the difference, and they're testing whether you know it too.
Gherkin Syntax Fundamentals — The Foundation Every Interview Tests
Every BDD interview starts with Gherkin. It's the entry-level question — but the depth of your answer determines whether the panel moves on to architecture questions or stays at the basics. Here's what a strong answer covers for each Gherkin keyword:
Feature
The Feature keyword describes a software feature and groups related scenarios. A strong answer: "The Feature provides context — it tells the reader what area of the application these scenarios cover. The description under Feature uses the format 'As a... I want to... So that...' because it anchors every scenario in a user goal. If you can't write the user story, you don't understand the feature well enough to test it." The trap is writing Feature descriptions that are vague or technically focused instead of user-focused. Interviewers at HMRC have flagged candidates who describe features as "API authentication" instead of "As a returning user, I want to log in securely so that my account data remains private."
Scenario & Scenario Outline
Scenario defines a single concrete example. Scenario Outline parameterises it with an Examples table. The interview question: "When would you use a Scenario Outline instead of multiple Scenarios?" The winning answer: "Use Scenario Outline when the behaviour is identical across data variations — like testing a login form with valid, invalid, and empty credentials. The behaviour (verify login result) is the same; only the inputs and expected outcomes change. Use separate Scenarios when the flow differs — a successful login navigates to a dashboard, while a failed login shows an error and stays on the login page. Confusing data variation with behaviour variation is the most common Gherkin anti-pattern."
Given / When / Then
These are the backbone of every scenario, and interviewers test your understanding of their distinct roles. Given establishes preconditions — the state of the system before the action. It's not "I navigate to the login page" (that's an action); it's "I am a registered user" (that's a state). When describes the action or event — and there should be only one When per scenario. Multiple Whens indicate you're testing multiple behaviours in one scenario. Then describes the expected outcome — observable results that a business stakeholder would understand. Avoid implementation details: "Then I should see a welcome message" not "Then the welcome-banner element should have class 'active'."
Background & Scenario Context
Background runs before every Scenario in a Feature — it's for shared preconditions. The interview question: "When would you use Background vs a Before hook?" The strong answer: "Background is for preconditions that are meaningful to the business — 'Given I am logged in as a standard user.' It's visible in the Feature file and contributes to living documentation. Before hooks are for technical setup that's invisible to the business — database seeding, WebDriver initialisation, API client configuration. Mixing them up — putting technical setup in Background or business preconditions in hooks — signals you've used Cucumber without understanding BDD's collaboration purpose."
The Gherkin question that catches the most candidates: "Write me a Scenario for withdrawing cash from an ATM." Most candidates dive straight into the happy path. The strong answer starts with: "Before I write the scenario, I'd clarify who the user is — are they a standard customer, a premium customer with a higher withdrawal limit, or a non-customer using a foreign card? That context determines the acceptance criteria." This demonstrates that you think about scenarios as specifications, not just test scripts.
Cucumber Framework Deep-Dive — What Interviewers Ask About Step Definitions, Hooks, and the Runner
Once you've demonstrated Gherkin literacy, the panel probes the Cucumber framework itself. This is where candidates who've only written Feature files separate from those who've configured and maintained a Cucumber project. Here's what interviewers ask and what a strong answer covers:
Step Definitions & Regular Expressions
"How do you map a Gherkin step to a step definition?" The basics: Cucumber matches Gherkin steps to annotated methods using regular expressions. @Given("I have (\d+) items in my basket") captures the number as a parameter. But the interview question that probes depth: "How do you handle step definition ambiguity — when two step definitions match the same Gherkin step?" Answer: Cucumber throws an AmbiguousStepDefinitionsException. Prevention: use unique step text, avoid overly generic regex patterns like "I have a (.+)", and use Cucumber Expressions ({int}, {string}) instead of raw regex — they're more readable and less prone to ambiguity. The senior candidate mentions organising step definitions by domain concept, not by page — authentication steps, basket steps, checkout steps — so steps are reusable across features that touch the same domain.
Hooks — Before, After, BeforeStep, AfterStep
"Explain Cucumber's hook lifecycle." The execution order: Before hooks run before each Scenario. Then Background steps (if any). Then each Scenario step — with optional BeforeStep/AfterStep hooks wrapping each step. Then After hooks run after each Scenario. The key interview insight: hooks execute in the opposite order of declaration for cleanup — like a stack. If you declare Before hooks A, B, C, they run A→B→C. After hooks run C→B→A. This matters when you're setting up and tearing down dependencies. The common interview follow-up: "How do you share state between hooks and step definitions?" Answer: dependency injection — Cucumber supports PicoContainer, Spring, or Guice for Java; in JavaScript/TypeScript, you use World (Cucumber's context object) or a shared state module. The trap is using static variables for state sharing — they cause test pollution that's hell to debug in parallel execution.
Cucumber Runner & Configuration
"How do you configure Cucumber to run specific scenarios?" The answer covers tags: @smoke, @regression, @wip. The runner configuration specifies which tags to include or exclude. The advanced answer discusses tag expressions — @smoke and not @slow — and the organisational convention: tags for test type (smoke, regression), tags for feature area (basket, checkout), tags for status (wip, flaky). The senior-level addition: "I use tags for pipeline integration — @smoke scenarios run on every PR, @regression runs on merge to main, and @flaky scenarios are excluded from the main pipeline but run in a scheduled flakiness investigation suite. Tags are how Cucumber integrates with CI/CD strategy."
BDD vs TDD vs Hybrid — The Trade-Off Question Every Panel Asks
This is the question that appears in nearly every BDD interview, in some form: "When would you use BDD over TDD? Are they alternatives or complementary?" The interviewer isn't looking for a debate — they're testing whether you understand the purpose of each practice and when to apply which.
TDD (Test-Driven Development)
TDD is a developer practice. Red-Green-Refactor: write a failing unit test, write the minimum code to pass, refactor. TDD produces well-tested, modular code at the unit level. Its primary audience is developers. Its primary benefit is design quality — TDD forces you to think about interfaces before implementations. In an interview, Mitchell's recommended answer: "TDD is about building the thing right. I use it at the unit and integration level — writing tests for individual classes, services, and components before I write the implementation. It's fast feedback (milliseconds to seconds) and it prevents over-engineering because you only write code that satisfies a failing test."
BDD (Behaviour-Driven Development)
BDD is a collaboration practice. It extends TDD's "write tests first" with "write tests in language the business understands." BDD's primary audience is the whole team — product owner, developer, tester. Its primary benefit is shared understanding and living documentation. The interview answer: "BDD is about building the right thing. It's a conversation first, automation second. The Three Amigos — product owner, developer, and tester — sit together and define scenarios before development starts. Those scenarios become executable specifications that serve as both tests and documentation. BDD doesn't replace TDD — it operates at a different level, closer to acceptance testing than unit testing."
The Hybrid Approach — When to Use Each
The answer that wins interviews: "TDD and BDD are complementary, not competing. I use TDD for unit tests — fast, developer-focused, driving code design. I use BDD for acceptance tests — scenarios written with the business that validate user journeys end-to-end. The layers reinforce each other: BDD acceptance scenarios define what the system should do. TDD unit tests define how each component achieves it. If a BDD scenario fails, TDD unit tests help pinpoint which component broke. If TDD tests pass but BDD scenarios fail, the integration between components is broken." The candidate who can articulate this layered testing strategy — BDD at the acceptance layer, TDD at the unit layer — demonstrates architectural thinking beyond any single testing practice.
The follow-up trap: "So should we write all our tests in Cucumber?" The answer is a firm no, and the reasoning is what interviewers judge. "BDD scenarios are expensive — they require collaboration, they run slower than unit tests, and they're harder to maintain because they touch multiple system layers. Use BDD for high-value, business-critical user journeys — the scenarios where misunderstanding the requirement would be costly. Use TDD for the thousands of edge cases and component-level behaviours that don't need business-readable documentation. A healthy test suite is maybe 10-15% BDD scenarios and 85-90% TDD unit tests — following the test pyramid, not the inverted ice cream cone."
Real BDD Interview Scenarios — What Panels Actually Ask
Drawing from panels Mitchell has conducted at HMRC, MoD, Nationwide, and consulting for Accenture, here are the BDD-specific scenarios that appear in SDET interviews — and what a strong answer looks like for each.
"Write a Feature file for a password reset flow."
This practical exercise tests whether you can translate a business requirement into Gherkin. The weak answer: a single happy-path scenario. The strong answer covers: (1) Happy path — user requests reset, receives email, sets new password, logs in successfully. (2) Edge case — user enters an email not associated with an account (security: the system should say 'if that email exists, a reset link has been sent' without revealing whether the account exists). (3) Edge case — reset link expires (test the expiry window). (4) Edge case — new password doesn't meet complexity requirements. (5) Edge case — user submits the form without entering a new password. Each scenario should use declarative language: 'When I request a password reset for my registered email' not 'When I click the forgot-password link and type test@example.com into the email field.' The interviewer is testing whether you write scenarios that specify behaviour rather than describe UI interactions.
"Your team says Cucumber scenarios take too long to maintain. What do you do?"
This is the BDD reality-check question. The weak answer: "We'll reduce the number of scenarios." The strong answer addresses root causes: "First, I'd audit the scenarios. The most common maintenance pain comes from scenarios written at the wrong level of abstraction — too detailed (describing every click and field) or too vague (missing critical acceptance criteria). I'd refactor scenarios to use declarative, business-readable language that doesn't change when the UI does. Second, I'd look for scenario duplication — multiple features testing the same behaviour from different entry points. Third, I'd check whether step definitions have become a dumping ground for complexity — if step definition methods are hundreds of lines, the automation layer has absorbed complexity that should live in Page Objects or helper classes. Fourth, I'd assess whether we're using the right tool for the right tests — not every test benefits from BDD, and scenarios that are purely technical (API validation, performance benchmarks) might be better served by a non-BDD framework." This answer demonstrates that you've maintained a real Cucumber suite, not just written a few Feature files in a tutorial.
"How do you handle test data in Cucumber scenarios?"
Test data strategy in BDD is where operational thinking meets collaboration. The strong answer: "Test data belongs in the Examples table of a Scenario Outline, not hardcoded in step definitions. But I distinguish between scenario-relevant data — 'Given I have £50 in my account' — and setup data — the user ID, account number, and session token needed to execute the scenario. Scenario-relevant data is visible in the Feature file because it's part of the specification. Setup data is managed by fixtures or factories in the step definition layer, invisible to the business reader. For parallel execution, every scenario must create or reserve unique test data — I use UUIDs, timestamps, or dedicated test data pools to prevent scenarios from colliding. The golden rule: the Feature file should read like a specification a business stakeholder understands. If it's cluttered with test data noise, it's failed BDD's primary purpose."
"Should we use Cucumber for API testing?"
This question tests whether you think in trade-offs, not dogma. The strong answer: "It depends on the audience. If the API scenarios are read and discussed with business stakeholders — e.g., 'Given a customer has an active subscription, When their payment fails, Then their account status should change to suspended' — then Cucumber adds value through shared understanding. The Gherkin scenarios become living documentation of the business rules encoded in the API. But if the API tests are purely technical — checking HTTP status codes, validating JSON schemas, testing rate limiting — Cucumber adds overhead without benefit. A REST Assured or plain HTTP client test suite would be faster to write, easier to maintain, and equally effective. The decision should be based on who reads the tests, not on what tool you're comfortable with." The nuance — Cucumber isn't for everything — is what separates thoughtful engineers from framework evangelists.
5 Common BDD Interview Mistakes That Cost Candidates Offers
After watching hundreds of candidates navigate BDD questions, Mitchell has identified the specific mistakes that cause interviewers to lean back and wait for the next candidate. These aren't gaps in knowledge — they're gaps in articulation. You might know BDD, but if you present it the wrong way, the panel won't hear the knowledge.
Mistake #1: Calling Cucumber a Testing Tool
This is the single most common mistake and it signals to interviewers immediately that you've used Cucumber without understanding BDD. "Cucumber is a collaboration tool that happens to produce automated tests. Its primary purpose is to create a shared understanding between business and technical team members through executable specifications. The tests are a by-product — a valuable one — but if your team never reads the Feature files together, you're doing test automation with extra steps, not BDD." This distinction — collaboration first, automation second — is what separates BDD practitioners from Cucumber users. Interviewers who have implemented BDD successfully will probe for this distinction explicitly.
Mistake #2: Writing Imperative Scenarios Instead of Declarative
"When I click the login button, And I type 'user@test.com' in the email field, And I type 'password123' in the password field, And I click submit..." This is imperative Gherkin — it describes how to accomplish something rather than what the behaviour is. It's brittle (the UI changes) and unreadable (business stakeholders don't care about field names). The declarative version: "When I log in with valid credentials, Then I should see my dashboard." The how lives in the step definition, where it belongs. The what lives in the Feature file, where it serves as living documentation. Interviewers who've maintained Cucumber suites will recognise imperative scenarios instantly — they're the number one cause of Cucumber maintenance pain — and they'll probe to see whether you write scenarios that survive UI changes or scenarios that shatter on the first redesign.
Mistake #3: Confusing Background with Before Hooks
When a candidate puts technical setup in Background or business preconditions in Before hooks, it signals they don't understand the purpose of each. Background is for preconditions that matter to the business reader — it's visible in the Feature file. Before hooks are for technical setup that the business reader doesn't need to see. The test: "Would the product owner understand and care about this step?" If yes, it goes in Background. If it's about WebDriver initialisation or database connections, it goes in Before hooks. This isn't a minor stylistic choice — it's about whether your Feature files function as living documentation (Background visible) or just test scripts (everything hidden in hooks).
Mistake #4: Over-Engineering with Too Many Tags
Tags are Cucumber's organisational superpower — and its organisational trap. A candidate who can discuss tag strategy demonstrates operational experience. One who lists twenty tag types signals they've over-engineered. The balanced answer: "I use a minimal tag taxonomy: one tag for test type (@smoke, @regression, @e2e), one for feature area if needed (@basket, @checkout, @auth), and one for work-in-progress or known-flaky scenarios (@wip, @flaky). More than that creates a maintenance burden — every new scenario requires someone to decide which of fifteen tags apply. The tagging system should serve the pipeline, not the other way around." The trap is using tags to recreate JIRA in Gherkin — it's a test suite, not a ticketing system.
Mistake #5: Not Knowing When NOT to Use BDD
The candidate who advocates BDD for everything signals inexperience. The candidate who can articulate where BDD adds value and where it doesn't signals mastery. BDD is valuable when: business rules are complex and benefit from shared understanding, acceptance criteria are the primary source of ambiguity, and the team includes non-technical stakeholders who need visibility into what's being tested. BDD adds overhead without benefit when: testing purely technical concerns (API contracts, performance, security), the team is entirely technical and communicates well without structured scenarios, or the application has a short lifespan where living documentation won't be read. Knowing when to not use BDD is as important as knowing how to use it — and interviewers at senior level and above will probe for this judgement explicitly.
What a Real BDD SDET Interview Looks Like — Timed Breakdown
Drawing from panels Mitchell has conducted across government and enterprise, here's how BDD and Cucumber questions typically appear in a 60-minute SDET interview:
Experience Probe
"Tell us about a project where you used BDD or Cucumber." This opener tests whether you've genuinely practised BDD or just added it to your CV. Be honest about your level. If you've written Feature files but never run Three Amigos sessions: "I've used Cucumber for test automation — writing Gherkin scenarios and implementing step definitions. I understand BDD as a collaboration methodology, though in practice the Feature files were written by the testing team. I'm aware that's BDD-lite, not full BDD, and I'm eager to work in an environment where the Three Amigos practice is embedded." Honesty plus self-awareness beats pretending you've run a fully mature BDD process when your answers to follow-ups will expose otherwise.
Gherkin Practical Exercise
"Write a Feature file for this user story." You'll be given a simple requirement — a login feature, a search function, a checkout flow — and asked to produce Gherkin scenarios. Focus on: declarative language (what, not how), edge cases (not just the happy path), scenario independence (each scenario should run in any order), and business readability (would the product owner understand this?). Don't stress about exact syntax — interviewers care about scenario design, not semicolon placement. If you're unsure about a keyword, say "I'd use a Scenario Outline here with an Examples table" — the concept matters more than the precise Gherkin formatting.
Framework Architecture & Integration
"How would you structure a Cucumber project for 50 feature files running in CI?" This probes your operational experience with Cucumber at scale. Discuss: project structure (features directory, step definitions organised by domain, support code in shared modules), parallel execution (Cucumber's built-in parallel runner or plugin-based solutions like cucumber-jvm-parallel-plugin), reporting (Cucumber's built-in HTML/JSON reports, integration with CI reporting tools), and the all-important CI/CD integration — how scenarios are selected by tag for different pipeline stages, how failures are reported, and how the Feature files themselves are versioned and reviewed alongside application code.
Methodology & Trade-Off Questions
"When would you recommend against using BDD?" This is where the panel tests judgement. Discuss the scenarios where BDD adds cost without benefit — purely technical testing, teams without business stakeholder engagement, short-lived projects where living documentation won't be read, and teams that already communicate well without structured scenarios. Also expect the TDD vs BDD discussion and the "how would you introduce BDD to a team that's never used it?" question — which tests your change-management and communication skills as much as your technical knowledge.
Your Questions
Ask about their BDD maturity: "How do you currently run BDD — is it Three Amigos with the product owner, or is it primarily a test automation practice? What's been the biggest challenge with your Cucumber suite — maintenance overhead, scenario quality, or stakeholder engagement? Do you use Cucumber alongside other testing tools, and where's the boundary?" Questions that probe their BDD practice demonstrate you're thinking about how you'd fit into their team — which is what a hiring manager weighing BDD experience wants to hear.
Why BDD Competence Is Becoming a Career Accelerator for SDETs
After 20 years watching the UK testing market evolve — from HMRC to the MoD, from Nationwide to Accenture — Mitchell has observed a consistent pattern: SDETs who can bridge the gap between business requirements and technical implementation advance faster than pure automation engineers. BDD is the framework for that bridge. Here's why:
- BDD makes your work visible to decision-makers. When your Feature files are read by product owners and business analysts, your testing isn't a black box that produces pass/fail results — it's living documentation that demonstrates your understanding of the product. SDETs who practise BDD effectively get invited to conversations that pure automation engineers don't: requirements workshops, acceptance criteria reviews, and release planning. Those conversations lead to promotions.
- BDD forces you to think about testing as specification, not verification. The shift from "does the system work?" to "does the system do what the business needs?" is the shift from mid-level to senior SDET thinking. BDD's language — Given/When/Then, user stories, acceptance criteria — trains you to think in terms of behaviour and value, not just coverage and pass rates.
- The AI shift makes BDD's collaboration value more important, not less. As AI tools generate test scripts from descriptions, the mechanical act of writing automation code becomes commoditised. What can't be commoditised: the conversation with a product owner where you discover that "password reset" actually means five different things depending on account type, authentication method, and regulatory jurisdiction. BDD is the structure for that conversation. The SDETs who facilitate it will have careers that AI complements, not replaces.
The candidates adding BDD to their skill set now — not just Cucumber syntax, but the collaboration practice — are the ones who'll walk into 2027 interviews as senior SDETs while their purely technical peers are still competing for mid-level roles.
How to Prepare for Your BDD Interview — Starting Tonight
You don't need to have run a fully mature BDD process across three teams. You need to understand the principles, be able to write declarative Gherkin scenarios, articulate the BDD vs TDD trade-off, and — most importantly — demonstrate that you think about testing as collaboration, not just automation. Here's the 3-step plan:
- Download SDET Interview Coach from the iOS App Store and complete the 2-minute onboarding assessment. Select your target stack and seniority level. The app's 800+ question bank includes BDD and Cucumber topics — Gherkin syntax, step definitions, hooks, BDD vs TDD, Cucumber CI/CD integration, and BDD anti-patterns — calibrated to all five seniority levels. Even if BDD hasn't been a core part of your daily work, the app surfaces questions at your level so you can build confidence before the interview exposes uncertainty.
- Run a BDD mock interview today. Pick BDD as your topic, set a 30-minute timer, and answer the questions out loud. The AI feedback scores you on technical accuracy, completeness, communication, and code quality — showing you exactly where your BDD knowledge gaps are before the real panel finds them. The AI mock interviewer asks adaptive follow-ups on Gherkin design, Cucumber architecture, and BDD methodology trade-offs, just like a real panel.
- Use Job Match for your target role. If the job description mentions "BDD," "Cucumber," "SpecFlow," "Behave," "Gherkin," or "behaviour-driven," paste it into Job Match. You'll get 50 questions tailored to that exact role's BDD expectations — no guessing whether they'll ask about Three Amigos, Scenario Outlines, or hook lifecycle management.
The candidates who prepare for BDD questions now — who can articulate the difference between Cucumber-the-tool and BDD-the-methodology, who can write declarative Gherkin that survives UI changes, and who can discuss when not to use BDD as confidently as when to use it — are the ones who'll walk into panels with answers that interviewers remember. BDD isn't a testing framework. It's a collaboration methodology that happens to produce tests. And with SDET Interview Coach, available on the iOS App Store, you can build that BDD confidence before you ever sit down with an interviewer.
If you're building your automation skills from a manual testing background, start with our guide on QA Career Change to SDET — it covers the interview questions manual testers face when transitioning to automation. For web automation interview preparation, see our guide on Playwright Interview Questions 2026. For the framework design round that pairs naturally with BDD architecture, see Test Automation Framework Design Interview Questions. And for the CI/CD pipeline integration that Cucumber scenarios feed into, see CI/CD Pipeline Testing Interview Questions.
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