DEV Community: Zain Ul Rehman

17 SDET Interview Questions That Will Actually Be Asked in 2026

Zain Ul Rehman — Thu, 23 Apr 2026 20:25:34 +0000

How most SDET interviews are structured

Understanding the structure helps you prepare the right material for the right stage.

Stage 1 — Recruiter screening (15–30 min)
Your background, experience, and basic technical awareness. No coding here. Just be clear and confident about your stack.

Stage 2 — Technical phone screen (45–60 min)
Automation concepts and basic coding questions. This is where most candidates get screened out.

Stage 3 — Technical interview (60–90 min)
Live coding, framework design questions, system design for testing.

Stage 4 — Behavioural / final round
Team fit, communication, how you handle conflict with developers.

The questions — with real answers

Q1: What programming language do you use for test automation and why?

What interviewers want: A clear, justified choice — not "it depends."

Strong answer: I primarily use Python because of its readable syntax, strong ecosystem (pytest, requests, selenium), and growing demand in AI and automation roles. I have also worked with Java in enterprise environments where TestNG and Maven are the standard stack. The language matters less than framework design — I can adapt.

Q2: Explain the Page Object Model. Why is it important?

What interviewers want: A practical explanation, not a textbook definition.

Strong answer: POM separates page interactions from test logic. Each page in your application gets its own class that contains the locators and actions for that page. Tests import these classes and call methods rather than directly touching the browser.

When the UI changes, you update one page class — not every test that touches that page. That is the real value. Modern AI tools like Mabl are trying to eliminate this maintenance work with self-healing locators, but POM remains the industry standard for code-based frameworks.

Q3: What is the testing pyramid and how does it apply to your work?

Strong answer: The pyramid recommends many unit tests, fewer integration tests, and even fewer end-to-end tests. E2E tests are slower, more brittle, and more expensive to maintain.
As an SDET, I focus on integration and E2E automation while supporting developers in writing unit tests. I push back when teams want to over-invest in E2E coverage — flaky E2E tests erode trust in the entire test suite.

Q4: How do you handle file uploads in Selenium?

Strong answer: For standard HTML file input elements, Selenium handles uploads by sending the file path directly to the input element using send_keys. For custom components using JavaScript or third-party libraries, you may need to use execute_script to make the input visible before interacting with it.

file_input = driver.find_element(By.ID, "file-upload")
file_input.send_keys("/absolute/path/to/file.pdf")

Q5: Tell me about a time your automated test caught a bug before production.

What interviewers want: A specific real example using the STAR format.
Structure to use:

Situation: What were you testing and what was the context?
Task: What was your automation covering?
Action: What did the test flag specifically?
Result: What was the impact — how serious was the bug, what would have happened if it reached users?

Even if the bug was not catastrophic, emphasize that automation caught it faster than manual testing would have.

Q6: How do you decide what to automate and what not to automate?

Strong answer: I automate tests that are: run frequently (regression), stable in their requirements, time-consuming to run manually, and where human error is a real risk.

I do not automate: one-time tests, exploratory testing, tests requiring human judgement about subjective quality, and tests that change so frequently that maintenance cost exceeds the benefit.

The rule: if a test will be run more than 10 times and takes more than 5 minutes manually — automate it.

Q7: What is flaky test and how do you fix it?

Strong answer: A flaky test is one that passes sometimes and fails sometimes without any code change. The most common causes are:

Timing issues — element not ready when test tries to interact
Test data dependency — tests sharing state and polluting each other
Environment inconsistency — differences between local and CI
Dynamic content — IDs or classes that change on each page load

Fix approach: Add explicit waits (not sleep), isolate test data per test, investigate the failure pattern (does it always fail on CI? on certain browsers?), and add retry logic as a last resort — not a first resort.

What separates a good SDET interview answer from a great one

Good answers explain what. Great answers explain why and connect to impact.
"I use POM" is good.
"I use POM because it reduces maintenance cost when the UI changes, which I have seen save our team 2–3 hours per sprint cycle" is great.
Always connect your technical answers to a business outcome. That is what senior interviewers are evaluating.

Originally published with 10 more questions and detailed answers at aitestingguide.com

12 ChatGPT Prompts for Selenium Tests That Actually Work (2026)

Zain Ul Rehman — Thu, 16 Apr 2026 22:35:33 +0000

If you have ever stared at a blank test file not knowing where to start, ChatGPT prompts for Selenium tests can change your workflow completely.

In 2026, the best SDETs are not writing every line of automation code from scratch. They are using AI to accelerate test creation while applying their expertise to review and improve the output.

