Formulir mengubah data pengguna menjadi tindakan sistem: pendaftaran, pesanan, pembaruan profil, atau unggah berkas. Menguji formulir lebih dari memasukkan kombinasi karakter. Ikuti alur dari masukan hingga data tersimpan dan hasil yang jelas di layar.
Validasi yang baik membantu pengguna memperbaiki kesalahan dan melindungi integritas data. Validasi buruk membuat frustrasi sekaligus membiarkan request tidak valid: UI mungkin menolak nama keluarga yang sah tetapi API menerima record tanpa persetujuan wajib.
Perjelas aturan terlebih dahulu
Dokumentasikan kontrak tiap kolom: wajib atau tidak, nilai yang diizinkan, rentang panjang, format, normalisasi, ketergantungan, dan waktu validasi. Pisahkan aturan bisnis seperti keunikan, ketersediaan paket, tanggal valid, dan pembatasan peran.
Normalisasi mengubah masukan ke bentuk yang disepakati, misalnya memangkas spasi di awal dan akhir. Jangan mengarangnya dalam pengujian. Spasi dapat bermakna dalam nama, dan mengubah huruf besar/kecil kata sandi atau karakter Unicode dapat mengubah rahasianya. Ajukan aturan ambigu sebagai pertanyaan persyaratan, bukan defect berdasarkan selera pribadi.
Pisahkan pemeriksaan klien dan server
Validasi klien memberikan umpan balik cepat sebelum request. Validasi server memutuskan apakah operasi diizinkan. Atribut HTML dan JavaScript browser dapat dilewati, sehingga penolakan UI tidak membuktikan perlindungan data backend.
Uji masukan tidak valid yang sama melalui formulir dan request langsung dalam lingkungan uji. Harapkan penolakan server yang disepakati, tidak ada record baru, dan penanganan kesalahan UI yang benar. Kontrak API menentukan status HTTP tepat; tidak ada status universal untuk semua formulir.
Pilih data secara sistematis
Gunakan kelas ekuivalensi: kelompok masukan yang diharapkan berperilaku sama. Untuk panjang 2–50, periksa kosong, 1, 2, 50, dan 51 karakter serta nilai biasa di dalam rentang. Ini memberikan cakupan batas yang dapat dijelaskan.
- →Angka: minimum, maksimum, nilai berdekatan, negatif, pecahan, dan pemisah tidak valid.
- →Tanggal: tanggal yang tidak ada, hari kabisat, batas periode, serta perilaku locale dan zona waktu yang diperlukan.
- →Teks: spasi, baris baru, Kiril, karakter Unicode gabungan, penempelan, dan nilai panjang.
- →Pilihan: tidak dipilih, nilai tidak tersedia, dan perubahan daftar turunan setelah kolom induk berubah.
Perjelas satuan panjang. Karakter terlihat, code point, unit UTF-16, dan byte dapat berjumlah berbeda, terutama untuk emoji.
Uji masukan sebagai interaksi
Pengguna mengetik, menempel, mengisi otomatis, mengedit bagian tengah string, dan menghapus seleksi. Mask telepon yang hanya bekerja saat mengetik berurutan dapat merusak nilai tempelan. Kalender dapat menerima tanggal melalui widget tetapi menangani masukan manual berbeda.
Periksa juga pengiriman lewat tombol dan Enter, navigasi Tab, retensi nilai setelah kesalahan, dan keyboard seluler yang sesuai. Placeholder dapat memberi contoh tetapi hilang saat mengetik, sehingga tidak menggantikan label kolom tetap.
Kesalahan harus mendukung pemulihan
Pesan perlu menjelaskan apa yang terjadi dan cara memperbaikinya. Kaitkan dengan kolom benar, buat dapat dipahami tanpa warna, dan tampilkan cukup lama untuk dibaca. Beberapa kesalahan memerlukan jalur jelas ke setiap kolom.
Periksa urutan fokus, nama kolom aksesibel, dan pengumuman kesalahan pembaca layar. Pesan umum “data tidak valid” mungkin tidak cukup untuk alamat pengiriman. Sebaliknya, pesan login yang mengungkap keberadaan akun dapat melanggar persyaratan keamanan. Konteks penting.
Pemeriksaan asinkron dan kondisi balapan
Ketersediaan nama pengguna, perhitungan harga, dan saran alamat tiba setelah tindakan pengguna. Masukkan A, cepat ganti menjadi B, lalu tunda respons A. Respons lama tidak boleh menimpa hasil saat ini.
Saat mengirim, tampilkan keadaan yang disepakati. Klik berulang, Enter, dan retry jaringan tidak boleh membuat operasi bisnis tambahan. Menonaktifkan tombol mengurangi risiko, tetapi verifikasi perlindungan duplikat yang menentukan pada lapisan operasi dan server.
Contoh praktis: pendaftaran
Misalkan kontrak mewajibkan email dan kata sandi 12–64 karakter, dengan spasi kata sandi dipertahankan. Akun dibuat saat pemrosesan server berhasil; respons yang hilang tidak berarti record tidak ada.
- 1.Masukkan data valid dan kirim. Harapkan satu record baru dan langkah berikutnya yang jelas, misalnya konfirmasi email.
- 2.Uji kata sandi sepanjang 11, 12, 64, dan 65 melalui UI serta API. Harapkan batas konsisten dan tidak ada record tidak valid.
- 3.Gunakan email yang sudah ada. Harapkan penolakan sesuai kontrak dan kolom valid lain dipertahankan, kecuali kebijakan mewajibkan rahasia dihapus.
- 4.Simulasikan timeout setelah pengiriman, lalu ulangi. Harapkan hasil terdefinisi tanpa akun kedua atau loading tanpa akhir.
- 5.Selesaikan pengiriman gagal dengan keyboard dan pembaca layar. Kesalahan harus dapat ditemukan dan diperbaiki tanpa mouse.
Berkas dan data sensitif
Untuk formulir berkas, periksa ukuran dan tipe menurut kontrak, berkas kosong, transfer terputus, dan unggah ulang. Atribut accept membantu pemilihan, tetapi server harus memvalidasi isi dan batas secara independen.
Jangan masukkan kata sandi, token, atau dokumen pribadi nyata ke diagnostik. Tunjukkan defect dengan data uji siap pakai dan request tanpa data sensitif.
Kesalahan umum dan pelajaran
Kesalahan umum meliputi hanya memeriksa kolom wajib, menganggap mask sebagai bukti validitas, dan memeriksa pesan tanpa keadaan data aktual. Pola email atau nama yang terlalu membatasi tanpa persyaratan produk juga berisiko.
Pengujian formulir sistematis menghubungkan kontrak, batas, metode input, keputusan server, dan pemulihan kesalahan. Nilai seluruh perjalanan pengguna, bukan jumlah string yang dimasukkan.
Bacaan lanjutan
- →MDN: Validasi formulir sisi klien
- →W3C WAI: Pemeriksaan mudah, formulir, dan kesalahan
- →OWASP: Panduan pengujian keamanan web
Satu aturan, matriks masukan konkret
Aturan latihan: nickname harus berisi 3–12 huruf ASCII. Spasi ditolak, bukan dipangkas diam-diam; huruf Unicode di luar latihan yang sengaja sempit ini. Formulir HTML hanya berjalan di klien dan tidak mengirim request. Fixture API memvalidasi aturan name yang sama secara terpisah.
Masukan Hasil yang diharapkan
(kosong) Tolak
ab Tolak: panjang 2
abc Terima: panjang 3
abcdefghijkl Terima: panjang 12
abcdefghijklm Tolak: panjang 13
abc Tolak: spasi di awal
абв Tolak: bukan ASCII menurut aturan iniUntuk nilai ditolak, pastikan kesalahan terlihat, aria-invalid=true, dan fokus pada kolom tidak valid. Kesalahan terhubung ke input melalui aria-describedby. Untuk nilai diterima, pastikan status sukses dan kesalahan kosong. Jangan menggeneralisasi aturan ASCII ini ke nama nyata atau produk internasional.
Pemeriksaan klien memperbaiki umpan balik tetapi dapat dilewati. Kirim JSON tidak valid langsung ke fixture API lokal dan pastikan juga ditolak. Pemeriksaan formulir dan API adalah dua pengujian terpisah; demo ini tidak mengklaim pengiriman menyeluruh dari browser ke API.