An online exam has to do three things at once: give every student a fair version of the test, survive bad Wi-Fi and closed laptops, and make cheating harder without treating every student as a suspect. This article walks through the design decisions in Smart Edu's exam engine — what each one does, why it was chosen, and where it stops helping.
1. Every attempt gets its own paper
Smart Edu separates the exam (what the teacher designs) from the paper (the concrete list of questions a student answers). A section can take questions from a fixed list chosen by the teacher, or draw them from question pools — "10 questions from this topic, 3 of them hard" — filtered by the exam's subject.
Two generation modes cover different needs:
- Built per attempt (the default): each student gets a freshly drawn paper. Neighbours rarely see the same questions in the same order.
- Prebuilt and shared: one paper for everyone, useful when results must be strictly comparable, such as a common end-of-term test.
On top of that, question order and the order of answer options can be shuffled per attempt. One exception is built in: for ordering questions ("put these steps in order"), the stored option order is the correct answer, so those options are always presented scrambled and graded against the stored order.
Every pool is scoped to the school's own question bank and to the exam's subject, so a test for one subject never draws questions from another subject or another school. Rules like this belong in the query that picks questions, not only in the interface.
2. Time limits are enforced on the server
A countdown in the browser is a display, not an enforcement. Students can change their clock, pause scripts or keep a tab open overnight. Smart Edu records when an attempt started and the section's time limit on the server; a submission that arrives after the deadline (plus a small grace period for network delay) is rejected, and an attempt that has already been submitted or timed out cannot be submitted again. The browser countdown is there for the student's benefit, not as the rule.
3. Checkpoints so nobody loses work
Exams fail in mundane ways: a laptop battery dies, a page reloads, a phone switches networks. Smart Edu saves answers in two places as the student works:
- Locally, in the browser, so a reload restores the form instantly.
- On the server, as periodic checkpoints, so the work survives a different device or a cleared browser.
Checkpoints save answers without grading them; grading happens once, on submit. That keeps a half-finished attempt from producing a misleading score.
4. Submissions are bound to their attempt
A submitted answer sheet should only ever count for the attempt it belongs to. The general technique is to have the server sign each attempt when it starts, with a key the browser never sees, and to check that signature on submission. A client then cannot forge a submission, re-send an old one, or move a set of answers to a different student's attempt. Smart Edu protects every submission this way.
It is important to be precise about what this does not do: it does not detect a student looking at notes or asking a friend. It protects the integrity of the submission, not the exam room.
5. Optional network restrictions
For exams taken in a school computer room, a section can be limited to an IP allowlist — the school's network. Students outside it cannot start or submit. This is a blunt tool: it assumes a fixed network address and is unsuitable for exams taken from home, so it is off by default.
6. What students see afterwards is a teaching decision
Showing the full answer key right after submission helps learning but also leaks the answers to students who have not taken the exam yet. Smart Edu lets the teacher choose per section:
- Full review — score, which answers were right, and the correct answers;
- Score and correctness — which answers were right or wrong, without revealing the correct ones;
- Score only.
A school can also hide results from students entirely until the teacher is ready. The same rules apply to people who take a public-code exam without an account: they can see their own result — under the same policy — in the browser session in which they took the exam, and nowhere else.
Limitations worth stating plainly
- No software can prove who is sitting at the keyboard or stop a second device. Proctoring at that level needs people, or invasive monitoring we deliberately do not build.
- Objective questions are graded automatically; essays and other open answers still need a teacher.
- Shuffling and pools reduce copying between neighbours; they do not stop answers being shared between exam sessions. Large, regularly refreshed question banks do — see organising a question bank teachers can use.
Summary
- Generate papers per attempt from pools scoped to the right subject and school.
- Enforce time on the server; treat the browser timer as information.
- Save progress locally and on the server; grade once, on submit.
- Sign submissions so they cannot be replayed or transplanted.
- Let teachers decide how much of the answer key students see, and when.