02 · Learner — Tests & Workspace

Preconditions

Signed in as any learner on a computer.

Steps

1. Open Mock Tests under Assessments in the navigation.
2. Read the lead line and every paper card, top to bottom.

Expected

• Heading Mock Tests; lead: "Timed tests on one subject or several, to see where you stand. Each is taken once, on a computer. 4 published." and a Your mock tests link to your results.
• Each card: its category in the eyebrow (Featured on Python Foundations and Data Structures Essentials), title, difficulty, a line on what it covers.
• Facts two to a row: Questions ("17 questions in 3 sections" on Programming Fundamentals), Time ("45 minutes"), Marks, and Strictness in plain words — Programming Fundamentals reads "Strict · leaving the test is recorded and can end it"; the others "Standard · leaving the test is recorded".
• At each card's foot: your standing (Not taken yet on an untaken paper) and one next action (Start).
• Featured papers come first, then the most recently updated; nothing shows a zero count or an empty fact.

Also try

• Open the page fresh from a bookmark/direct link — the catalogue loads directly.
• Kestrelworks' card on Company Tests shows the third strictness line: "Off · nothing about how you take the test is recorded".

Steps

1. On Mock Tests, type "SQL" in Search mock tests ("Search by title or what it covers"). Clear it.
2. Open Filters, choose difficulty medium, then a category; read the applied chips.
3. Choose a category+difficulty pair that matches nothing. Clear with the control offered.
4. Choose difficulty medium again, navigate to another page, then return to Mock Tests from the navigation. Check the address bar.

Expected

• Search narrows the cards to matches as you type; clearing restores.
• Each chosen filter shows as a removable chip under the bar (e.g. "medium", "SQL"); removing a chip un-narrows the list.
• Nothing matching: Nothing matches with a way to clear the filters — never an empty grid presented as the full catalogue.
• Category and difficulty stay applied after you leave and return — they are kept in the address and remembered on this device until sign-out. The search text is not kept: it is gone when you come back.

Also try

• Reload the page with filters in the address — they reapply from the URL.
• Open the same address in a second browser — the device-kept filters follow it.

Preconditions

One account per standing: an account mid-test (In progress), one with a test past its time not yet ended (Overdue), one with a test being marked (Grading), and finished tests (score + Passed/Not passed). Stage them gradually as your plan's tests run.

Steps

1. As each state exists, open Mock Tests and read the card's foot.
2. Compare the action offered at each state.

Expected

• Untaken: "Not taken yet" + Start. In progress: In progress + Resume. Past time unended: Overdue. Being marked: Grading (no score shown). Final: "Your score" + percentage + Passed/Not passed + View result and Practice.
• Exactly one primary action per card — never Start beside Resume.
• The standing is the latest test on the paper; an earlier replaced result is not what the card shows.

Also try

• On a phone/tablet (or a narrow device profile in dev tools): the card still reads its standing but Start reads "Taken on a computer" and Resume "In progress: carry on on a computer".

Preconditions

A test you started and left without submitting (leave via Leave, not by closing mid-answer).

Steps

1. Open Mock Tests (or Company Tests for a company test).
2. Read the strip at the top of the page; press Resume.

Expected

• A strip names the test: "{paper title} is in progress. Time is up at {deadline IST}." with Resume.
• Resume returns to the same test at the same question, the clock still counting from where it was — never a new test.
• While it runs, every other paper's Start is refused with "Another test is in progress. Resume it" linking back.

Also try

• On a touch device the strip reads "Carry on on a computer; its clock keeps running." with no Resume.

Preconditions

A paper whose availability is closed or not yet open, or an archived paper, if the seed includes one; otherwise note N/A. A second account with a live test for the at-limit line.

Steps

1. Read the foot of a paper you cannot start: not yet open, closed, archived, taken, or while another test is in progress.

Expected

• Not yet open: "Opens {date, time IST}". Closed: "Closed". Archived: "Archived". Taken: View result (+ Practice where it opens).
• At the live-test limit: "Another test is in progress. Resume it" — a link to the live test, not a Start button.
• Each is a clear reason, never a disabled Start with no explanation and never an apparently usable Start.

Steps

1. Open Programming Fundamentals from the catalogue. Read the whole page top to bottom.
2. Do the same on Python Foundations and compare the "How it works" parts.

Expected

• Mock Tests as the way back; the title; Mock Test kind; category and difficulty; the facts: questions, time, marks, whether wrong answers lose marks, the pass mark and the strictness.
• About the paper with the description — Programming Fundamentals says "Three sections, 17 questions, 45 minutes… Strict: leaving the test's tab is recorded, and the fifth time ends the test." — and when it was last updated.
• Sections: Logic and numbers, Objects and functions, Programs — each numbered with its questions, marks, a suggested time and its briefing.
• How it works, in parts on time, marking, moving through the paper and what is recorded: the clock does not pause; answers are saved as you give them; "You pass with 50% of the marks."; one line for each of the paper's navigation rules.
• "What is recorded" differs honestly by paper: Standard papers say "You are told each time. Recorded events never end the test."; Programming Fundamentals says "You are told each time. At 5 recorded, the test submits itself with the answers saved by then."
• Beside it, Before you start: "Each test is taken once. It is taken on a computer, not a phone or tablet." and when it can be started.
• Nothing starts a test or a timer by opening the page.

Steps

1. On each Mock paper's page, find the lines in How it works describing how you move through the paper.
2. Compare with what you see inside the test later (doc §2).

Expected

• One line for each of the paper's six features, stated as it applies — e.g. on the seed papers (all features on): "The time left is shown throughout.", "A grid of numbered questions shows where you are and what you have answered.", "You can mark a question to come back to. Marking is not answering.", "You can move on without answering.", "You can go back to questions you have already seen.", "You can move between sections."
• Where a feature is off on a paper (staff-made variants), its line says so plainly — e.g. "The time left is not shown, but the time limit still applies.", "You answer each question before moving on to the next.", "A question closes once you move away from it."
• Nothing here is discovered only inside the test: every restriction is disclosed before Start.

Steps

1. Read the Before you start list on an open paper: "It can be started at any time." (or "It can be started until {when}. A test started before then runs its full time." / "It opens {when}." where a window is set).
2. If a learner has agreed extra time (a staff accommodation), open a paper as them.
3. If staff archived a paper you can open, read its page.

Expected

• The availability line matches the paper's window; no invented deadline where none is set.
• Extra time shows as an info line, e.g. "1 hour 30 minutes, including agreed extra time: twice the usual 45 minutes."
• An archived paper's page still opens and says "This paper is archived, so it cannot be started." in place of when it can be; a relief grant holder also reads "Your relief grant on it can no longer be used."
• A never-published or unknown paper address gives the same plain not-found as anything missing — it does not say whether it exists.

Steps

1. Open an untaken paper's page on a computer and watch Systems check under Before you start — do not press anything until it finishes.
2. Open Show the checks. Press Check again.

Expected

• "This checks this computer and the test's services. Nothing starts here." then "Checking this computer…" then a one-line result: "This computer is ready · N checks passed" on a healthy computer.
• Show the checks lists each item as Passed, Warning or Could not check: Connection; Saving answers and reading them back; This computer's clock; This browser; Keeping answers on this computer; Screen and pointer; Running code on a paper with programs (Python Foundations, Programming Fundamentals, company papers with coding); Full screen on Tamarind Grove's paper.
• The list opens by itself when anything did not pass.
• No camera, microphone, screen sharing or file access is requested at any point — that is by design, not a missing step.
• No test, timer or charge is created: the paper still offers Start afterwards, and your results list gains no row.

Steps

1. Make the browser window narrow (under about 1,024 px wide) and press Check again.
2. Read the summary and the conditions area; try to start without ticking.
3. Widen again and re-check until all pass.
4. If any item ever shows Could not check (e.g. connection down), try Start.

Expected

• Screen and pointer shows Warning: "The window is small, or there is no mouse or trackpad. The test is easiest on a full-size window with a keyboard and pointer."
• Summary: "This computer can take the test · 1 warning to accept". The conditions show the warning in a "The systems check warned about" note ending "You can still take the test if you accept this."
• A tick box appears: "I accept these conditions and the warning above" — the Start button waits for the tick. With all checks passed there is no box: one press, "Accept the conditions and start".
• Could not check is not a warning: "The test can start once every item can be checked." and Start stays unavailable — you cannot tick your way past it.
• A clock warning reads "This computer's clock is out by more than half a minute. The test keeps its own time, so the time left shown is still right." — it does not invent a failed check.

Also try

• Disconnect and Check again: Connection and Saving answers show Could not check with their own words.

Steps

1. On a paper's page, let the check pass, then sit on the page over 10 minutes without starting; look at the check and at Start.
2. Press Check again more than six times inside a minute.

Expected

• After ~10 minutes the check reads "This check has run out." with Check again; Start waits for a fresh check.
• Past six checks in a minute the panel says how many seconds until it can run again — it does not silently fail or hammer the api.
• Checking again re-runs the whole check (a check is held only while the page is open; arriving again checks again).

Steps

1. Open /papers/:paper/preflight for a Mock paper (use its address from the catalogue link).
2. Open /papers/:paper/acknowledgement.
3. Do the same against a Company paper's address.

Expected

