Quizzes, assignments and grading

1. In Questions, choose Create question and select multiple choice (including true/false), short answer, numerical answer, written response, fill in the blanks, matching, ordering or coding. Add a subject and topics to organise your bank.
2. To make a listening question, open Listening clip on a multiple-choice or subject question and upload an audio file (mp3, m4a, wav, ogg, webm or aac). Learners hear it above the question; its file name is never shown to them. Each attempt keeps the clip it started with, so replacing or removing a clip changes only new attempts.
3. In a coding question, use visible tests for learner feedback and hidden tests for grading.
4. Use Student preview to check the current draft with only visible examples, and Check reference solution to run all draft tests before saving. Test points are relative weights; the quiz sets the question’s final score. An output question’s reference solution is not saved; a unit-test question’s is saved, seen only by staff, and run on every save.
5. Save changes writes the question, files and tests together. If another editor saved first, your draft is kept with a conflict notice: compare the latest version, then reload before saving. Leaving an unsaved draft prompts you first.
6. Each coding quiz attempt keeps the question and tests from when it started. Later edits affect new attempts; Mark all attempts again deliberately uses updated tests. Attempts predating this feature retain the version available when it was installed, without changing existing marks.
7. Questions on read-only plans cannot be edited, and only the author or an admin can edit a question. A question used by an active batch or LMS quiz cannot be archived; follow its usage links to review those quizzes. An archived question remains listed in the bank: open it and choose Restore question to use it again.

Links to staff pages need a sign-in.

1. Under Code & files, add files the program reads: up to 20, 1 MB together, less the room kept for what learners send (their code beside a driver program, and the files they edit at full length). A name may sit in folders up to 3 deep, such as data/rates.csv; at the top level a file cannot be called input, run.sh, build, build.tar or go-trim.txt, or code with any extension. Choose + Add file to type a text file, or Upload a file for data, images or anything else. An uploaded binary file is kept byte for byte and shown by its name and size; learners never see its contents and cannot edit it.
2. A test can carry test code. In Python 3, JavaScript, TypeScript, PHP and Ruby it runs after the learner’s code, so it can call their functions. In Java, C, C++, C#, Go, Kotlin and Rust it is a driver program with its own main, and the learner’s code is compiled beside it as the file named under Learner’s file name (Solution.java, solution.c and so on when left blank). A Rust driver declares the module, for example mod solution;.
3. Tick Passes when it exits cleanly on a test with test code to pass it when the run ends without an error within the time limit, whatever it prints. Assertions, Python’s unittest.main(), Node’s built-in test runner and Ruby’s minitest then work without matching printed text, written in the test code and calling the learner’s functions directly: there is no module of theirs to import.
4. Under Language, Installed packages lists what the code runner has beside the language: Python’s data packages, Ruby’s test gems, or the standard library only. A notebook question lists the packages the grader has that a browser notebook does not load, and the versions that differ.
5. Memory per run appears when The Skill Site’s code runner allows more than 512 MB: choose more for questions that load large data. A question whose language the runner no longer offers is flagged in the bank and the editor: choose a language and check it with Check reference solution.
6. Learners and staff see each visible test’s output and errors apart, and a run problem in words: did not compile, timed out (after the question’s time limit, or 30 seconds without one), ran out of memory, printed too much, started too many processes or crashed. A run problem never changes a mark: the test fails as before.

A unit-test question runs your own test files with a test framework over the learner’s code, and scores each test by its name. It runs Python and JavaScript tests.

