QA Tester: Jenis Pengujian dan Cara Menulis Test Case yang Baik
Mengenal jenis pengujian software (unit, integrasi, sistem, regresi, UAT, performa, keamanan), cara menulis test case dan laporan bug yang jelas, serta contohnya untuk aplikasi kesehatan.
Tester bukan sekadar "orang yang mencari kesalahan programmer". Tester adalah wakil pengguna di dalam tim: orang yang memastikan aplikasi benar-benar bisa dipakai untuk pekerjaan nyata sebelum sampai ke tangan pengguna. Di aplikasi kesehatan, kesalahan kecil seperti hasil lab tertukar atau tagihan terhitung ganda bisa berdampak besar.
Jenis-jenis pengujian
| Jenis | Yang diuji | Biasanya oleh |
|---|---|---|
| Unit test | Fungsi atau kelas terkecil secara terpisah | Programmer, otomatis |
| Integration test | Interaksi antarmodul atau dengan sistem luar (database, API BPJS, SATUSEHAT) | Programmer / QA |
| System test | Aplikasi utuh dari sudut pandang pengguna | QA |
| Regression test | Memastikan fitur lama tidak rusak karena perubahan baru | QA, sebaiknya otomatis |
| UAT | Kesesuaian dengan kebutuhan dan alur kerja klien | Pengguna / klien |
| Performance test | Kecepatan dan ketahanan saat banyak pengguna | QA / DevOps |
| Security test | Celah keamanan: akses tanpa izin, injeksi, kebocoran data | QA / spesialis keamanan |
Anatomi test case yang baik
Test case yang baik bisa dijalankan oleh orang lain tanpa bertanya, dan hasilnya jelas: lulus atau gagal. Contoh:
| Bagian | Isi |
|---|---|
| ID | TC-DAFTAR-012 |
| Judul | Mencegah pendaftaran ganda pasien dengan NIK yang sama |
| Prasyarat | Login sebagai petugas pendaftaran. Pasien dengan NIK uji 3202xxxxxxxx0001 sudah terdaftar. |
| Langkah | 1. Buka menu Pasien Baru. 2. Isi NIK 3202xxxxxxxx0001 dan data lain. 3. Klik Simpan. |
| Hasil yang diharapkan | Muncul pesan "NIK sudah terdaftar" beserta tautan ke data pasien lama. Tidak ada data baru yang tersimpan. |
| Prioritas | Tinggi |
Perhatikan bahwa hasil yang diharapkan harus spesifik dan bisa diperiksa. "Sistem berjalan normal" bukanlah hasil yang diharapkan.
Teknik mencari skenario uji
- Boundary value: uji nilai di batas. Jika umur harus 0–150 tahun, uji -1, 0, 150, dan 151.
- Equivalence partitioning: kelompokkan input yang perilakunya sama, lalu uji satu wakil dari setiap kelompok, misalnya pasien umum, BPJS, dan asuransi swasta.
- Negative test: apa yang terjadi jika input kosong, format salah, koneksi terputus, atau tombol diklik dua kali?
- Alur nyata: ikuti perjalanan pasien dari pendaftaran, poli, lab, farmasi, sampai kasir, dan pastikan data mengalir dengan benar di setiap langkah.
Menulis laporan bug yang dihargai programmer
- Judul yang spesifik: "Total tagihan ganda saat resep diubah setelah dicetak", bukan "Kasir error".
- Langkah untuk mereproduksi, langkah demi langkah.
- Hasil yang diharapkan vs hasil sebenarnya.
- Bukti: screenshot, rekaman layar, atau potongan log.
- Lingkungan: versi aplikasi, browser, dan akun yang dipakai.
- Tingkat keparahan: kritis, tinggi, sedang, atau rendah.
Jangan pernah melampirkan data pasien asli di laporan bug. Gunakan data uji, atau samarkan identitasnya.
Otomatisasi: mulai dari mana?
Tidak semua pengujian perlu diotomatisasi. Prioritaskan yang sering diulang dan berisiko tinggi: perhitungan tagihan, alur login dan hak akses, serta integrasi yang sering berubah. Test otomatis ini dijalankan di pipeline CI setiap kali ada perubahan. Penjelasannya ada di artikel DevOps untuk tim kecil.
Mengukur hasil pengujian
Ringkas hasil pengujian dengan angka yang mudah dipahami manajer dan klien: execution rate, pass rate, dan defect removal efficiency. Hitung dengan kalkulator metrik QA.