• Preflight lands on the paper's own page with the systems check in view; acknowledgement lands at the conditions and Start.
• On a Company paper both addresses open its briefing at those parts — never a Mock page.
• A Mock paper's /briefing address opens its page, and a Company paper's plain /papers/:paper address opens its briefing — the two never mix.

Steps

1. On a fresh account, open Python Foundations, wait for the check to pass, and read the conditions beside Start — do not start yet.
2. Compare with a Strict paper (Programming Fundamentals) and the Off paper (Kestrelworks).

Expected

• "Read these conditions before starting, then start the test when you are ready." followed by the true list, e.g.: "Each test is taken once; its result is the one that counts." · "The clock starts when you accept and does not pause. Time is up at {deadline, ~45 min from now}." · "Your answers are saved as you give them, and submitting is final." · "You can leave and come back until the time is up; the clock keeps running." · "Only one test can be in progress at a time, whatever the device." · "If you sign in on another device while a test is in progress, it keeps running and you continue there." · "You can't hand the test to anyone else."
• On Standard: "Leaving the test page is recorded; recorded events do not end the test." On Strict: "…and at {N} recorded events the test submits itself." On Off: nothing about recording appears at all.
• One action: Accept the conditions and start — the wording makes clear what pressing it does.

Preconditions

Stage as many as your plan allows: an account with a live test; an unpublished/archived paper (staff-made); a phone or narrow device; a stale systems check (>10 min).

Steps

1. Try to reach Start on each refused path: another test in progress; a paper that is not published; on a touch device; with a run-out check.

Expected

• Live test elsewhere: "Another test is in progress. Resume it" — a link to the live test, never a second Start.
• Not published/archived: the page explains that state plainly; an archived paper adds "Your relief grant on it can no longer be used." where a grant exists.
• Touch device: "Tests are taken on a computer. Open this test on one to check it and start." — no systems check, no Start.
• Stale check: "This check has run out." — Start waits; re-checking restores it.
• In every refusal there is no fake Start, no silent failure and no test created: your history gains no row.

Also try

• Where a declared maintenance window covers a coding paper's grading, the page names it and Start does not offer — "Grading for the programs in this paper pauses {when}."

Preconditions

An account willing to spend its one test on a paper (use SQL Queries — cheapest, 40 min). You will keep this test running for the room cases, so pick the plan's designated test account.

Steps

1. Press Accept the conditions and start once. Before it completes, press it again / hit Enter again.
2. In a second account on its paper page, open the page in two tabs and press Start in both nearly together.
3. Check Test results for that account.

Expected

• One press lands you in the test room at the paper's first question; the clock is running from that moment.
• A second press mid-start changes nothing — one test is created or resumed, never duplicated.
• Two tabs both land in the same test. History lists exactly one in-progress row.
• Start records the time the deadline is counted from — "Time is up at {deadline}" matches duration from the press, not from page-open.

Also try

• Reload mid-start: the test still lands intact.

Preconditions

Staff cooperation: they hold a draft edit (title/section/question/marks change) on a paper a tester is mid-test on. If you cannot coordinate this, mark N/A.

Steps

1. Start the paper's test. Ask staff to publish an edit to the paper while the test runs.
2. Continue the test; finish it; read the result.

Expected

• The running test keeps its original questions, sections, marks and settings to the end — nothing mid-test changes shape.
• The result grades against the frozen copy and is still reviewable against what the learner actually saw.
• The paper's catalogue card meanwhile shows the updated facts for anyone yet to start.

Steps

1. Open Company Tests. Read the lead and the four company cards.
2. Search "kestrel", clear it, search a string matching nothing.

Expected

• Heading Company Tests; a lead naming what these are (tests in the style of real companies, with no pass mark) plus a link to Your company tests.
• Each card: company name, what it does, the roles its tests are for, the number of papers, and your readiness or "Not tested yet".
• Search narrows by company name only; a miss shows a nothing-matches state with a clear — never an empty grid.

Also try

• After taking tests, the card shows your readiness band and recent standing instead of "Not tested yet".

Steps

1. Open Northvale Systems. Read the page fully: roles, papers, readiness, recent tests.
2. Open Corvane Software and compare.

Expected

• Way back to Company Tests; name, description, the roles its papers are for.
• Paper cards show role, year and Pattern; untaken papers list first, then your taken ones. Card facts include questions, sections, minutes, strictness.
• "Your readiness" is per role — untested reads as not enough evidence, never zero.
• Two honest disclaimers appear in words like: "The company does not run or endorse this test, and your result is never shared with it." and "Never a prediction of being hired."
• A "None yet" style line where you have no tests at that company — not an empty list.

Steps

1. Open Northvale's Associate Software Engineer (Strict, limit 3) briefing at /papers/:paper/briefing. Read top to bottom.
2. Compare with Kestrelworks' Software Developer Intern (strictness Off).

Expected

• Way back to the company page (Company Tests in the navigation is lit, not Mock Tests); title; Company Test kind; the company, role, year and Pattern label; the paper's own briefing text.
• Facts include questions, sections, minutes — and honestly no pass mark and no rewards.
• "How it works" for a company paper says its sections are taken one at a time — a section closes behind you and cannot be re-entered.
• The strictness lines match the paper: the Associate paper says at 3 recorded the test submits itself; Kestrelworks says nothing is recorded about how you take the test.
• Then the same systems check, conditions and single Start as a Mock paper — including the run limits disclosure where a paper has one ("Runs in this section are limited: 10."/"15.").

Steps

1. Open /company-tests/not-a-company directly.
2. If staff have a company with every paper unpublished, open its address.

Expected

• An unknown company address gives the plain not-found — same shape as any missing page, never revealing whether it exists.
• A company you cannot take tests at is not listed as an empty card in the catalogue.

Preconditions

An account with a mix: one finished Mock, one finished Company test, one in progress if available.

Steps

1. Open Test results (/test-results). Read the heading line and each row.
2. Switch the type control: Both / Mock Tests / Company Tests. Open the "Where it stands" filter and try each state.

Expected

• Title "Test results" with a count sentence in the lead and "Every Mock and Company Test of yours, newest first."; a ghost link to Assessments dashboard.
• Each row: title; kind word (Mock Test / Company Test); "Started {date, time IST}"; where it ended adds a plain line — "Time ran out", "Ended at its limit of recorded events", "Replaced by a newer test" (muted), an invalidation reason.
• Trailing: a finished test shows "X of Y marks", the percentage and Passed/Not passed (Mock only — Company rows never show a pass state); a non-final row shows its state word instead (In progress · Overdue · Grading), never a score.
• Type switching and the standing filter (All / In progress / Being marked / Finished) both work and are remembered in the address; no matches reads "None of your tests matches these filters" with a clear.
• An in-progress row opens the room; every other row opens its result. On touch, in-progress rows show "Carry on on a computer" and don't open.

Steps

1. Open /mock-tests/history and /company-tests/history directly.
2. Open them from each catalogue's "Your mock tests"/"Your company tests" link.

Expected

• Each address opens Test results already switched to that type: "Every Mock Test of yours, newest first." / "Every Company Test of yours, newest first." — the segmented control shows the choice and can be changed.
• With nothing there: "No mock tests yet" / "No company tests yet" with links to both catalogues — never a bare zero.

Preconditions

One account with several finished tests of each type; one fresh account with none.

Steps

1. Open /tests-dashboard on both accounts.
2. Compare each region between them.

Expected

• Regions: Score trends (Mock and Company separately), Strengths, Coming up, What to do next, recent results, and a this-month line.
• Mock trends show score/per cent; Company trends show marks and the readiness figure where there is one.
• On the empty account each region says its own honest "nothing yet" — "No company tested yet", no invented flatline at zero, no fake next action.
• "What to do next" offers real actions (papers to take, a test to resume) that navigate correctly.
• A live test is surfaced here too, consistent with the catalogue strip.

Preconditions

A running Standard Mock test (e.g. SQL Queries).

Steps

1. Look at the whole page at ≥1024px: top strip, question, navigator.
2. Look for anything that is not the test: site navigation, header, footer, companion, inbox, any help panel.

Expected

• No normal shell: no product navigation, no footer, no inbox/bell, no companion — the test is the whole page.
• Top strip: Leave; the paper's name; each section as a tab with its answered count ("3/7"); Recorded events for Standard/Strict; the remaining time.
• Where a paper hides the countdown, the timer area says so honestly rather than faking a clock — the deadline still applies.
• No "Ask for help", AI-help or credit-style control exists anywhere in the room (generated assistance is off platform-wide).

Steps

1. In the running test, open the navigator and read it fully.
2. Answer a question, mark one for review, close a section on a company test (later), then re-read the grid.

Expected

• The grid shows every question in the section with a state that is not colour alone: answered carries a mark, marked-for-review a flag, closed a lock, the current question is outlined.
• A legend or labels make the marks plain; a count line reads "N of M answered" for the section and the whole paper.
• Submit test sits in the navigator; the Single-key shortcuts switch sits there too, on by default.
• The whole-paper line reads e.g. "Whole paper 4 of 17 answered · 1 marked".

Steps

1. Narrow the window below 1024px while a test runs.
2. Open the questions from the "N/M answered" control.
3. Pick a question from the sheet.

Expected

