Test Scenario, Test Case, dan Bug Report
Overview
Test scenario, test case, dan bug report adalah tiga elemen penting dalam proses pengujian perangkat lunak. Ketiganya saling melengkapi untuk memastikan aplikasi berjalan sesuai harapan dan bebas dari kesalahan.
Test Scenario vs Test Case
Perbedaan mendasar keduanya adalah pada pertanyaannya:
- Test Scenario: Menjawab pertanyaan, "APA YANG HARUS DIUJI?". Ini adalah gambaran umum apa yang diuji untuk memastikan fungsi aplikasi sesuai kebutuhan.
- Test Case: Menjawab pertanyaan, "BAGAIMANA MELAKUKAN PENGUJIAN?". Ini adalah langkah detail pengujian, termasuk input, proses, dan hasil yang diharapkan.
Template Test Scenario
Test scenario biasanya cukup sederhana, menjelaskan fitur yang diuji.
| Field | Keterangan |
|---|---|
| ID Scenario | Nomor unik skenario |
| Deskripsi | Ringkasan skenario pengujian |
| Modul/Fitur | Modul atau fitur yang diuji |
Template Test Case
Test case jauh lebih detail dan berisi langkah-langkah spesifik.
| Field | Keterangan |
|---|---|
| ID Test Case | Nomor unik test case |
| Deskripsi | Ringkasan singkat tentang pengujian |
| Precondition | Kondisi awal sebelum pengujian |
| Test Steps | Langkah-langkah detail pengujian |
| Test Data | Data yang digunakan untuk pengujian |
| Expected Result | Hasil yang diharapkan sesuai requirement |
| Actual Result | Hasil aktual yang muncul setelah pengujian |
| Status | Lulus/Gagal (Pass/Fail) |
Bug Report
Saat Actual Result tidak sama dengan Expected Result, saat itulah kita menemukan "bug". Bug Report adalah laporan formal mengenai kesalahan atau masalah pada sistem.
Saat melaporkan bug, penting untuk menentukan tingkat keparahan (Severity) dan prioritas (Priority).
Bug Severity (Tingkat Keparahan)
Ini adalah ukuran dampak bug pada fungsi software.
- Critical: Menyebabkan kegagalan total pada sistem atau fungsionalitas utama. Aplikasi tidak dapat digunakan atau data rusak.
- Major (High): Menyebabkan fungsionalitas utama tidak bekerja dengan benar, tetapi tidak menyebabkan sistem crash total.
- Minor (Medium): Bug yang tidak memengaruhi fungsionalitas utama, tetapi dapat menyebabkan ketidaknyamanan bagi pengguna.
- Low: Bug yang tidak mengakibatkan kerusakan pada sistem.
Bug Priority (Prioritas Perbaikan)
Ini adalah ukuran seberapa mendesak bug tersebut harus diperbaiki, biasanya ditentukan oleh manajer.
- P1 - (Urgent/Critical): Bug yang harus segera diperbaiki karena memblokir fungsionalitas utama atau menyebabkan sistem crash.
- P2 - High: Bug penting yang harus diperbaiki secepatnya karena memengaruhi banyak pengguna, tetapi tidak se-mendesak P1.
- P3 - Medium: Bug yang bisa diperbaiki di siklus rilis berikutnya. Tidak memengaruhi fungsionalitas inti.
- P4 - Low: Bug minor atau kosmetik yang bisa diperbaiki kapan saja.
Contoh Format Bug Report
Berikut adalah contoh format laporan bug yang baik:
| Bug Title | Perhitungan BMI salah saat input berat 60kg dan tinggi 170cm |
|---|---|
| Bug ID | BMI-001 |
| Step to reproduce | 1. Buka aplikasi BMI 2. Masukkan Berat = 60 3. Masukkan Tinggi = 170 4. Klik tombol "Hitung" |
| Actual Result | Hasil BMI = 12.5 |
| Expected Result | Hasil BMI seharusnya = 20.8 |
| Severity | Major (High) |
| Priority | P2 - High |
| Assignee | Developer |
| Reporter | SQA (Software Quality Assurance) |
Cara Terbaik Menghindari Bug
Cara terbaik untuk menghindari bug adalah dengan menerapkan praktik terbaik di seluruh siklus pengembangan, tidak hanya saat pengujian.
- Pahami Persyaratan: Pastikan semua persyaratan dipahami dengan jelas oleh seluruh tim.
- Unit Testing: Lakukan pengujian unit untuk mendeteksi bug di tahap awal pengembangan.
- Code Review: Minta pengembang lain meninjau kode untuk menemukan kesalahan.
- Rencana Pengujian: Buat test plan yang komprehensif.
- Pengujian Otomatis: Manfaatkan automation testing untuk deteksi bug yang lebih cepat.
- Kolaborasi Tim: Tingkatkan komunikasi antara pengembang dan penguji.
← Kembali ke Daftar Blog