Kasus uji adalah deskripsi terstruktur dari pemeriksaan tertentu. Tujuannya adalah membuat pemeriksaan tidak ambigu, dapat direproduksi, dan berguna bagi tim, bukan sekadar mendokumentasikan sesuatu.
Isi umum kasus uji yang baik
- →Judul yang jelas mengungkapkan tujuan cek tersebut.
- →Prasyarat: keadaan sistem awal yang diperlukan.
- →Langkah pengujian: tindakan yang dilakukan oleh penguji atau sistem.
- →Hasil yang diharapkan: apa yang seharusnya terjadi.
- →Jika diperlukan, uji data, prioritas, tautan persyaratan, dan catatan.
Apa yang membuat kasus uji menjadi kuat
- →Ia memeriksa aturan atau risiko tertentu, bukan semuanya sekaligus.
- →Hasil yang diharapkan dapat diukur dan tidak ambigu.
- →Ini berisi langkah-langkah yang cukup untuk kejelasan tanpa detail yang tidak perlu.
- →Kegagalan memperjelas apa yang salah.
Kesalahan umum
- →Menulis kasus yang terlalu panjang yang mencakup beberapa ide berbeda sekaligus.
- →Menggunakan hasil yang diharapkan tidak jelas seperti "berfungsi dengan benar".
- →Gagal memisahkan prasyarat dari langkah-langkah.
- →Menduplikasi lusinan kasus yang hampir identik sehingga daftar periksa atau parameterisasi akan berfungsi lebih baik.
Ketika suatu kasus tidak diperlukan
Tidak setiap pemeriksaan membutuhkan kasus uji tersendiri. Untuk smoke testing atau sanity testing yang singkat, fitur yang belum stabil, dan sesi eksplorasi, biaya dokumentasi terperinci dapat melebihi manfaatnya. QA yang baik memilih format secara sadar.
Kasus login yang berfungsi dengan persyaratan eksplisit
Kasus ini menggunakan spesifikasi latihan fiktif, bukan aturan login universal. Akun learner@example.test aktif dan memiliki kata sandi valid yang diketahui. Kata sandi salah atau akun yang tidak dikenal menampilkan pesan yang sama, “Invalid credentials”, tanpa membuat sesi. Kolom kosong menampilkan kesalahan kolom tanpa mengirim permintaan login. Kata sandi salah untuk ketiga kalinya secara berturut-turut pada akun yang dikenal mengunci akun selama 5 menit; login berhasil mereset penghitung. Akun terkunci tidak dapat login meskipun kata sandinya benar.
Jalankan setiap kasus secara mandiri. Kembalikan penghitung kegagalan yang dinyatakan, status kunci dan sesi sebelum memulai; jika tidak, urutan pengujian sebelumnya akan mengubah hasil yang diharapkan. Gunakan kredensial sintetis saja.
ID Keadaan awal Masukan / tindakan Hasil yang diharapkan
L01 Aktif, 0 kegagalan, belum login Kirim akun yang dikenal + kata sandi benar Sesi dibuat; profil terbuka; penghitung bernilai 0
L02 Aktif, 0 kegagalan, belum login Kirim akun yang dikenal + kata sandi salah Invalid credentials; tidak ada sesi; penghitung bernilai 1
L03 Akun tidak dikenal, belum login Kirim unknown@example.test + sembarang kata sandi Invalid credentials; tidak ada sesi
L04 Belum login Kirim dengan kedua kolom kosong Dua kesalahan kolom; tidak ada permintaan login
L05 Aktif, 2 kegagalan, belum login Kirim akun yang dikenal + kata sandi salah Tidak ada sesi; akun terkunci selama 5 menit
L06 Terkunci, belum kedaluwarsa, belum login Kirim akun yang dikenal + kata sandi benar Tidak ada sesi; kunci tetap berlakuPerluas satu baris menjadi case manual yang dapat dieksekusi
Kasus: L02 — menolak kata sandi salah
Prasyarat: akun aktif, penghitung kegagalan 0, tidak ada sesi.
1. Buka halaman login.
2. Masukkan learner@example.test dan kata sandi yang sengaja salah.
3. Kirim satu kali.
UI yang diharapkan: “Invalid credentials”; profil tidak terbuka.
Keadaan yang diharapkan: tidak ada sesi; penghitung kegagalan akun yang dikenal menjadi 1.
Bukti: respons tanpa data sensitif serta pengamatan keadaan yang tersedia di lingkungan uji.Penghitung memerlukan mekanisme pengamatan yang disepakati, seperti tampilan administrasi khusus pengujian atau fixture uji berizin. Jika mekanisme itu tidak tersedia, tandai asersi tersebut belum terverifikasi; jangan menyimpulkannya dari pesan. Tambahkan kasus pemulihan, kedaluwarsa kunci, konkurensi, dan aksesibilitas sesuai risiko produk sebenarnya; enam baris tersebut merupakan kumpulan awal, bukan penilaian autentikasi lengkap.