A tester trainer
Working services with planted defects, a board of tasks and a request console — everything the way it is at work. You find a bug, you write a report, and an AI mentor reviews it like a senior developer: what does not add up, what to fix in the report itself and where to look next. It does not know the answer, so the find stays yours.
Completely free · every project included · progress is saved to your profile
Inside the workspace
These are views from the simulator itself, not stock images. Select a screen to open the full-size demo.
this is the workplace inside the stand
1 look at the product page
/products/15
Send
{ "product": { "id": 15, "title": "Thinking, Fast and Slow", "price": 1020, "stock": 0, "in_stock": false }}
2 put five copies in the cart
{ "product_id": 15, "quantity": 5}
{ "message": "Item added to the cart", "item": { "product_id": 15, "quantity": 5 }}
Why a video course does not get you an offer
Expected result
Watched the course to the end — you can test now.
Actual result
At the interview you are handed access to a service and asked to find a defect and write it up. In the course somebody else already did that, and did it beautifully. Watching a person find a bug and finding one yourself are different skills, like reviewing a chess game and playing at the board.
The course reviews the game well enough. Playing at the board it cannot give you: for that you need a service where there really is something to find, requirements to check the answer against, and someone to tell you whether you hit or missed. That is what the stand is: not lessons, but a working day.
Why you need this
Finding out whether you enjoy listening about the profession takes an evening. Finding out whether you enjoy doing it takes sitting down and hunting for a defect by hand. Here are three cases where the stand covers exactly what theory does not.
By the end of the first task you will know more about yourself than after ten hours of video: whether you enjoyed digging, whether you have the patience to check an answer against a requirement, whether you want to try once more from another angle.
what you get an answer to «is this for me» — before you sink half a year into the profession
Theory gives you the words: boundaries, equivalence classes, severity. Reading them takes an evening; understanding them takes your hands. Here they turn into actions: you send the value right at the edge yourself and watch the server answer something other than the requirement promised. After that the term stops slipping away.
what you get terms you have used with your own hands rather than memorised
The first thing they ask is how you tested and to show your bug report. Both pile up here — the history of your requests and dozens of reports, each with a note on why it was accepted or not.
what you get examples of your own work instead of «I took a course»
Nothing to install, and not a single line of code to write. You open it, read the requirements, send a request — from there it is down to attention.
What is inside
Only the service under test changes — the orientation, the About page, the board, Postman and the report form stay as they are. Once you have found your way around, the next project needs no relearning.
We start from zero: what a backend is, why it has no website and why you go to it directly. Unfamiliar words are underlined — hover over one and an explanation appears, exactly as on this page.
A description, acceptance criteria, a checklist, the statuses «to test» and «testing». It is the requirements that decide whether what you see is a bug or the intended behaviour.
Method, path, parameters, headers, body, an authorization tab — the way real Postman has it. Plus ready-made requests for every task, so there is somewhere to start.
A title, the steps, the expected and the actual result, the severity. In return — whether the report is accepted, a score for how it is written, and an explanation of what to fix.
How it works
Any trainer is easy to turn into a guessing game. Here that is closed off by how the stand is built, not by a plea not to peek.
The stand remembers every request you sent. Until the defect showed up in your own request, the report will not be accepted — even if everything in the form is picked correctly. Cycling through the dropdown will not work.
Eight simple checks: is the method named, are there concrete values, does the expected differ from the actual, and do the steps match the requests in your history. A sloppy report shows at once.
Every report is reviewed by an AI mentor: it explains what does not add up and where to look next. It does not know the right answers — the list of defects is never shown to it. So you can ask «why was it not accepted» as many times as you like: you will get a hint, never a ready answer.
Who it is for
There is no single “right” user: some are choosing a career, some are preparing for a first interview, and others are filling gaps before moving to Middle QA.
Alex knows the terms but has not tested independently. The shop project turns requirements, requests and evidence-based bug reports into one repeatable workflow.
Sam rehearses the practical part: HTTP methods, status codes, boundary checks and a clear explanation of why the service response is wrong.
Jordan wants to learn whether QA fits before buying a long course. One task quickly shows whether finding discrepancies is engaging in practice.
Taylor already knows how to investigate customer issues. The simulator turns that skill into reproducible steps, expected results and severity decisions.
Morgan is comfortable with interfaces but avoids APIs. Prepared requests make authentication, validation and access-control checks less intimidating.
Chris refreshes test design on a running service: equivalence classes, boundaries, negative scenarios and business-rule checks.
Jamie works through bank, CRM and iGaming cases that cross several resources. The task is to reason about data, roles and consequences, not only status codes.
Robin uses a repeatable stand for reviews. Requests and reports are saved, so the conversation stays anchored in concrete decisions rather than abstract theory.
What you learn
Products differ, but things break in much the same ways. So the tasks are grouped not by storyline but by kind of breakage — and you go through each kind across several business products in a row. That is the skill: recognising a familiar breakage in an unfamiliar product. Below is what you will be checking; what exactly is broken there, you find yourself.
What happens if you send an empty field, a zero, a minus, a string that is too long, or the wrong format. The most common thing, and where people start at work.
What a stranger can see and what they can do. Finds here are worth the most, and they are simpler to check than they look.
The service answers without errors, but does something other than the requirements say. Caught only by reading the acceptance criteria.
The numbers do not add up with each other. To catch it you have to compare two answers and count yourself — by eye it is invisible.
Restrictions that do not actually restrict. Checked right at the boundary: one less, exactly that, one more.
How the service fails rather than what it computes. Is the status code right, is the right field named in the error, did the internals leak out. Checked on broken requests, not on correct ones.
Inside a project the tasks go from simple to hard, but they are never locked: stuck — move to the next one and come back. Progress lives on the server: you can close the tab, return a month later and carry on from the same place.
Access
Every current project, theory section and future module is available without a subscription or payment. Create a profile, confirm your email, and start immediately.
Freefor every learner
no card, trial period or recurring charge
Questions
No, not a single line of code. A tester sends requests and reads answers — that is closer to careful reading than to development. Everything you need to know is explained in the orientation from scratch.
That is the point. The first screen explains what a backend is and why it has no website, every unfamiliar word is underlined and opens on a click, and every task comes with a checklist and a hint. You will send your first request within the first ten minutes.
About a month at an hour a day. There is no rush: access is free, progress does not expire, and new modules keep arriving.
A real one. Live requests, status codes, token authorization, limits on file size and how often you may act. The defects are planted on purpose — everything else works the way it does for everyone.
That is exactly how the first day goes, and it is normal. The report will not be accepted, but you will be told what does not add up and where to look, without being given the answer. Tasks are never locked: you can move to another and come back.
The interface is Russian, English and Vietnamese, switched on the fly. The services themselves answer in English and are not translated: real services speak English, and it is better to get used to that at once.
The platform keeps being built, and new sections open to everyone for free: theory with check questions, real interview drills and more business-product projects. It grows while you use it, and your progress remains available when you return.
Email confirms that the profile belongs to you and lets you continue on another device. It is not a payment step and does not add you to a newsletter.
If you need a person
The stand covers the practice. But some questions are answered only by a live conversation: where to go next, what to put in a CV, why they do not call you back for a second round. Write to us and describe what you need.
We go through whatever you are stuck on: how to approach an unfamiliar service, what to check first, why your report keeps being rejected.
The CV, the applications, where first offers actually come from, and what to do when you have no experience and every vacancy asks for a year of it.
We go through real questions out loud: the technical part, tasks on the spot, and a review of how you answer.