You get a code editor, a live app and a terminal. Write a Playwright, Cypress or Selenium test, run it, and watch it click through the app. The way the job actually works.
Then we break the app on purpose to check your test would have caught the bug. Because a test that cannot fail is not a test.
No account needed. The editor opens with a working example.
Sign in to Nimbus
This is not a mockup of some other product, it's the starter file. Run this exact test yourself →
how-it-works
Not videos. Not slides. You write tests against software that behaves like the real thing, and every step of the loop happens right here.
choose-your-target
Most tutorials teach you on static demo pages, so the first real product breaks everything you learned. The Workbench apps behave like real products. A SaaS login, a storefront, a CRM, with loading delays, validation errors and state that changes while your test runs.
// on YouTube you test someone else's app, frozen in a video
SaaS login & auth
async sign-in · validation errors
E-commerce store
cart state · full checkout
CRM dashboard
~700ms saves · CRUD modals
write-it-yourself
A VS Code-grade editor with autocomplete for the Playwright, Cypress and Selenium APIs. You choose the locator, you pick the assertion, you run it from the terminal. The exact muscle memory a live interview checks for.
// copying from a course teaches your clipboard, not you
watch-it-run
Run it and watch the app respond: every element your test clicks or fills is highlighted in the live preview, with a step log of each action. When a selector matches the wrong element, you see it happen. The feedback loop that documentation can't give you.
// docs list the API, they can't show your selector missing
wrong selector? you see it match the wrong element, live
get-graded
Green does not mean good. So when you solve a problem, we run your test twice: once against the working app, then against a copy where we broke the exact behaviour you were asked to prove. If your test still passes, it was never really testing anything, and we tell you which behaviour you missed.
// no course, video or doc has ever checked your test this way
Challenge complete: Update cart quantities
Terra Supply · challenge 3 of 4
SaaS login & auth
async sign-in · validation errors
E-commerce store
cart state · full checkout
CRM dashboard
~700ms saves · CRUD modals
choose-your-target
which-framework
The question every beginner asks. Here is the honest answer, and you can change your mind any time, because all three run against the same apps here.
Start here if you're new
The most requested framework in current job posts, with a modern API. Our tutorials and starter files begin with it.
Try Playwright →For enterprise jobs
The long-time industry standard. If your target companies are large or their stack is older, they run Selenium.
Try Selenium →If the job post names it
Popular in product companies that adopted it early. The command-queue style is different, practice it before the interview.
Try Cypress →Still deciding? Read Playwright vs Cypress (8 min), or don't decide at all: run the same scenario in all three and feel the difference.
start-here
manual-tester
You already know what to test. That is the hard half. The missing half is expressing it in code. Start with the Playwright tutorial and write your first automated login test today, in the browser.
~30 min to your first green test
Start the Playwright tutorial →interview-soon
Practice the questions interviewers actually ask, waits, locators, flaky tests, with explanations for every answer. Then rehearse the live-coding part in the same kind of editor you’ll be tested in.
technical + pair coding · by level
Open your interview track →switching-tools
The fastest way to switch is contrast: run the same scenario against the same app in both frameworks. The concepts carry over. You just need the new syntax in your fingers.
same apps · 3 frameworks
Compare them side by side →try-one-now
This is question one from the SDET track, exactly as it appears in the interview section. Pick an answer and see how the explanations work.
Prefer to read first? The tutorials cover the same ground:
SDET track · question 01
Two questions, then you are writing a test. Hit Verify and find out whether it would really catch the bug , that's the whole method.
Start free →Your code and progress are saved in your browser.