Supporting Remote School Assessments During Lockdown

COVID-19 restrictions removed the shared classroom environment schools normally relied on for examinations, and with it the informal structure, supervised rooms, printed papers, a teacher on hand, that had always made assessment straightforward. Administrators still needed to prepare question sets, organise schedules, guide students, and retain examination records, all without the physical setting they had always used to do it. iEncode Tech built the Online Examination Portal on Java, Spring Boot, and MySQL, with WebSockets handling live exam-session behaviour, so the platform could recreate that structure digitally, quickly enough to matter during an active disruption. What makes this case study distinct from a typical quiz-builder story is the deliberate separation it maintains between administrative preparation and the student experience, mirroring how a supervised exam actually runs.

Before this engagement, remote assessment options available to schools were largely improvised: video calls with a teacher watching over a webcam, emailed question papers, or generic quiz tools never designed for formal, multi-question-type examinations. None of those approaches scaled well to a whole institution running examinations across multiple classes and subjects at once, and none preserved the clear boundary between the person setting an exam and the person taking it that a physical classroom enforces automatically. The Online Examination Portal was built specifically within that gap, as part of iEncode Tech's wider education technology work.

Moving formal school assessment online under time pressure raised problems that go beyond simply putting questions on a webpage:

• Multiple question types needed support so exams could resemble what schools already used, not a single simplified quiz format
• Student and administrative responsibilities had to be clearly separated so learners never saw preparation tools and administrators were not routed through the exam-taking flow
• Scheduling needed to be explicit and reliable, since a remote exam has no supervising teacher present to informally manage timing or catch a student who has run out of time
• Schools needed a repeatable process they could reuse for future examinations, not a one-off setup built around a single event
• Result information had to remain connected to the specific examination and schedule it belonged to, preserving an accurate record rather than a loose collection of scores
• The system needed to work for multiple schools without hardcoding assumptions specific to any one institution's process

Discovery for this project happened under real constraints: schools needed a working solution during an active disruption, not a fully researched platform delivered months later. That pressure shaped the approach directly, rather than exploring a wide design space, the priority was identifying the smallest set of workflows that would let a school run a genuine formal examination remotely: question authoring with multiple question types, explicit scheduling, a focused student experience, and reliable result recording. Anything beyond that core loop was deliberately deferred, since the goal was a dependable process schools could actually use in the near term, not a feature-complete platform built too slowly to matter.

The goals that came out of that discovery were specific to the moment but built to outlast it: give administrators full control over question preparation and scheduling, give students an assessment experience free of administrative complexity, make exam timing explicit and automatic rather than manually enforced, and make the whole workflow repeatable so a school using it for one examination could use the same process for the next one without reconfiguring from scratch.

iEncode Tech kept question preparation and organisation firmly within school administration, giving staff control over multiple question types and how they were structured into an examination. Students received a focused, separate examination experience, free of administrative tooling, with scheduling acting as the explicit connective layer between preparation and participation, so an exam only became visible to students at the intended time, closely mirroring how a supervised, in-person exam would actually run.

The workflow was built to be repeatable rather than bespoke: once a school had used the platform for one examination, the same process, question authoring, scheduling, student participation, and result recording, applied to the next one. Results stayed tied to their originating examination and schedule, giving schools a reliable record rather than a loose collection of scores disconnected from the exam that produced them.

Administrative screens were designed for depth: question banks, scheduling controls, and organisational tools that assume a staff member is working through preparation carefully over time, not rushing through a single screen. Student screens were designed for the opposite: minimal, focused, and free of anything that might distract from the exam itself, since a student sitting a formal assessment remotely already has enough to manage without navigating unfamiliar software on top of it. Keeping those two experiences visually and functionally separate, rather than a single interface with role-based visibility, was a deliberate choice to reduce the chance of a student ever seeing, or accidentally triggering, an administrative control.

Examination and question management

Administrators create and manage examinations with support for multiple question types, giving schools the flexibility to build assessments that resemble what they already used in the classroom.

Scheduling and session control

Explicit scheduling connects prepared exams to a defined window of time, with real-time session monitoring and automatic submission at the scheduled end, removing the need for a supervisor to manually enforce timing.

Student experience

Students move through a scheduled examination, answering questions and submitting their work, in an interface kept entirely separate from administrative tooling, so nothing about the exam-taking flow depends on understanding how the exam was built.

Results and records

Results and examination records stay connected to their source exam and schedule, giving schools an accurate, traceable record rather than a disconnected list of scores.

School-level administration

Each school operates its own administrative space within the platform, so the same underlying system supports multiple institutions without one school's data or configuration affecting another's.

• Backend: Java and Spring Boot form the application layer, chosen for a strongly typed, well-tested framework suited to an examination system where correctness, consistent scheduling, and reliable scoring matter more than rapid visual iteration.
• Database: MySQL stores structured examination, question, schedule, and result data, a relational fit for the strict connections between exams, their questions, their schedules, and the students who sit them.
• Real-time layer: WebSockets support real-time exam-session behaviour, such as keeping a student's session state current and enabling reliable auto-submission when a scheduled exam window closes.
• Infrastructure: AWS (EC2, Lambda, S3, Route 53) hosts the application and its infrastructure, giving schools dependable uptime during scheduled exam windows, when many students may be active on the platform at once.

The hardest technical requirement was reliable auto-submission at a scheduled exam's end. A remote exam has no supervisor to physically collect papers when time is up, so the platform itself had to enforce that boundary precisely, submitting a student's work automatically at the scheduled end time regardless of network hiccups or a student who simply stops responding. WebSocket-based session monitoring addressed this by keeping an authoritative, server-side view of exam state, rather than trusting a student's device alone to submit on time.

The second real difficulty was keeping the system genuinely reusable across multiple schools rather than accumulating institution-specific logic that would make onboarding a new school harder each time. Building scheduling, question management, and results as general-purpose workflows, rather than shaped around any one school's particular process, is what let the platform scale to multiple institutions during a period when many needed the same solution at once.

The solution was deployed for multiple schools and provided a central, repeatable workflow for remote assessment during a period when no other dependable option was available to them. It gave administrators a structured way to prepare and schedule exams, gave students a focused assessment experience, and kept results connected to the examination record that produced them.

No school names, student totals, or examination volumes were supplied, so this case study does not infer them. What is confirmed is the platform's deployment for real school use, its multi-question-type support, and its separation of administrative and student responsibilities, capabilities that remain directly relevant to any institution needing dependable remote or supplementary assessment infrastructure beyond the pandemic context that originally drove development.

Building under genuine time pressure sharpens priorities in a way that is hard to replicate deliberately: focus on the smallest workflow that solves the real problem, and defer everything else. That same discipline carried directly into the companion Library Management System built for the same institutional relationship, and it continues to inform how iEncode Tech scopes education platform engagements more broadly.

Need a dependable remote or supplementary assessment system for your institution? Contact iEncode Tech to discuss a platform built around how your school actually schedules and delivers examinations, or see the Online Examination Portal project overview for a concise summary of what was delivered.