Studi kasus — 01
TOEFL Prediction System
Digitalisasi ujian TOEFL prediction universitas, dari pendaftaran sampai sertifikat ber-QR
Platform ujian berbasis komputer dengan tiga sesi terjadwal, penilaian otomatis, akses berbasis peran, penyimpanan jawaban offline, dan sertifikat digital yang dapat diverifikasi.
- Peran
- Programmer — desain dan implementasi
- Periode
- 2025 — sekarang
- Status
- Aktif
Ringkasan
Judul lengkap proyek ini adalah Pengembangan Website TOEFL Prediction System Untuk Mendukung Digitalisasi Pelaksanaan Ujian TOEFL Prediction di Universitas Ubudiyah Indonesia. Nama panjangnya menjelaskan tujuannya dengan tepat: memindahkan ujian yang sebelumnya berjalan di atas kertas ke sistem yang menangani seluruh siklusnya.
Dalam praktiknya ini satu aplikasi dengan tiga tugas: menyelenggarakan tes prediksi tiga sesi, menilainya tanpa hitung manual, dan menerbitkan sertifikat yang bisa diverifikasi pihak lain.
Penggunanya adalah pusat bahasa, operator ujian, dan mahasiswa. Situsnya publik; isi soal dan catatan internal tidak.
Masalahnya
Tes TOEFL prediction adalah acara terjadwal dengan volume besar. Saat berjalan di kertas, setiap langkah manual: peserta mendaftar di daftar hadir, ruangan dicek satu per satu, tiap sesi dihitung dengan jam dinding, lembar jawaban dikumpulkan dan dinilai, lalu sertifikat diketik satu per satu dengan stempel dan tanda tangan.
Alur itu punya tiga kelemahan struktural:
- Penilaian lambat dan repetitif. Tiga sesi harus dihitung dan dikonversi ke skala untuk setiap peserta.
- Sertifikat sulit diverifikasi. Sertifikat kertas dipercaya karena stempelnya, bukan karena bisa dicek ke catatan.
- Ujian rapuh. Lembar jawaban hilang, sesi salah waktu, atau grid salah baca sulit dipulihkan setelah kejadian.
Digitalisasi bukan soal memasang formulir yang lebih rapi. Tujuannya membuat tiap langkah deterministik dan bisa diaudit.
Yang dilakukan sistem
Aplikasi mencakup seluruh siklus ujian:
- Pendaftaran dan penjadwalan. Peserta didaftarkan dan dimasukkan ke sesi ujian.
- Pelaksanaan. Tiga modul berjalan berurutan — Listening, Structure and Written Expression, dan Reading — masing-masing dengan timer dan aturan navigasi sendiri.
- Pengumpulan. Jawaban disimpan saat dipilih dan dikirim setelah sesi ditutup.
- Penilaian. Jawaban mentah dikonversi menjadi skor per sesi dan skor total berskala.
- Sertifikasi. Sertifikat digital dibuat dengan kode QR yang mengarah ke halaman verifikasi.
Operator melihat sesi dan peserta. Peserta melihat jadwal dan hasilnya. Izin bukan sekadar tampilan: operator tidak boleh mengubah skor yang sudah selesai, dan peserta tidak boleh membaca data peserta lain.
Arsitektur
| Lapisan | Pilihan | Alasan |
|---|---|---|
| Aplikasi | Next.js + React + TypeScript | Satu basis kode untuk halaman server-rendered dan antarmuka ujian |
| Data | PostgreSQL dengan Drizzle ORM | Data relasional dengan query bertipe dan migrasi |
| Auth | Better Auth | Penanganan sesi tanpa membangun alur kredensial dari nol |
| Otorisasi | CASL abilities | Aturan peran didefinisikan sekali dan diperiksa di batas aplikasi |
| Validasi | Zod | Satu skema untuk input form, payload API, dan parsing |
| State klien | Zustand | State kecil dan eksplisit untuk runner ujian |
| Buffer offline | IndexedDB via Dexie | Jawaban bertahan saat koneksi putus |
Detail pentingnya bukan daftar library, tapi di mana masing-masing boleh mengambil keputusan. Database memegang integritas, Zod memegang bentuk input, CASL memegang izin, dan lapisan React memegang presentasi. Saat batas itu kabur, perangkat lunak ujian jadi sulit dipercaya.
Perilaku offline
Jaringan di ruang ujian tidak selalu andal. Browser yang kehilangan koneksi di tengah sesi listening tidak boleh kehilangan jawaban atau membiarkan peserta masuk ke keadaan yang nanti ditolak server.
Model sinkronisasinya dibangun di atas tiga aturan:
- Jawaban ditulis ke IndexedDB lebih dulu dan dianggap sumber kebenaran lokal sampai diakui server.
- Request sinkronisasi bersifat idempoten, jadi percobaan ulang setelah timeout tidak membuat jawaban ganda.
- Server tetap berwenang atas waktu dan status pengumpulan, sehingga klien dengan jam lambat tidak bisa memperpanjang sesi.
Aturan terakhir yang paling penting. Dukungan offline bukan berarti “biarkan klien melakukan apa saja lalu rekonsiliasi nanti”. Ini izin sempit untuk kegagalan jaringan, sementara server tetap menentukan apa yang sah.
Autentikasi dan otorisasi
Setiap rute dibatasi berdasarkan peran: peserta, operator, dan administrator. Better Auth menangani sesi; CASL menyatakan apa yang boleh dilakukan tiap peran.
Prinsip yang selalu saya pegang: pemeriksaan izin harus dekat dengan data, bukan hanya di UI. Menyembunyikan tombol adalah keputusan kegunaan. Menolak request adalah keputusan keamanan, dan keduanya harus ada.
Penilaian dan sertifikat
Penilaian sengaja dibuat membosankan: setiap sesi menghasilkan skor mentah, skor mentah dikonversi menjadi skor sesi, lalu digabung menjadi skala yang dilaporkan. Pipeline yang eksplisit membuat hasil yang diperdebatkan bisa ditelusuri sampai ke jawaban, bukan diargumenkan.
Setiap sertifikat membawa kode QR yang menunjuk ke URL verifikasi. Halaman itu mencocokkan identitas sertifikat ke database dan menampilkan hasilnya. Tangkapan layar sertifikat bukan bukti; catatan di sistemlah buktinya.
Pengujian
Proyek ini diuji dari luar, per peran, bukan hanya lewat unit test.
- Alur peserta: daftar, mulai, jawab, kumpulkan, baca hasil, unduh sertifikat.
- Alur operator: buat sesi, pantau peserta, tutup sesi.
- Kasus batas: mengumpulkan setelah timer habis, menyambung ulang di tengah sesi, dan mencoba mengakses sesi dengan peran yang salah.
Pendekatan itu sesuai risikonya. Kegagalan mahal di sistem ini adalah kegagalan alur kerja, bukan fungsi murni yang salah nilai balik.
Tantangan dan pelajaran
Waktu adalah urusan server. Timer yang hanya hidup di browser hanyalah saran. Server harus bisa menyatakan kapan sesi berakhir, terlepas dari apa yang dipercaya klien.
Offline adalah batasan desain, bukan tombol fitur. Begitu jawaban bisa disimpan lokal, setiap jalur tulis butuh strategi idempotensi.
Otorisasi adalah masalah data. Pemeriksaan peran yang tersebar di banyak komponen akan melenceng. Menyatakan ability sekali membuat perilakunya terprediksi.
Sertifikat adalah produk kepercayaan. Kode QR hanya berguna kalau halaman verifikasi berwenang dan identitasnya tidak bisa ditebak.
Sistem ini sudah berjalan dan dipakai. Yang ingin saya perbaiki berikutnya adalah visibilitas operasional: dashboard kesehatan sesi dan jejak audit yang lebih jelas untuk perubahan skor.