What to actually look for in a CBT system for WAEC and NECO mocks

Every year, schools invest in CBT (Computer-Based Testing) systems to prepare students for WAEC and NECO. And every year, some of those schools discover on mock exam day that their system cannot handle the conditions of a real Nigerian school environment.

The demos looked good. The dashboard was clean. The vendor was responsive. But when 120 students sat down simultaneously on a shared network with intermittent power, the system slowed to a crawl, lost sessions, and left the exams officer manually reconstructing which students had submitted.

This guide is about what to evaluate before you sign a contract — not after.

The conditions you are actually testing in

Before evaluating any CBT system, be honest about your infrastructure. Most Nigerian secondary schools operate with:

• A shared internet connection that degrades under load
• Power supply that may cut out once or twice during a three-hour exam
• A mix of device ages and screen sizes in the computer lab
• Students who have varying levels of familiarity with keyboard and mouse use

A CBT system that works beautifully on a stable fibre connection in a Lagos tech office may fail completely in these conditions. The question to ask every vendor is: "What happens when the internet goes down mid-exam?"

Offline-first design

The most important technical feature for Nigerian school CBT is offline-first architecture. This means the exam runs locally on the device or local server, and syncs to the cloud when connectivity is restored — rather than requiring a live internet connection throughout.

Ask vendors specifically: does the exam continue if the internet drops? Does the student's progress save locally? Can the system recover a session after a power cut? If the answers are vague, treat that as a red flag.

Question randomisation

WAEC and NECO use question randomisation to prevent copying. Your mock system should do the same. This means each student sees questions in a different order, and in multiple-choice questions, the options are also shuffled.

Some systems offer randomisation as a feature but implement it poorly — the same "random" order is generated for every student in the same session. Ask to see a demonstration with two simultaneous test accounts and verify that the question order differs.

Simultaneous user load

Test the system with the number of students who will actually sit at the same time. If your largest exam session is 150 students, ask the vendor to demonstrate the system with 150 simultaneous users. Many vendors will offer to do this — take them up on it, and watch the response times carefully.

A system that handles 20 users smoothly but slows significantly at 100 is not suitable for a school of your size, regardless of what the marketing materials say.

Timer behaviour and auto-submission

The exam timer should be server-side, not client-side. A client-side timer can be manipulated by students who know how, and it also means that if a student's device crashes and they log back in, their timer may reset. Server-side timing ensures the clock runs independently of what happens on the student's device.

Auto-submission at time expiry is essential. Students should not be able to continue after the timer ends, and the system should submit whatever answers have been recorded at that point rather than losing them.

Result generation and analysis

After the exam, you want to know more than just each student's score. A good CBT system shows you which questions were most frequently answered incorrectly — this tells you where your teaching needs to focus before the real exam. It should also flag students who finished suspiciously quickly, which may indicate guessing or other issues worth investigating.

The dashboard question

Vendors often lead with dashboards in their demos. The dashboard is the least important part of a CBT system. A beautiful analytics interface is worthless if the exam itself is unreliable. Evaluate the exam engine first, the reporting second, and the dashboard last.

A practical evaluation checklist

• Does the exam run offline if internet drops?
• Does student progress save locally and sync on reconnection?
• Is the timer server-side?
• Does auto-submission work at time expiry?
• Is question and option order randomised per student?
• Has the vendor demonstrated the system under your expected concurrent user load?
• Can you export raw scores to a spreadsheet?
• What is the support response time if something fails on exam day?

A system that passes all eight of these checks is worth considering. A system that fails any of the first five is not ready for your school, regardless of price.