Automation testing practice that checks your work
Most interview preparation for QA and SDET roles stops at reading answers. That helps with definitions, but interviews increasingly include a live exercise: write a locator, fix a flaky test, query a database or test an API endpoint while someone watches. The only way to get comfortable with that is to write the code yourself and get honest feedback. Every lab on this page gives you that feedback, and each one says exactly how it checks your work.
How each lab grades your answer
- Executed: JavaScript coding challenges run your code against unit tests in a sandboxed Web Worker, and the SQL practice lab runs your query on SQLite in the browser, then again on altered data so a hard-coded result fails.
- Run against a demo app: Playwright test challenges run your spec on a Playwright-compatible runtime against a small shop app. Your tests must pass on the working app and fail on versions with planted bugs, which is how you know your assertions actually catch defects.
- Resolved against a real DOM: Playwright and Selenium locator challenges show exactly which elements your locator, XPath or CSS selector matches.
- Validated: Selenium Java snippets (waits, frames, page objects, TestNG) are checked against pattern rules. They are not compiled, and the challenge says so.
- Real requests: the API testing playground sends real HTTP requests to a practice REST API and checks the responses you actually received.
Where to start
If you are new to automation, begin with the beginner Playwright locator challenges or the first JavaScript challenge. They are short and teach the habits that later challenges build on: locating elements the way a user perceives them, and writing small functions that are easy to test.
If you already automate tests at work, go straight to the advanced challenges: fix a flaky cart test, find flaky tests in run history with SQL, or implement a retry helper for flaky async calls. These mirror the debugging conversations that senior SDET interviews are built around.
Combine practice with interview preparation
The labs and the SDET interview question bank are designed to be used together. When a question asks how Playwright auto-waiting works, the Playwright lab lets you see it; when a question asks how you would test an idempotent PUT endpoint, the playground lets you send the request. A practical weekly routine looks like this:
- Pick one topic, such as Playwright interview questions or API testing interview questions, and answer five questions aloud before revealing the model answers.
- Solve two or three lab challenges on the same topic, reading the explanation after each one even when you pass.
- Bookmark anything you got wrong and revisit it at the end of the week.
- Finish with a 30-minute SDET mock interview to practise answering under time pressure.
Fill the gaps with lessons and tools
If a challenge exposes a gap, the learning paths cover the underlying concepts in order, from software testing fundamentals to automation framework design. The free QA tools help with the supporting work: the XPath and CSS tester for selectors, the JSONPath tester for API responses and the cURL generator for turning requests into commands you can share.
Progress is saved in your browser, so you can close the tab and continue where you left off without creating an account.