I have been doing this in my own SDET workflow for months. Here are the exact prompts I use — and the four rules that make them actually work.

4 rules before you start prompting

Before sharing the prompts, these four rules dramatically improve the quality of output:

1. Always specify your stack.
Mention Python or Java, Selenium 4, Pytest or TestNG, and any patterns like Page Object Model. Vague prompts produce generic code that needs heavy editing.

2. Give context about your application.
Tell ChatGPT what the page does, what elements are involved, what the expected behavior is. The more context, the more accurate the output.

3. Ask for one thing at a time.
Do not ask ChatGPT to write an entire framework in one prompt. Break it down — one page class, one test file, one utility function at a time.

4. Always review and test the output.
Never paste ChatGPT code directly into production without running it and understanding every line. This is non-negotiable.

The prompts

Prompt 1 — Browser setup and configuration

Use this when starting a new project and you need the initial browser configuration.

Write a Python Selenium 4 browser setup using pytest fixtures.
Include: Chrome WebDriver with ChromeDriverManager, headless mode option,
implicit wait of 10 seconds, and a teardown that closes the browser after
each test. Use the pytest conftest.py pattern.

What you get: A production-ready conftest.py with driver initialization and teardown. No more copy-pasting setup boilerplate across every new project.

Prompt 2 — Page Object Model class

Write a Python Selenium 4 Page Object Model class for a login page.
The page has: username field (id="username"), password field (id="password"),
submit button (id="login-btn"), error message (class="error-msg").
Include: explicit waits for each element, a login() method that takes
username and password as parameters, and a get_error_message() method.
Use pytest and inherit from a BasePage class.

What you get: A complete, clean POM class. Replace the locators with your actual application's element IDs and it works immediately.

Prompt 3 — Generating test cases from a POM class

I have a LoginPage POM class with these methods:
- login(username, password) — fills and submits the login form
- get_error_message() — returns the error text if login fails
- is_dashboard_visible() — returns True if login succeeded

Write a pytest test file with these scenarios:
1. Valid login redirects to dashboard
2. Invalid password shows error message
3. Empty username shows validation error
4. SQL injection in username field is handled safely

What you get: Four complete test cases with assertions, ready to run. You gave it the context — it writes the scenarios.

Prompt 4 — Locator strategy suggestions

I am testing a search feature. The search input has no ID or name attribute.
Available attributes: placeholder="Search products...", 
data-testid="search-input", class="search-field active".
Which Selenium locator strategy should I use and why?
Write the locator in Python Selenium 4 syntax.

What you get: A reasoned explanation of locator priority (data-testid is most stable) plus the exact Python syntax. Useful when you are dealing with poorly structured HTML.

Prompt 5 — CI/CD pipeline for test automation

Write a GitHub Actions workflow file that runs a Python Selenium test suite
on every push to the main branch. The workflow should:
- Use Ubuntu latest
- Install Python 3.11
- Install dependencies from requirements.txt
- Install Chrome browser
- Run pytest with HTML report generation
- Upload the HTML report as a workflow artifact

What you get: A complete, working GitHub Actions YAML file. Drop it into your .github/workflows/ folder and your tests run automatically on every push.

Prompt 6 — Converting manual test cases to automation

I have this manual test case:
Test: Verify product filter by price range
Steps:
1. Navigate to /products
2. Set minimum price to 50
3. Set maximum price to 200
4. Click Apply filter
5. Verify all displayed products show prices between 50 and 200

Convert this to a Python Selenium 4 test using pytest and POM pattern.
Assume a ProductPage class with a set_price_filter(min, max) method exists.

What you get: A direct translation from manual to automated — extremely useful when you have a large manual test suite to migrate.

The 3 mistakes that kill your results

Not providing locator information.
Generic prompts produce locators like By.ID("submit") that will not work in your application. Always provide real element attributes.

Accepting the first output without refinement.
ChatGPT's first response is a starting point. The best results come from two or three rounds of refinement. Say "this is good but make the waits explicit and add a try/except for StaleElementException."

Asking for too much at once.
Prompts that ask for an entire framework produce messy, inconsistent code. Small focused prompts produce clean, maintainable output.

The mindset shift

The most effective way to use ChatGPT in a professional SDET workflow is not to replace your coding — it is to eliminate the parts that are repetitive and time-consuming so you can focus on the parts that require real expertise.

Framework design, test strategy, coverage decisions — those still need a human. Boilerplate, repetitive test variations, CI/CD scaffolding — that is where ChatGPT saves you hours every week.

Originally published with more prompts and examples at aitestingguide.com