1. Under How is it graded?, choose Unit tests. Pick a test pack (Python tests or JavaScript tests) and a preset: pytest for Python tests; jest, mocha, node-test for JavaScript tests. Or choose Your own command: it runs with bash beside the files and must write $OUTPUT_DIR/report.xml (JUnit XML) or $OUTPUT_DIR/results.json (Gradescope’s shape), running its tests in one process. A GitHub Classroom setup and test command fits here.
2. Name the learner’s file (the pack offers solution.py or solution.js): learners write their code in it and your tests import it. Add your test files and any fixtures under Files given to the program. Tick Learners edit this file on any other file learners change, and Hidden on a test file learners must not see. A file learners edit cannot be hidden. Nothing may sit under node_modules/: the JavaScript pack brings its own packages.
3. Write the reference solution: the learner’s file, and a version of each file learners edit. It is saved with the question, seen only by staff, and run on every save. Check reference solution runs it as a save would and lists every test, visible or hidden, passed or failed, with its message; it saves nothing.
4. Marking an answer, a check and a save each make up to two runs on the code runner. The run of the visible files has the learner’s files and every file not hidden: a test it reports is visible. The full run, made only when some files are hidden, has every file: a test only it reports is hidden. A save is refused unless the reference found at least one test, passed every test in both runs, and the full run reported every visible test.
5. The tests found become the question’s list, at most 200, each worth 1 point until you change it. Saving again keeps a test’s points by its name, gives a new test 1 point and drops a test no longer found. The time limit covers the whole run: 20 seconds unless you set one, up to 30.
6. A test in the list that the report leaves out fails; a reported test not in the list scores nothing and staff see its name. A run that timed out, ran out of memory, printed too much or started too many processes fails every test of that run. A run that wrote no report, or ended cleanly with a report naming none of the tests, is never marked zero: a quiz answer waits for staff in the grading queue, where you change its mark. A hand-in is tried up to 3 times, and again when the learner hands in again, you save a change to its tests, files, points or limits, or you choose Mark all hand-ins again. If the code runner itself fails, the answer is tried again later, after a longer wait each time, or at once when you choose Mark all hand-ins again. Meanwhile Give the tests mark, in its grading form, lets you give the tests part yourself, with a reason the learner reads.

Learners read the prompt, their own files and the visible test files. After marking they see each visible test by name, passed or failed, with its message, how many hidden tests passed, and any run problem in words. They never get a hidden file, a hidden test’s name or anything the full run printed, and neither do AI hints. Staff also see each hidden test by name, the test pack’s version and preset, and when marking again ran on a newer test pack. Unit-test questions are not offered through the API or embeds.

Hand-ins are marked against the question as it is, recording its version and the test pack’s. Quiz attempts are marked against the question as it was when the attempt started; Mark all attempts again uses the question as it is now.

A limit to know: a test framework runs the learner’s code in its own process, so determined code could write a report of its own. The report must name the question’s tests, staff see the code, its replay and the similarity check, and the tests never set an assignment grade alone. For an exam that needs stronger guarantees, use output tests: each hidden input runs in a run of its own, where its expected answer never is.

Drafts are written by Claude, an AI model made by Anthropic, from what you type and the material you give; nothing about learners is sent. Check each question, its correct choices and its explanation before you add it. Nothing from a draft reaches learners until you add it, and learners never use drafting.

Your institute has 100 drafts a month, or 10 on a trial or the free plan; a draft that fails is not counted. Each person has one draft being written at a time. AI drafts lists your own drafts; admins see everyone’s.

1. Once an admin has turned on AI drafting in Settings, open Questions and choose Draft with AI, then Draft multiple-choice questions. To draft from a lesson’s own text, open the lesson and choose Draft questions from this lesson.
2. Say what the questions should cover, choose how many and how hard, and paste your own material if they should keep to it. Choose Draft with AI.
3. Tick the questions you want and choose Add the ticked questions to the question bank, or choose Edit, then add to change one in the usual form first. Each question is added once, then set in a quiz like any other.

Links to staff pages need a sign-in.

1. In AI drafts, choose Draft a coding question. Say what it should test, and choose the language and difficulty.
2. The draft comes with a title, a prompt, starter code, tests (some shown to learners, some hidden) and a worked solution. Before you see it, the worked solution is run against every test on our code runner, and the draft page shows each test’s result.
3. Choose Open in the question editor. Tests the worked solution failed are left out, and the rest go in; check them, edit anything and save the question as usual. The worked solution is never saved with the question.

Short answers compare against the accepted answers you enter, ignoring extra whitespace and optionally case. Fill-in-the-blank questions accept alternatives per labelled blank and award equal partial credit.

Numerical answers accept decimals and scientific notation, with an absolute tolerance. Units match the accepted spellings exactly; the platform does not convert units or evaluate expressions. Tell learners the expected units in your prompt.

Matching gives equal credit for each correct pair. Ordering awards the full mark only for the complete correct order. Written responses require a teacher mark; add marking guidance to help staff assess consistently.