• The grid leaves the side and opens as a sheet over the question; the count control reads "N/M answered. Open the questions" in meaning.
• Choosing a question in the sheet lands on it and closes the sheet.
• Answers, time and recorded events keep working; the test is not abandoned by narrowing.

Steps

1. Read the first question of each section on SQL Queries or Python Foundations.
2. Open "About this section" on a section's first question.

Expected

• Each question heads "{section} · {kind} · {marks}" and "Question N of M".
• A kind hint matches the control: "Choose one answer." / "Choose every answer that applies." / "Enter a number."
• Where the paper deducts for a wrong answer, the question says so: "A wrong answer loses 0.25 marks." (Programming Fundamentals, Northvale's aptitude/reasoning) — and where it doesn't, nothing implies a penalty.
• The section's first question offers "About this section" with the section's briefing; later questions don't repeat it.
• Foot controls: Previous · Mark for review · Next (or "Next section"/"Review and submit" at the ends) plus the shortcut key line where shortcuts are on.

Steps

1. Walk to the last question of a section, then the last of the paper.
2. Walk back to the first question.

Expected

• At a section's end the forward control reads Next section where more remain, or Review and submit at the paper's last.
• At the paper's first question, Previous is absent or inert — never a dead button that pretends to move.
• Words never promise a move the settings forbid (no "Next section" on a section-locked company paper beyond its end).

Steps

1. Watch the countdown through a minute boundary and under 5 minutes (a 40-minute test reaches this; or watch the last minutes of a short company paper).
2. If a staff-made paper hides the countdown, check its room.

Expected

• The countdown matches the announced deadline, not wall-clock guesses — it never pauses, never gains time on reload.
• Under five minutes it is visibly marked (a warning treatment) without blocking the question.
• Where countdown display is off for a paper, the room says the clock is hidden and the limit still applies — no invented "unlimited".

Steps

1. On a single-choice question choose an option; then Clear my answer; then choose again.
2. On a multi-select ("Choose every answer that applies") tick two options, then untick one, then untick all.
3. On a true/false question pick each answer in turn.

Expected

• Choice answers save as you choose: "Saving…" then Saved beside the question — no separate save step.
• Clearing saves the question as unanswered; the navigator's answered count drops and the cell loses its answered mark.
• A multi-select with nothing ticked is unanswered — the question says so plainly, not as a wrong-looking state.
• Choosing another single-choice option replaces the saved answer; only the newest choice is kept.

Steps

1. On a numerical question type letters and symbols.
2. Type a number; clear it; type a decimal; leave it.

Expected

• Non-numbers are refused in the field or named plainly ("Give a number.") — and are not sent as an answer.
• A typed number waits a beat, then saves ("Saved"); clearing returns the question to unanswered.
• The field gives no hint of the grading tolerance — nothing shows "within 0.001" or the expected value.

Steps

1. Walk a full paper and note the kinds it contains — single-choice, multi-select, true/false, numerical, code (company coding sections, Mock "Programs" sections).
2. Check the kind word in each heading matches the control offered.

Expected

• The kind in the heading names the control: a "single choice" question offers one-of options; "multi-select" offers toggles; a coding question offers the editor (§2.5).
• No question renders broken, empty or with options from another question.
• Marks shown per question match the section totals on the paper page.

Steps

1. Watch the answer state through a normal save.
2. Dev tools → network offline; answer a question and read the state; press Retry.
3. Come back online and watch it.

Expected

• Healthy save: "Saving…" → "Saved". A question never answered reads "Not answered yet".
• Offline: the answer is kept on the device and reads Saved locally with a real Retry; on reconnect it sends itself and flips to "Saved" — no re-answering needed.
• A refused send (service down, not just offline) reads Not saved with Retry — the answer stays on screen and is never lost silently.
• Whatever the state, the words are the real state — never "Saved" for something still only on the device.

Steps

1. Type a numerical answer and press Next inside the same second; go back and check it saved.
2. Type, then immediately press Submit (through the dialog); check the result's review.
3. Type, then hide the tab or reload instantly; return and check.

Expected

• Outstanding typing is flushed before navigation, submit, deadline, tab-hiding and close — what you typed arrives, not only what had already saved.
• On return the answer is there, saved — not replayed as unsent typing.
• A send that still hasn't landed by the deadline reads "Not saved: it arrived after time was up" — honestly late, never a false "Saved".

Steps

1. Answer two questions, mark one, move to a third; reload the page.
2. Note the question you land on, the saved states, and the clock before/after.

Expected

• You land back where you were (same question), answers and marks intact, each reading its real save state.
• The clock kept counting while the page was down — you never gain time by reloading.
• On Standard/Strict the refresh is recorded for staff but never counted — the recorded-events number does not move and no note warns you.

Steps

1. Open the running test in a second tab. In tab 2 answer a question and move forward; leave tab 1 sitting on an older question.
2. In tab 1 type an answer and try to move.

Expected

• The stale tab announces itself: "This test had moved on in another tab or window. This page now shows where it is and the answers it holds." — then it shows the current question with its real saved state.
• A device-only answer the newer tab refuses is discarded so it cannot be sent later — it does not pop back.
• An older delivery never overwrites a newer answer: the newest answer the test holds is what survives.

Also try

• Submit in one tab — the other tab sees the test ended and moves to the result, never offers a second submit.

Steps

1. Cut the network mid-test for a minute; answer a question offline; restore.
2. Watch the save state and the clock throughout.

Expected

• The test is not ended by a lost connection — the room stays usable where it can, answers go to "Saved locally", and sends resume on return.
• The clock keeps running from the deadline — connection loss is never extra time and never counted as a recorded event.
• Where the room can't proceed safely it says so plainly rather than pretending answers saved.

Preconditions

Two computers/browsers, the same learner account on both (this is the one case where one account in two places is the point).

Steps

1. Start a test on browser A; answer a question; let it save.
2. Sign in to the same account on browser B; open the test's address there.
3. Look at browser A, then continue on B.

Expected

• Browser A's session ends with the usual "opened on another browser or device" notice — but the test is not ended and its clock kept running.
• Browser B resumes the same test at the latest position with saved answers; unsent device answers that couldn't move stay on A honestly.
• On Standard/Strict the move is recorded for staff and never counted — the event count does not rise for it.

Steps

1. With the shortcut switch on: press B on a choice question; N to advance; P to go back; M on a markable question.
2. On the last question press N. Dismiss.
3. Hold Ctrl/Alt/Meta and press N; type in a number field then press N while focused; open the submit dialog and press keys.
4. Turn Single-key shortcuts off in the navigator and press the same keys.

Expected

• Letters/digits choose options (A–H or 1–8 by option count); N moves forward — on the final question it opens the Submit view; P moves back; M toggles mark-for-review where the paper allows it.
• Keys are inert while a modifier is held, while typing in a field or the code editor, and while a dialog is open.
• With the switch off the keys do nothing; the switch's choice is kept on this device until sign-out.
• A shortcut can never bypass a disabled feature — M does nothing where marking is off for the paper.

Steps

1. Mark two questions for review; answer one of them.
2. Open the navigator and the Submit dialog; read the marked counts.
3. Unmark one via its control.

Expected

• Marked questions carry the flag in the grid and on the question; marking does not answer, and answering a marked question keeps both states.
• The submit dialog counts them separately ("2 marked") and offers to go to the first marked question.
• Unmarking removes the flag everywhere at once.

Preconditions

A seed paper (all features on) plus a staff-made variant with skip/revisit off if your plan has one; mark N/A where not staged.

Steps

1. On a normal paper: leave a question unanswered and Next past it; jump to it from the grid; answer and return.
2. On the variant: try to move forward unanswered; answer, then try to go back.

Expected

• Normal: forward movement never requires an answer; the grid jumps anywhere open; answered questions stay editable.
• Skip off: the forward control refuses while unanswered and says so — yet permitted backward/section moves still work.
• Revisit off: once you leave a question it locks — grid cell and controls show it closed, and nothing (keys included) reopens it.

Steps

1. On a multi-section Mock, switch sections from the strip; note where each lands.
2. Exceed a section's suggested time (its paper page listed one) without leaving.

Expected

• Switching lands on that section's first open question — not always question 1, not a blank.
• Suggested section time is guidance: nothing auto-advances or closes a section at it.
• On a section-locked company paper, closed sections cannot be re-entered by any route — strip, grid or keys (see TC-TST-024).

Steps

1. Answer a shuffled-order question; reload; check the order and your answer. Compare with the same question on a second account.

Expected

• Where the paper shuffles questions/options, each learner's order can differ — but the question text, options' meaning and your saved answers follow the content, not the position.
• Reload never re-deals your order mid-test.

Preconditions

A paper with a coding section — Python Foundations' "Programs", Northvale Graduate Engineer Trainee's "Coding", or Programming Fundamentals' "Programs".

Steps

1. Reach a coding question; read its pane fully.
2. Switch its language tab; type in each.

Expected

• The question pane shows the description, each example with its input and expected output, and a line like "Graded on these examples and N hidden test cases after the test."
• Language tabs are offered where the question allows several; a line says only the language shown is saved and graded.
• The editor loads only when a coding question is drawn — it does not pre-load on other questions.
• Hidden test cases show nothing: no inputs, no expected output, no hint of content — the number alone.

Steps

1. Write code in the first language tab; switch to a second tab and write different code.
2. Switch back. Leave the question and return.
3. Note which tab shows the save state.

Expected

• Each tab keeps its own code while the page is open — switching never copies or loses it.
• Only the shown language is the saved answer: its tab carries the save state, and the result reviews that language's code.
• Code saves like other answers (held briefly, then sent); the state words are the same ladder as §2.3.

Steps

1. On a coding question press Run the examples; read the results beside the output.
2. On a limited paper (Northvale Trainee: 10; Tamarind: 15) run until near the limit; make a run fail (empty code / a pace refusal) and watch the count.
3. On an unlimited paper note its line.

Expected

• Results appear per example beside the output — pass/fail each, against visible cases only.
• A limited section shows "N runs left in this section." — a started run spends one; at zero it says "No runs left in this section. Your code is still saved and graded."
• An unlimited one says "Runs in this section are unlimited." — practice is always unlimited.
• A refused start spends nothing: empty code is named ("the code is empty" in meaning) and a run-pace refusal says how long to wait — the count doesn't drop.
• Running reveals nothing hidden: output is only for the visible examples.

Preconditions

A company test in progress (every seed company paper is section-locked) — e.g. Corvane Data Analyst Trainee.

Steps

1. Answer in section one, then advance via Next section. Read the prompt; confirm.
2. Try to return: section tab, grid cell, Previous, keys.
3. Advance repeatedly across the paper.

Expected

• The advance prompt warns plainly — "{section} closes, and you can't come back to it." plus the count unanswered — with a way to stay ("Stay in {section}") and to move.
• After advancing, the closed section's tab shows a lock and its questions are unreachable by every route; attempts say which section is active.
• Only the active section and the adjacent advance are ever reachable — you cannot skip ahead two sections.
• Repeated advances count once each — the paper's structure (sections, questions, order) never collapses into one list.

Preconditions

A running test. A second tab on the same account.

Steps

1. While the test runs, open other learner pages in the second tab: a Challenge's hints/editorial, Code Lab, Quick Notes, My Solutions' compare.
2. Note what each says; end the test and re-check one.

Expected

• Spoiler-adjacent things close while a test is live — hints, editorials, compare, Quick Notes, outside-help and problem-reporting controls say why and when they return, never opening quietly.
• Ordinary practice still opens where it doesn't spoil — but anything that would feed the live test is held.
• On a recorded test (Standard/Strict) leaving the room for these pages is itself recorded — the restriction and the recording are consistent.
• Nothing in the room offers generated help, companion messages or problem reporting while the test runs.

Preconditions

A running Kestrelworks Software Developer Intern test.

Steps

1. Hide the tab, switch away, return; reload; use the clipboard.
2. Watch the strip and look for any recorded-event surface; finish and read the result.

Expected

• No recorded-events indicator in the strip at all — the paper told you before Start that nothing is recorded, and it isn't.
• No notes, no counts, no "Recorded:" line; leaving and returning is invisible to the room.
• The result's ending reason is your own (submitted / time ran out) — never a recording reason.

Preconditions

A running Standard test (e.g. SQL Queries).

Steps

1. Switch to another tab for a few seconds, return.
2. Read the note; acknowledge it; check the strip.
3. Do it twice more; try leaving via Leave and via closing the tab.

Expected

• On return a note names what happened — "Recorded: The test page was hidden or left." plus "N recorded so far. This never ends the test." — and stays until you dismiss it (OK).
• The strip's Recorded events count rises one per leaving; leaving via Leave and via closing both count once each.
• Nothing about the test changes: same question, answers, clock — recording is all that happened.
• Past any number of leavings the test continues — there is no hidden ceiling on Standard.

Preconditions

A running Northvale Associate test (ceiling 3) — the cheapest Strict spend. This spends the account's test; plan it as that account's test.

Steps

1. Leave/return three counted times (spread beyond two seconds each); read each note and the strip count.
2. At the third, watch the test end; open the result.

Expected

• The strip reads "Recorded events: N of 3" — the ceiling is visible throughout, not a surprise.
• Each note says what counted and the consequence: "N of 3 recorded. At 3, the test submits itself."
• At the ceiling the test submits itself with the answers saved by then — the result records the ending as its own reason ("It reached its limit of recorded events…" in meaning), never a fake "submitted".
• Below the ceiling the test never ends itself for events; only counted events move it.

Preconditions

A running Standard test.

Steps

1. Trigger several leave-signals inside two seconds (alt-tab repeatedly, or blur+hide together).
2. Wait past two seconds and do it again.

Expected

• Signals inside a two-second window count once — the count climbs by one, not by signal count.
• Separated leavings count separately — each real leaving is one event, honestly.

Preconditions

A running Strict test (or Standard — the count behaviour is what matters).

Steps

1. Note the event count; reload the page.
2. Drop the connection briefly and restore.
3. If you can: sign in on another browser (TC-TST-015).
4. Zoom the browser, navigate by keyboard/screen-reader, toggle reduced motion.

Expected

• Refresh is noted for staff and the count does not move — the note, if shown, says a refresh is "noted, never counted" in meaning.
• Connection loss, slow network, save retries and platform notices are not recorded events — no count, no note.
• A sign-in elsewhere is recorded for staff but never counted.
• Keyboard navigation, zoom, captions, assistive technology and reduced motion are not events — the ceiling is for leaving, not for how you use your computer.

Preconditions

A running Strict test on a paper with these recordings enabled (check the paper page's "What is recorded" lines; mark N/A if none of your tests has them).

Steps

1. Copy or paste within the test; right-click.
2. Press a restricted shortcut (F5, print, dev-tools).

Expected

• Where enabled, each is recorded as its kind — "Copy, paste or the right-click menu was used." / "A restricted shortcut was pressed." in meaning — and counted/noted as the paper configures.
• Nothing is blocked: the paste lands, the menu opens — recording is observation of the kind, never interception and never clipboard content.
• Where the paper doesn't enable them, doing the same records nothing.

Steps

1. Through a whole Strict test, watch for any permission prompt, any recording indicator outside the page, anything capturing keys or clipboard content.
2. In dev tools watch what leaves the browser when events fire.

Expected

• No camera, microphone, screen or file permission is requested anywhere in the test lifecycle.
• Recorded payloads are event kinds + timestamps — never keystrokes, clipboard contents, screenshots or other-page data.
• What staff see (kinds, times, counted status, ending reason) is exactly what the notes told you — there is no secret extra.

Preconditions

A fresh account starting Tamarind Grove Systems Engineer (fullscreen required, Strict ceiling 3). Plan this as the account's spend on that paper.

Steps

1. Start the test; read the full-screen gate; press Go to full screen.
2. Press Esc to leave full screen; read what happens; re-enter.
3. Refuse/deny if the browser offers a choice.

Expected

• A gate explains the requirement before the room opens — it cannot be dismissed without choosing, and it is the same requirement the briefing disclosed.
• Leaving full screen prompts a return and records "Full screen was left." — on this Strict paper it counts toward the 3.
• A refusal prompts again and is told honestly — never silently recorded and never an undocumented failure. Where the browser can't do it, the message says to use a current Chrome/Edge/Firefox.
• The systems check's Full screen item predicted all of this before Start.

Steps

1. With a test running, open a second paper's page (any type) and try Start.
2. Sign the same account in elsewhere and try to start a paper there.
3. End the test; confirm a new Start is allowed again.

Expected

• Every Start is refused while one is live: "Another test is in progress. Resume it" — a link, not a button.
• The cap is the account's, not the tab's: a second device gets the same refusal.
• After the test ends (submit/time-out/ceiling), Start returns to normal immediately.

Steps

1. While a test runs, watch product-wide behaviour in the second tab: motion, toasts, anything that would interrupt.

Expected

• Motion is stilled during a live test (product rule); decorative animation on other pages holds still too.
• Toasts/notifications don't fire into the test room; anything waiting surfaces after.
• Hints/editorials/Quick Notes/compare are closed with their reasons (TC-TST-025) — and reopen when the test ends.

Steps

1. In a running test, answer some, mark some, leave some; press Submit test and read the dialog without confirming.
2. Use its links; then Keep going.

Expected

• "Submit {title}?" with "You have {time} left. Once you submit, your answers can't be changed."
• Tallies: answered, not answered, marked — plus per-section "N of M answered · K marked".
• Two honest shortcuts: "Go to question N, the first one not answered" and "Go to question N, marked for review" — each lands exactly where it says.
• "Keep going" returns to the room unchanged; only the confirm submits.

Steps

1. Press Leave in a running Standard test; read; confirm.
2. Do the same on a Strict test.
3. Return via the paper's Resume and check nothing moved but the clock.

Expected

• "Leave the test?" with "The clock keeps running. You can come back until {deadline}. After that, the test is submitted as it is."
• On Strict it adds the recorded-truth: leaving is recorded, and at the ceiling the test submits itself.
• Confirming lands you on the paper page with Resume as the next action — leaving is a pause in your chair, never a submission.
• On Standard/Strict the leaving is recorded once (the note on return matches §3); on Off, nothing is.

Steps

1. Submit a test; press the confirm twice fast; try Enter during it.
2. Try submitting again from a second open tab of the same test.

Expected

• One submission, one result: repeated and simultaneous submits collapse into the same ending — no double grading, no error.
• The room hands over to the result page; the test can never be re-opened for answering.
• The result records "submitted" as the ending reason.

Preconditions

A test near its deadline (a company paper's last minutes, or leave a started Mock until the end).

Steps

1. Be typing an answer as the clock reaches zero; watch.
2. Open the result.

Expected

• A "Time is up" state you cannot dismiss: "Submitting the answers saved by now…" then the result.
• Outstanding typing at zero is carried into the submission where it can be; after the deadline nothing new counts.
• Time used never exceeds the deadline; the ending reason reads as time-ending ("Time ran out, so the answers saved by then were submitted." in the history row).
• Answers already saved are all in — nothing held back by the abrupt ending.

Steps

1. Press Submit in the final seconds; while the submission completes past zero, try to change an answer on another question.

Expected

• The submission finishes honestly under grace — it does not fail for crossing the deadline.
• No answer editing is possible during grace: grace finishes a submission, it never extends answering.

Preconditions

A test left running past its deadline without submitting (leave it, don't watch it end).

Steps

1. Past the deadline, look at the catalogue card, the history row and the paper page.
2. Wait ~5 minutes and look again; open the result.

Expected

• Before the worker reaches it the test reads Overdue — honest, never "lost" or a fake score.
• Within about five minutes it submits itself; the row flips to grading/final and the ending reason is the time ending.
• Everything saved by deadline is graded; nothing after counted.

Steps

1. With a test near its deadline, cut the network and let the clock hit zero offline; read the state; restore.

Expected

• An honest state: "The connection dropped as time ran out. Your saved answers are safe and are submitted for you; the result follows." with a way to the result.
• The submission keeps retrying and lands when the connection returns — the result then says whether ending and grading completed; it never shows a fake failure or a fake score.

Preconditions

Submit a test leaving: a question never opened (Not reached), one opened then left (Skipped), and one on screen at the end / left blank (Not answered).

Steps

1. Arrange the three kinds, submit, open the review.

Expected

• The review names the three differently — a never-opened question is Not reached; an opened-and-left is Skipped; one on screen at the end is Not answered.
• The answers tile counts them ("Not answered: N skipped · N not reached · N left blank. Unanswered questions lose nothing.").
• No kind pretends to be a wrong answer or a zero mark it wasn't.

Steps

1. Submit a test and land on the result page before grading finishes; watch it.
2. Leave the page and come back through history while still grading.

Expected

• "Submitted" (or "Time's up. Submitted.") with "Submitted at {time IST}. Your answers are saved. Your result is being prepared" — on a company test adding that your readiness updates with it.
• A Grading status where the score will go; a line like "This page shows the result as soon as it is ready. You can leave; grading carries on." — and it does update live (or via Check now).
• Nothing invented: no provisional score, percent, pass, rewards or readiness while grading.
• The history row reads Being marked/Grading with no score — consistent everywhere.

Preconditions

A grading service delay/outage (coordinate with staff, or note N/A if grading is always fast on the deployment).

Steps

1. Watch a result that is still grading after ~30 seconds and ~5 minutes.

Expected

• Long grading escalates its honesty: a "taking longer than usual" line, then a "grading is busy; your answers are safe" line — still pending, never flipped to a failed-looking result.
• When grading completes the real result appears; the row was never wrong in the meantime.

Preconditions

A finished Mock test — one passed, one failed if your plan allows.

Steps

1. Open the result; read the lead fully.
2. Check the numbers against your recorded answers.

Expected

• "Your score" as X of Y marks; the percentage to one decimal rounded down; Passed or Not passed beside "The pass mark is 50%."
• Time used "X of 45 minutes" — never more than the paper's time; the ending reason in words.
• An "Earned" line only where something was earned — e.g. "+200 XP · First Mock Test completed" on a first finish, "+300 XP · First Mock Test passed" on a first pass; recognitions (90%+, perfect score, perfect section) named.
• Practice links appear where practice is open: "Practise the N you missed" / "Practise all".

Steps

1. On a finished result, press each answer tile.
2. Open "Your sections"; press a section's "Show questions".

Expected

• Tiles filter the review to that outcome; counts add to the question total.
• "Not answered" shows its breakdown (skipped / not reached / left blank) and "Unanswered questions lose nothing."
• "Your sections" rows read "X of Y marks · N of M answered"; a section filter narrows the review to it.

Steps

1. Open several reviewed questions across kinds: a choice you got right, one wrong, a coding question.
2. Look for any hidden-test-case material.

Expected

• Each row: the question's first line, its outcome status, "X of Y marks".
• Inside: Your answer beside Right answer for choice/numerical ("Your answer: N · Right answer: M"); Your code plus "N of M test cases passed" for coding; Explanation and "A reference solution in {language}" where the paper shows them.
• Your own answers/code appear wherever the question is shown — that is always.
• Hidden case content never appears — only "N of M test cases passed"; no inputs, expected outputs or diffs against hidden material.

Preconditions

A paper whose review settings hide questions/answers (staff-made variant if needed), and a result older than its retention — mark N/A where not staged.

Steps

1. Open both results.

Expected

• Withheld review: "This paper does not show its questions after the test. Your score and its breakdown above are complete." — score/sections still complete.
• Aged out: a line like "Your answers are kept for 90 days, or while this is among your 20 most recent tests of its kind…" with the summary intact and no dead review action.

Preconditions

Your written answer record for a finished test incl.: a multi-select with some right some wrong; a wrong single-choice on a −0.25 paper; a coding question passing some cases.

Steps

1. Compare each question's awarded marks with what the rules promise.
2. Check the total and the percentage.

Expected

• Multi-select partial credit: (correct − incorrect)/correct × marks; wrong-only loses the penalty once where the paper applies one, else zero.
• Programming Fundamentals' wrong single-choice loses 0.25 exactly as disclosed; where a paper has no negative marking, wrong is just 0.
• Coding marks are proportional to passed cases; non-compiling code earns 0 with no negative penalty.
• The total is rounded once and floored at zero — negative marking can bite inside a section but the test total never goes below 0; percentages display one decimal rounded down.

Preconditions

An account finishing its first Mock ever, then a second; check the wallet/achievements against doc 03.

Steps

1. Finish a first Mock test (any outcome); note XP.
2. Finish a first pass (may be the same or a later paper); note XP.
3. Finish another test — confirm nothing repeats.

Expected

• First completion pays once (200 XP); first pass pays once (300 XP); scoring ≥90% / a perfect score / a perfect section grants its recognition once.
• Later tests: the Earned line lists only what that test newly earned — often nothing — never re-pays.
• Company tests never appear in these rewards at all.

Preconditions

An account willing to spend a paper submitting with zero answers (choose deliberately — it's that account's only test on that paper).

Steps

1. Start, submit with nothing answered; read the result.

Expected

• Score 0, "Not passed", every question under Not answered — no crash, no invented partials.
• First-completion XP still pays (finishing is the achievement); the paper now shows "View result"/Practice — your one test is spent.

Preconditions

A finished company test (e.g. Corvane Data Analyst Trainee).

Steps

1. Open the result; read every region.
2. Look for anything Mock-shaped: a pass mark, XP, achievements.

Expected

• Eyebrow "Company Test · {company} · Pattern"; the score and the accuracy ring "N right of M answered" (all-unanswered reads "Nothing was answered, so there is no accuracy.").
• Marks by difficulty and marks by question kind — a cut may be negative ("−0.5 of 4 marks") where the paper deducts; the cuts add to the score.
• A company-readiness ring: a band, or "Not enough evidence yet" with what it needs.
• The honest line: "Company Tests have no pass mark and earn nothing: your score, accuracy and readiness are the result." — no Passed/Not passed, no XP anywhere.

Preconditions

An account finishing tests at a two-paper company (Northvale or Corvane — the only seeds that can pass the ≥2-finalized gate).

Steps

1. Finish one company test; read readiness. Finish the company's other paper; read again.
2. On a one-paper company (Kestrelworks/Tamarind), finish and read readiness.

Expected

• Before the gate (≥2 finalized tests on that company and at least half its published papers covered): "Not enough evidence yet: finish N more papers to see it" — never a fake band or a 0%.
• Past the gate a band: below 50 "Not ready" · 50 to under 75 "Developing" · 75–100 "Well prepared" — the figure to one decimal, rounded down.
• While the newest test grades the readiness says it is updating — never a stale number presented as current.
• Kestrelworks/Tamarind can never reach the gate with one published paper — they stay "Not enough evidence" honestly.

Steps

1. Copy a finished test's address; open it signed in as a different learner account.
2. Try a random /tests/… and /tests/…/result.

Expected

• Another learner's test/result opens the same not-found as a made-up address — "Result not found"/"It is not one of your tests." in meaning — never a partial render of their data.
• Nothing leaks through title, counts or error wording.

Preconditions

Staff grant a relief to an account with a finished result on a published paper.

Steps

1. Open the paper's page; read the next action and the conditions.
2. Start and finish the relief test; check history for both rows.

Expected

• The next action reads "Use your relief grant"; the conditions add "This test replaces your earlier result once it is final, and it is the only one your relief grant gives." with the button "Accept the conditions and use your relief grant".
• Only one unused grant exists at a time per paper — a second grant can't stack.
• When the new result finalizes, the older row reads "Replaced by a newer test" (muted) and its result page says it is archived and stays in history; the new result is what counts — for score, readiness and practice alike.

Preconditions

A grant holder facing: an archived paper; another live test; an unavailable paper.

Steps

1. Try to use the grant on each.

Expected

• Archived: "Your relief grant on it can no longer be used." — the grant survives, the Start doesn't exist.
• Live-test cap: the same "Another test is in progress. Resume it" refusal as everyone.
• The grant is not consumed by refusals — it stays until a test it funds actually finalizes.

Preconditions

Staff invalidate a finished result (agree which — it is the learner-facing side of a staff action).

Steps

1. Open the invalidated result; read it fully.
2. Open history; check the paper's card; check XP/Skills/readiness changed as the notice said.

Expected

• The result page keeps the entry: "This test has no result" plus the neutral reason — one of: "Something on our side went wrong while it was taken or marked, so its result cannot be relied on." · "A question in it was faulty in a way that cannot be put right, so it cannot be marked fairly." · "Your account needed securing while it was in progress, so its work cannot be relied on." · "It was decided that its result cannot stand." — never blame, never silence.
• "It no longer counts towards anything, and it stays in your history." — history keeps the row marked invalidated.
• Skills and company-readiness contributions are removed; Mock rewards reverse exactly (a notification says whether XP counts or is taken back); a reversed first-completion/first-pass reward can be earned once on a later valid test.
• Practice on that paper closes until a valid replacement finalizes; the card offers a fresh start where the paper allows.
• Repeated processing changes nothing — reversal is exactly once.

Preconditions

Staff archive/remove a paper a result exists on (coordinate).

Steps

1. After the paper goes, open the result from history; try the paper's address.

Expected

• The result and its history row remain readable — the paper's end doesn't take the result with it.
• Practice offered from that result closes honestly; a link to the paper lands on its archived/not-found state, not an error.

Preconditions

An account with a finished result on a still-offered paper.

Steps

1. Open Practice from the card or the result. Read the lead; scroll the page.
2. Look for anything test-shaped: a clock, an events count, a Save that persists.

Expected

• The honest line up top: "Unrecorded practice: no clock and nothing recorded. Your result stays as it is, and nothing here is kept once you leave the page."
• Every section and question on one page — the current published questions, numbered as the paper numbers them.
• No countdown, no recorded events, no navigator, no submit — and no way to affect your result, history, Skills or rewards.

Steps

1. Answer several questions of different kinds and press each one's Check.
2. On a paper that hides correct answers, check a wrong answer.

Expected

• Each Check grades that one question: its outcome and "X of Y marks" beside it — checking is per-question, never whole-paper.
• Where the paper reveals answers: "The right answer is: …"/"The answer is N." plus explanation and reference solution where they exist.
• Where it doesn't: "This paper does not show its correct answers." — outcome and marks still show honestly.
• Changing your answer and checking again re-grades — practice never locks you in.

Steps

1. On a coding question in practice, Run the examples repeatedly — past any test-time allowance.
2. Write a partial solution and press Check; read the outcome.

Expected

• "Runs are unlimited in practice." — no allowance countdown ever appears.
• Check "runs your code on these examples and N hidden test cases" and reports "N of M test cases passed" — practice Check is the one place hidden cases grade live.
• Hidden material still shows nothing: no inputs, expected output or your output against hidden cases — the count alone.

Steps

1. Check several questions; read the "So far" line as it grows.
2. Press Start again; check the page. Leave and reopen practice.

Expected

• "So far: X of Y marks · N of M questions checked, out of K marks" — checked counts, not attempted.
• Start again empties every answer and the tally — confirmed it's a fresh page, not a partial clear.
• Reopening practice later starts clean: nothing you did was kept — the promise in the lead kept literally.

Steps

1. On a result with missed questions, press Practise the N you missed; then Show all. Compare with Practise all.

Expected

• The practice page opens filtered: "Showing the N questions you missed in your test." with Show all to open the rest.
• Practise all opens the whole paper; a zero-miss result doesn't offer an empty "missed" list.

Steps

1. Before any test on a paper: no Practice action; type the address directly.
2. While a test on it is live or grading: try the address.
3. On an archived/closed paper you finished: look for Practice.
4. On a phone/tablet: look for Practice and open the address.

Expected

• Never taken: no Practice anywhere and the address lands on the paper page / a closed state — never a practice room.
• Live or grading: practice is closed until the newest test is final — the page says so, no half-open room.
• Archived/closed paper: no Practice action and "Practice is not open" in meaning at the address — even though your result exists.
• Touch: no Practice on cards; the address reads "Practice runs like the test, on a computer" / "Open this page on a computer to practise: no clock, and nothing recorded."

Steps

1. Note Skills/XP/history before a practice session; do a full practice; re-check.

Expected

• Nothing changed anywhere but the page: no history row, no Skills movement, no XP, no notifications, no rewards — unrecorded means unrecorded.

Preconditions

An account with 2+ projects of different languages and states.

Steps

1. Open Workspace → My Projects. Read the strips and every card.
2. Open a card's actions.

Expected

• Lead names the collection; a strip reads "N of 10 projects"; a line like "Across every project you have held: N programs finished well, and N tasks completed." plus "Each holds up to 100 files and 25 MiB. Course Workspaces are counted apart."
• Cards most-recently-edited first; each shows the runtime line, name, "Edited {when} · {N of M tasks}", the state (In progress / Ready to complete / Complete), storage "X of 25 MiB, in N of 100 files".
• Actions: Download, Details…, Delete… — Delete asks first.

Steps

1. On a fresh account open My Projects.
2. With projects loaded, cut the network and refresh the list; restore and retry.
3. Search a name; filter by a language; combine into a no-match.

Expected

• Empty: "No projects yet" plus a line like "Start one in any language Wizly Learning runs, or as a web page you preview." — never a dead grid.
• A failed refresh keeps the loaded list visible and offers a retry — the page doesn't empty itself on an error.
• Search matches project names; the language filter narrows to that runtime; "No projects match" (in meaning) with a clear restores.

Preconditions

An account holding 10 projects.

Steps

1. Try New project and Import a ZIP; read what they say.
2. Delete one project (through its confirm); try again.

Expected

• At 10 the controls are unavailable with the reason: "You have 10 projects, the most you can keep. Delete one to make room for a new one." — never a silent dead button.
• Delete's confirm names the project: "Its files are deleted for good and cannot be brought back. Its place among your 10 projects is freed." with Download it first offered.
• After deleting, creation works again and the count drops to "9 of 10 projects".

Steps

1. Open New project → Blank. Read the type groups; pick several and watch the starter-file list change.
2. Type a name past 120 chars; an illegal name; a good one. Create.

Expected

• Types grouped honestly — e.g. Python (incl. Data analysis), Web (Web page, React), Databases (SQL), more languages (JavaScript…) — each with a line on what it is and the starter files it lands with.
• "The language stays {runtime} for the life of the project." — runtime is a birth decision, no switching later.
• The name field counts "0 / 120", refuses illegal characters as typed with the path rules named — never silently rewrites them.
• Create project needs name + type; the new project opens in the IDE with its starter files present.

Steps

1. Open Build your own. Read the three choices; combine them.
2. Try SQLite alone — no back end. Then Flask + SQLite. Create each if slots allow.

Expected

• Three honest choices: a front end (HTML or React), a back end (Flask), a database (SQLite) — each named for what it adds.
• SQLite only offers with Flask — choosing it alone says why (a database needs something to run it).
• The resulting runtime and starter files follow the stack; the IDE's run story matches (React+Flask lands as its own project type, not a mislabelled blank).

Steps

1. On the template strip open "Use this template" for React: habit tracker and SQL: college fest. Read each dialog; create one.
2. Compare the project against the template after staff edit the template later (or trust the independence line and spot-check).

Expected

• Before creating, the dialog shows it all: description, language, the files with sizes, the 3-task checklist with instructions, and the storage it needs — nothing lands sight-unseen.
• A line like "The project is yours: a copy that later changes to the template never touch." — and it means it.
• No name typed → takes the template's name; the project opens with template files and its checklist.
• Later template edits do not reach your copy (verify against a re-seeded template if available).

Steps

1. Import a ZIP a small valid archive: read the included/excluded preview before confirming.
2. Try a ZIP over a limit (>25 MiB total, >100 files, or paths outside the rules) and a non-ZIP file.

Expected

• The page reads the ZIP locally first and shows what comes in and what is left out with why — before anything is created.
• Import is all-or-none: a refused archive makes no project, no partial files, no placeholder.
• Refusals name their reason (size, file count, paths, "not a ZIP") — never a silent drop; a dropped-on ordinary ZIP is just a stored file unless you choose Import.

Steps

1. In any create dialog press Create project twice quickly; import with a double-confirm.

Expected

• One project, once — the list gains a single card and the project count rises by one.

Steps

1. Open a Python project. Identify each region top to bottom, left to right.
2. Toggle the right panel and the stack details; open each icon-rail tab.

Expected

• Project bar: back to My Projects, the language mark, the project name, "Personal project" + its state, the stack chips where relevant, where-it-runs, the storage meter, Run (or Stop while running), Debug for Python, Save, Download, and the right-panel toggle.
• Icon rail: Explorer, Search, Run and Debug, Project settings — each opens its side panel.
• Editor: file tabs across the top, an optional second editor, the file itself.
• Output: tabs for Terminal (or Results for SQL), Problems, Output — plus Debugger on Python projects.
• Right panel: Preview (or Page) and Checklist — no generated-help or agent tab anywhere (GENERATED_ASSISTANCE is off).
• Status bar: save state, problems count ("No problems"/"N problems"), "Start file: {path}", runtime, storage, and task state.

Steps

1. Open three files; cycle tabs with Alt+[/Alt+]; close one.
2. Ctrl+P the file palette; Ctrl+Shift+P the command palette; Ctrl+G to a line; Ctrl+S to save; Ctrl+Enter to run.

Expected

• Tabs open across the top with an unsaved mark; closing works from the tab (hover close or shown).
• The palettes find files/commands; Ctrl+G lands on the line; Ctrl+S saves now; Ctrl+Enter runs.
• A file's unsaved dot appears in its tab and its explorer row — the two never disagree.

Steps

1. Open a folder's row menu and a file's row menu — read every action.
2. Drag a file onto a folder; use Move to….
3. Open to the side a second file beside the first.

Expected

• Folder row: New file here · New folder here · Upload files here · Rename or move · Delete. File row: Rename or move · Download · History · (Reset data on a .db) · Delete.
• Each asks what it must — Delete confirms, Rename validates the path rules — and lands exactly there.
• Dragging onto a folder (or Move to…) relocates the file; a collision names itself rather than overwriting.
• Open to the side puts the file in a second editor — both stay live and save independently.

Steps

1. Drag each divider; reload — is it kept?
2. Narrow below 1024px: the IDE becomes tabs (Code / Output / Preview); run something while narrow; widen again.

Expected

• Divider positions are kept on this device.
• Under 1024px a personal project still edits and runs via its tabs — a running program keeps running across the switch; widening restores the three-pane layout.
• Nothing overlaps, clips or needs horizontal scrolling at 1024 / 1280 / 1440.

Steps

1. Try to create/rename files named: my file.py (space), ../x.py, /abs.py, a\b.py, a name over 120 chars, a path over 240, and FILE.py beside file.py.
2. Make legal nested paths with hyphens, underscores and dots.

Expected

• Each illegal name is refused at the field with the rule in words: "Letters, digits, hyphens, underscores and dots, with / between folders." — nothing is created and your typed text isn't quietly edited.
• Case-collision (FILE.py vs file.py) is refused — the file system treats them as one.
• Legal nested paths create cleanly.

Steps

1. Type into a file and watch the status bar through the save cycle.
2. Take the network offline, type more, read the state; restore.
3. Force a save failure (service refusal); read and retry.

Expected

• The ladder in order: typing → "Not saved yet"/"Saved locally" → an automatic checkpoint (idle ~a minute, or on Ctrl+S/Run) → "Saved · just now".
• Offline work is kept in the browser honestly labelled "Saved locally" and sends on return.
• A refusal reads "Not saved: {files}." with Tap to retry — the work is never dropped.
• Where the browser can't hold a copy the state says so: "Not saved yet, and this browser cannot keep a copy" — the honest worst case, not a silent loss.

Steps

1. Type changes, do not save, reload the page immediately; check the file.
2. Type, close the tab, reopen the project.

Expected

• The browser-kept copy restores your edits — the file shows what you typed, marked as its real save state, and a pending send completes on the next open.
• Nothing is presented as saved that wasn't — the status bar still says "Saved locally"/retry, not "Saved".

Steps

1. Open the project in two tabs; edit different lines in both; let them collide.
2. Read the dialog; try each choice on separate collisions.

Expected

• The behind tab is named honestly: "Open in another tab" with Edit here to take over.
• On a real conflict: "{path} changed somewhere else" + "Your version is still here. Choose what to keep." with both versions shown and four honest choices: Keep mine · Take the stored version · Save mine as a new file · Download my version.
• Each choice does exactly what it says — nothing is merged or lost silently.

Steps

1. Upload a small image into a folder; open it — it shows as a picture.
2. Upload a batch with one file over the 10 MiB binary limit; check nothing landed.
3. Upload over an existing name; try to run a binary file in the terminal.

Expected

• An uploaded image opens as an image, not as text garbage; text/binary limits (2 MiB / 10 MiB) are enforced with named reasons.
• A batch validates all-or-none: one bad file means nothing arrives — no placeholder, no partial set, no charge.
• Uploading over an existing path asks first — never silent overwrite.
• A binary stays stored and downloadable but never runs — the terminal/editor treats it as data.

Steps

1. Edit and checkpoint a file a few times; open its History; Use this version on an older checkpoint.
2. On the project, open the restore path; read the confirm; restore.

Expected

• History lists real checkpoints; "Use this version" puts that content into the editor — it becomes the working copy, not a forced save.
• "Restore project" asks first and names the checkpoint it returns to; the restore itself lands as a new checkpoint — it is recoverable, not destructive.
• With no earlier checkpoints the history says so honestly; a failed read says so too — never an empty list implying no history exists.

Steps

1. In a Python project run a program that prints and then input()s.
2. Send input; use Backspace, Ctrl+C, Ctrl+D.
3. Make it error; read the traceback.

Expected

• The run bar names where it ran: "This device · Python 3.14.2" — the version is literal, not a guess.
• Waiting input() holds the program; your typed line goes in; Backspace edits; Ctrl+C interrupts; Ctrl+D ends input.
• "The program finished." / its exit state is honest; an error shows its traceback at the real line.
• Output lands in the Terminal/Output tab — program output is never mistaken for platform messages.

Steps

1. In a multi-file Python project, set a start file from a file's menu; check the status bar and run bar.
2. Rename that file; delete it; run again.

Expected

• "Start file: {path}" shows the choice; the run bar says "Starts from {path} (your choice)".
• Priority is honoured: your chosen file → else main/Main (Java) / index (web) → else the only file of its kind at root → else it can't run and says why.
• Renaming follows the choice; deleting the chosen file falls back to the next rule and says so — never a dead Run.
• An empty project can't run: Run is unavailable or refuses with the reason.

Preconditions

A project needing cloud (Flask / numpy / pandas — e.g. the taskBoard template; or a Data-analysis template project).

Steps

1. Run it; watch where it says it runs.
2. In the same project try a pure-Python file — does it still run on device?

Expected

• The run bar names the cloud honestly — "Cloud · Python 3.14.10"/"Ran in the cloud and finished." — device is preferred wherever possible and the choice is never hidden.
• Files it can't run on device (needing cloud packages/features) say "It can run in the cloud instead." in meaning — offered, not forced.
• Cloud limits are real: ≤100 files, ≤10 MiB each, ≤25 MiB total — an over-limit project says so rather than failing mysteriously.

Steps

1. In a SQL project (collegeFest template or a blank SQL) write a query and run.
2. Write a syntax error; run.
3. Open the .db file's row — find Reset data; check storage accounting.

Expected

• Queries run in-browser SQLite; tables/rows show in the Results tab.
• An error names itself with its line — a SQLite message surfaced honestly, not a generic failure.
• Databases .db/.sqlite/.sqlite3 hand back up to 5 MB; Reset data exists on the file; project storage for My Projects doesn't meter the browser-side database.

Steps

1. In a React project (habitTracker template) edit App.jsx and watch the preview.
2. Import a package outside the pinned set (lodash); import BrowserRouter/HashRouter and read the error.
3. Use react, react-dom, react/jsx-runtime, react-router-dom — the allowed set.

Expected

• The preview refreshes from your edit — a fresh isolated frame each time, not a leaked old state.
• An outside package is refused by name at its line: "…is a package this preview does not provide" in meaning — pinned versions only: react/react-dom/react-jsx-runtime 19.3.0, react-router-dom 7.18.4.
• BrowserRouter/HashRouter errors honestly — the preview is MemoryRouter only; the message says why.
• Console output appears under the preview; a missing import file names "The page names files the project does not hold:" with the paths.

Steps

1. Find Update as I type; type and count the ~700ms wait; toggle it off, reload — is it kept per project+browser?
2. Put an external link in the page and click it.
3. If a preview can stall, watch past 10 seconds.

Expected

• Update-as-you-type defaults on with its ~700ms debounce; your choice persists per project per browser.
• An external link is never followed inside the preview: "That link goes to …, which this preview does not follow, so it stays on this page." in meaning — isolation kept.
• A preview silent past ~10 seconds says the connection is down — never a frozen frame pretending to work.

Steps

1. Start programs until the allowance (3 concurrent across Code Lab + projects) is reached; start one more.
2. Navigate away mid-run and return inside ~2 minutes; then past it.

Expected

• At the limit a new run is refused and Running programs lists what's running with Stop each — a program waiting on input() still holds a slot.
• Leaving the page keeps the program ~2 minutes; returning reattaches and replays missed output (bounded ~500 messages/256 KB) — no lost run, no duplicated output.
• Past the window the program has stopped honestly — it isn't still "running" on the server somewhere.

Steps

1. On a Python project press Debug on a program that sets variables and errors.
2. Open the Debugger tab; use To the start / Back / Forward / To the end and the step slider; Go to the error.
3. Try Debug on a non-Python project and on a cloud-requiring file.

Expected

• Debug records the run — steps, frames and variables — on this device; the Debugger tab offers first/last/back/forward plus a "Step n of N" slider.
• "Go to the error" jumps to the failing step; variables at each frame are inspectable; the recording is bounded honestly.
• Debug is Python-only and device-only: elsewhere it is absent or says why nothing can run — never a button that pretends to debug.

Steps

1. In a Python project write code with an error and a warning; open Problems.
2. Click each entry.

Expected

• Python files are checked on-device; problems group by file with counts ("1 error, 2 warnings").
• Clicking opens the file at the line+column — never just highlights the file.
• Clean code reads "No problems" — and problems never appear where no check ran.

Steps

1. Add a task; rename it; move it up/down; remove it — no confirms needed for these.
2. Add tasks until the cap; try one more.
3. Tick tasks and watch the count + card state.

Expected

• All four edits work inline without confirmation; order persists.
• At 12 tasks the add refuses with "A project holds at most 12 tasks. Remove one to add another."
• Ticking updates "N of M tasks ticked" and the project state follows: all ticked → Ready to complete — ticking is not completing.

Steps

1. On a no-task project try to complete — read the block.
2. On a fully-ticked project press Mark complete; read the confirm; confirm.
3. Do it on the account's first ever completion; then complete another project.

Expected

• No tasks: "A project needs at least one task, every one ticked, before you can mark it complete."
• The confirm is honest about the honour system: "You are judging for yourself that the work is finished. Nothing checks it and nobody grades it." and "Unticking a task, or adding one, later returns it to In progress."
• Done: "You marked this project complete on {date}." and the card flips to Complete.
• First ever: "Project complete. You earned First project completed." — once only; the second completion says just "Project complete."

Steps

1. On a Complete project untick one task — watch the state; complete it again.
2. Use Untick every task; read the confirm; confirm.

Expected

• Unticking (or adding) returns it to In progress honestly — the state isn't sticky.
• Completing again shows "Project complete." with no second achievement.
• Untick-every asks first: "Every task goes back to unticked{, and the project returns to In progress}. Your files are not touched." — and the files really aren't.

Steps

1. Open a personal project on a phone or tablet (or a mobile dev-tools profile).
2. Switch Files / Checklist / Brief; open a file; tick a task; try to edit or run.

Expected

• The honest line: "Editing and running need a computer: open this project on one to change files or run it."
• Files read with line numbers; the segmented Show: Files / Checklist (with counts) / Brief (course workspaces).
• Ticking tasks and completing still work — the checklist is a real control; editing and running simply aren't offered.
• "Download the project" is offered; "All files" browses; empty reads "This project has no files yet."

Preconditions

An account with at least one Course Workspace (created from a lesson) and some personal projects.

Steps

1. Open Course Workspaces. Read the lead strip and the cards.
2. Compare against My Projects.

Expected

• Lead: "The projects your course lessons asked you to build, each in a workspace of its own. They do not count against your own projects."
• A shared meter: "{X} of 250 MiB used" + "Shared by all of them. Each holds up to 40 files and 20 MiB."
• Each card: runtime, name, "{subject} · {lesson}" (or "Its course could not be read just now" honestly), "Edited {when} · {tasks} · {size}", its state, Download, Open the lesson, Delete….
• Empty: "No Course Workspaces yet" + "A course's project lesson makes one when you start it. Find one in a subject's outline." — never a zero-meter pretending empty.
• The collections never mix: workspaces don't appear in My Projects and don't eat its 10 slots.

Steps

1. Open the course's project lesson; read what the workspace starts with; press Start the project.
2. Leave and open the lesson again; press its project action again.

Expected

• Before creating, the page shows what the workspace starts with (its files/starter); starting creates it once.
• Repeated opens from the lesson return the same workspace — never a second copy, never a fresh state.
• The workspace appears on /course-workspaces with that lesson named.

Steps

1. Open the workspace; read its layout and right panel.
2. Open the Brief tab and the way back to the lesson.
3. Look for any generated help, agent or credits surface.

Expected

• Three columns: explorer / editor / output; the right panel offers Preview (or Page), Checklist and Brief — and "Back to {lesson}" in the header.
• Brief shows the lesson's brief as the course wrote it, with the way back to the lesson.
• Where the lesson was unpublished after the workspace existed, the Brief says it can't be read and why — honestly, not a stale copy.
• No generated help, no agent tab, no credit costs — same absence as §6, verified here too (GENERATED_ASSISTANCE=false).
• Runs, files, saves and limits behave exactly as §6 — the workspace is the same tool, not a lesser one; its own limits apply (20 MiB · 40 files) within the shared 250 MiB.

Steps

1. Tick every task in a Course Workspace; press Mark complete; read the confirm and confirm.
2. Open the lesson, the subject, and check XP/certificate surfaces it should feed.
3. Untick a task afterwards and re-check the lesson.

Expected

• The confirm adds the course truth: the lesson records this completion once and keeps it even then — completing is honour-system, same as §6.
• The lesson completes; where that finishes the subject/course, its completion, XP and certificate follow ("You completed {course}." / "See your completion" when a course finishes).
• Unticking afterwards does not un-complete the lesson — completion is recorded once and stands; the workspace's own state still moves honestly to In progress.

Steps

1. Delete a Course Workspace (read the confirm); check storage freed and the lesson still complete.
2. From the lesson press Start again; compare the new workspace.

Expected

• Delete confirms honestly: "Its files are deleted for good and cannot be brought back. A lesson it completed stays complete; starting the project again makes a fresh workspace from its starting files." — Download offered first.
• Storage frees from the course meter (not the personal count — it never used that).
• The lesson shows "Lesson complete" with Start again; starting makes a fresh workspace from the lesson's starting files — a new copy, never a recovery of the deleted one.

Preconditions

Staff archive a course a learner has a workspace from (coordinate; mark N/A if not staged).

Steps

1. Reopen the workspace and the lesson's start action after archiving.

Expected

• The existing workspace still opens and works — archiving the course doesn't orphan the learner's files.
• Starting a new workspace from the archived course is refused honestly — the course is gone for new starts, not for existing work.

Steps

1. Push a Course Workspace toward its limits (large files, many files — ZIP import where allowed or uploads).
2. Push the shared meter across several workspaces if feasible.

Expected

• The per-workspace limits (20 MiB / 40 files) refuse with their own reason — not the personal 25/100 numbers.
• The shared 250 MiB is honest too: crossing it refuses with the shared reason, never a mysterious failure.

Steps

1. Sweep every surface in this doc for any AI/agent surface: test room, results, practice, both project IDEs, run/debug panels, right panels, palettes, Quick Notes-adjacent spots.

Expected

• Nothing exists: no help panel, no "Ask"/"Explain"/"Analyse" paid action, no Credits cost, no generated help — /credits is an unknown address.
• Finding one is a P1 bug — absence is the spec (GENERATED_ASSISTANCE=false).

Steps

1. Drop the network and reload: the catalogues, a paper page, Test results, My Projects, a result mid-grading.

Expected

• Each says it can't be asked/read in its own words with retry where offered — never an empty grid, a 0 count, or a faked success.
• An unreadable readiness/standing/usage figure is never drawn as zero.
• A grading test is always "Grading"/"Being marked" — never a half-score.

Steps

1. Re-audit every "once" surface: one test per paper, one live test, one relief grant, idempotent Start/Submit/Create/Mark-complete, once-only rewards.

Expected

• Every "once" is a real once — no path (double-click, second tab, second device, refresh, back-button) makes two.

Steps

1. Across this doc's surfaces, listen for wrong words: "attempt/retake" for test, "proctoring" for strictness, "hidden case" naming content, "Labs" in interface text, "saved on this device" vs "Saved locally".

Expected

• Tests are "taken once"; strictness is Off/Standard/Strict in plain words; events are "Recorded events" and the ceiling is the "limit of recorded events"; save states are the literal ladder; unanswered is Not reached/Skipped/Not answered; the product names itself Wizly Learning.

Steps

1. Check deadlines, "Submitted at", "Edited" stamps, marks in the thousands, and every percentage in results/readiness.

Expected

• All times are IST and the product-day boundary (09:00 IST) is respected where it applies.
• Numbers use Indian grouping where they get large; percentages show one decimal and round down — readiness and score both.

Steps

1. Drive: a test room by keyboard alone; a result page's review with a screen reader; the IDE's palettes and dialogs by keyboard.
2. Check every state (answered/marked/closed/current; save states; outcomes) survives without colour.

Expected

• Everything reachable by keyboard in sane order; dialogs trap and release focus correctly; focus lands on headings on navigation.
• No meaning carried by colour alone — marks, labels and words carry it too (the navigator's states, Passed/Not passed, outcomes all have non-colour signals).
• Reduced motion and zoom (to ~200%) keep everything usable.

Steps

1. Spot-check the catalogue, a paper page, the test room (≥1024 only), a result, My Projects, the IDE at each width; flip themes and modes on two screens.

Expected

• Nothing overlaps, clips or lies about capability at any width — the test room honestly requires ≥1024, practice and IDE degrade as spec'd.
• Both themes and both modes keep every state legible — no white-on-white status, no theme-only meaning.

Steps

1. Time cold loads of the catalogues and the IDE; time in-page reads (paper page, result, opening a file).
2. Watch every spinner/skeleton — does it end honestly?

Expected

• First load usable around three seconds on a normal connection; in-page reads around one second; the test room is responsive immediately.
• Skeletons stand only for real loading — nothing spins forever and nothing fakes a completed read.