New attempts keep a snapshot of their prompts and answer keys. Editing a question affects later attempts. To apply a corrected answer key to completed attempts, use Mark all attempts again on the quiz results. The original prompts and responses are preserved, while released answers show the key used for re-marking. Marks awarded by a teacher are kept.

For matching and ordering corrections, keep option wording unchanged so earlier responses can be matched to the corrected key. Keep blank labels unchanged when correcting fill-in-the-blank answers. Use a new question for different content.

Earlier MCQ attempts were backfilled with the version available during the upgrade; previously overwritten content cannot be recovered.

1. Open a batch, then Quizzes, and create a quiz from the question bank.
2. Set the availability window, time limit, attempts allowed and pass mark. Decide whether it counts towards the batch outcome.
3. For several correct choices, optionally enable partial credit: each correct choice earns a share, each wrong choice loses a share, and the mark cannot go below zero.
4. Multiple-choice and objective subject questions are marked on submission; code is graded in the background. Written responses wait for a teacher in the grading queue. The overall result stays pending until every written response has a mark. Later question edits do not silently change existing attempts.
5. Use Copy for another test. In the same batch, dates move a week forward; in another batch, dates move with its start date. Review the filled form and save it.

Links to staff pages need a sign-in.

1. Open the batch’s Assignments and create the task with its due date and marking details. Assignment copying works like quiz copying.
2. Standard assignments accept written answers, links and files. To make a coding assignment, enable Use a programming question and select a question from the bank and the points awarded by its tests. Learners can check visible tests; submission runs all tests, including hidden ones.
3. Optionally add a rubric with criteria and point levels. The maximum score combines test points with the staff-marked part. Once a rubric has graded work, only its wording can change.
4. Learners can attach up to five files to a hand-in. Review their latest submission, give feedback, and grade it or return it for revision.
5. Under Late work, keep Use the institute’s late-work rules, or clear it to give this assignment its own: whether late hand-ins are accepted, a cut-off in days, a penalty per day and the lowest mark a penalty leaves. Late hand-ins are always marked late, with how many days.
6. To give one learner a later due date, use More time for one learner on the assignment page. Their lateness and any penalty are worked out again. When grading, choose Waive the penalty if it should not apply. On a quiz, More time for one learner on its results page gives a later close and extra minutes.

1. Open the grading queue or the batch’s assessment results. Choose rubric levels or enter the staff score; the final assignment score adds the test mark.
2. Where tests make up the whole assignment mark, use Confirm the tests marks to grade waiting hand-ins. A test result alone does not finalise an assignment grade.
3. On a quiz attempt, Change mark requires a reason the learner can see. Use the automatic mark restores the calculated mark for automatically graded questions. Written responses always require a teacher mark.
4. After correcting tests or answers, use Mark all attempts again for a quiz or Mark all hand-ins again for a coding assignment. Staff overrides stay in place and the previous mark remains visible until the new calculation finishes.
5. To comment on handed-in code, choose Comment on lines on an assignment’s submissions, or open one learner’s quiz attempt. Select a line number (hold Shift and select another for a range), write the comment and choose Add comment; your earlier comments on the same task are offered. Learners see comments with their result, never before.
6. To see who may need help, open How learners are getting on from a coding assignment or a quiz’s results. Each learner’s time spent (the gaps between their saves, checks and hand-ins of five minutes or less), checks of their code and how many ended in an error, hand-ins or attempts, tests passed and hints asked are listed, with those who may need help first and the reason: a long time without passing compared with the batch, errors check after check, three tries without passing, every hint level used without passing, or not started when their own due date is near while half the batch has. It is a prompt to look, not a verdict; learners never see it.
7. With Accept regrade requests on in an assignment or quiz, learners can ask, with a reason, for a grade or a question’s mark to be looked at again, for the days set in Settings. Open requests appear in the grading queue and beside the work. Choose Keep the mark with a reply, or change the grade or mark: your reply or reason answers the request, and the learner is emailed.

Links to staff pages need a sign-in.

Optional quiz conditions include a sitting code, allowed networks, one device per attempt, focus tracking and a coding paste limit. Learners see the conditions before starting. These conditions do not apply to LMS quizzes.

If a learner needs a replacement device, open their attempt and choose Let them continue on another device.

Focus records show when the test page was hidden or lost focus. Discuss unusual activity with the learner; it is not proof of misconduct and never changes a mark automatically.