12 Cara Ampuh Menemukan Bug yang Bisa Langsung Diterapkan oleh QA

Praktik sederhana untuk meningkatkan cara berpikir dan menemukan bug yang lebih efektif.

Menemukan bug bukan hanya tentang menjalankan test case sesuai langkah yang sudah dibuat. Seorang QA perlu berpikir seperti user, memahami risiko, dan mencoba berbagai kondisi yang mungkin terjadi saat aplikasi digunakan.

Dalam pekerjaan sehari-hari, kita tidak mungkin memprediksi semua cara user menggunakan sebuah aplikasi. Karena itu, QA perlu memiliki cara berpikir yang sistematis untuk mencari kemungkinan masalah yang sering terlewat.

Artikel ini membahas 12 cara praktis untuk menemukan bug, mulai dari melihat cara user menggunakan fitur, mencari kondisi ekstrem, menguji batas nilai, mengganggu proses, sampai menguji hak akses. 

Semua cara di bawah ini dibuat sederhana dan bisa langsung diterapkan dalam pekerjaan QA, baik saat melakukan manual testing maupun automation testing.

1. Jangan Test Fitur, Test Cara User Menggunakannya

Sebagai QA, jangan hanya mengikuti alur yang sudah ditentukan di test case. Coba pikirkan bagaimana user sebenarnya akan menggunakan fitur tersebut.

Contoh :

Misalnya ada fitur Login.

Alur normal:

Masukkan username → password → klik Login → berhasil masuk.

Sebagai QA, kita bisa mencoba:

• Klik Login dua kali.
• Mengosongkan username atau password.
• Menekan Back setelah login.
• Melakukan refresh.
• Menggunakan fitur dengan urutan yang berbeda.

Tujuannya yaitu memastikan fitur tetap berjalan dengan benar ketika digunakan dengan cara yang berbeda oleh user. 

Cara menerapkannya di perusahaan, setiap mendapatkan fitur baru, tanyakan:

• Bagaimana user menggunakannya secara normal?
• Apa kesalahan yang mungkin dilakukan user?
• Apa yang terjadi jika user melakukan sesuatu di luar alur normal?

Intinya : Jangan hanya test apakah fitur bekerja. Test bagaimana user menggunakan fitur tersebut.

 2. Berpikirlah Seperti User yang "Nakal"

QA perlu mencoba membuat sistem gagal dengan cara yang masih mungkin dilakukan oleh user.

Contoh

Misalnya ada fitur pembayaran.

User normal:

Pilih metode pembayaran → klik Bayar → selesai.

QA bisa mencoba:

• Klik Bayar berkali-kali.
• Mengubah jumlah pembayaran.
• Kembali ke halaman sebelumnya.
• Membuka halaman pembayaran di tab lain.
• Menggunakan data yang tidak sesuai.

Tujuannya yaitu menemukan celah yang mungkin terjadi ketika user tidak mengikuti alur yang diharapkan.

Cara menerapkannya di perusahaan :

Saat mengetes fitur, tanyakan:

"Kalau saya ingin membuat fitur ini gagal, apa yang akan saya coba?"

Tidak perlu melakukan sesuatu yang tidak masuk akal. Fokus pada tindakan yang masih mungkin dilakukan user.

Intinya : QA tidak hanya mencari kondisi yang benar, tetapi juga mencoba menemukan cara yang dapat membuat sistem gagal. 

3. Selalu Cari Edge Case

Edge case adalah kondisi yang jarang terjadi tetapi masih mungkin terjadi.

Contoh

Misalnya umur yang diperbolehkan:

18–60 tahun.

Jangan hanya test:

25
30
40

Coba juga:

17
18
60
61

Bisa jadi bug justru muncul pada kondisi yang jarang digunakan.

Cara menerapkannya di perusahaan

Untuk setiap fitur, tanyakan:

• Apa kondisi paling kecil?
• Apa kondisi paling besar?
• Apa kondisi yang jarang terjadi?
• Apa yang terjadi jika data tidak biasa digunakan?

Intinya : Jangan hanya test kondisi yang umum. Cari kondisi yang jarang terjadi tetapi masih mungkin terjadi, skenario ekstrem, atau kasus aneh.

 

4. Mainkan Boundary Value

Boundary value adalah nilai yang berada di sekitar batas yang ditentukan sistem.

Contoh

Password harus memiliki minimal 8 karakter.

Test:

6 karakter → ❌ (bawah minimum)
7 karakter → ❌ (minimum)
8 karakter → ✅ (tepat batas)
9 karakter → ✅ (maksimum)
10 karakter → ✅ (atas maksimum) . dll.

Bukan hanya:

10 karakter → ✅

Karena bug sering muncul di sekitar batas.

Cara menerapkannya di perusahaan

Kalau requirement memiliki batas:

Test nilai sebelum batas, tepat pada batas, dan setelah batas.

Contoh:

Minimum = 8

(bawah minimum)6 →(minimum)7 → 8 → 9 (maksimum)→ 10 (Atas maksimum)

Intinya Kalau ada batas, selalu test nilai sebelum, tepat pada, dan setelah batas tersebut.

5. Ubah Kondisi Device

Untuk aplikasi web atau mobile, jangan hanya menggunakan satu kondisi device.

Contoh

Misalnya aplikasi berjalan dengan baik di:

Chrome + Windows + layar besar.

Coba juga:

• Mobile.
• Tablet.
• Browser berbeda.
• Screen size berbeda.
• Portrait dan landscape.
• Device dengan spesifikasi lebih rendah.
• Ubah jaringan
• Baterai
• Kecerahan
• Bahasa
• Mode Gelap
• Orientasi

Tujuannya:

Memastikan aplikasi tetap berjalan dengan benar pada kondisi device yang berbeda.

Cara menerapkannya di perusahaan

Sesuaikan dengan target aplikasi. Misalnya aplikasi mobile, prioritaskan:

Device
OS
Screen Size
Orientation
Browser
Ubah jaringan
Baterai
Kecerahan
Bahasa
Mode gelap

Tidak harus mengetes semua device. Fokus pada device yang paling banyak digunakan user. 

Intinya

Jangan menganggap aplikasi yang bekerja di satu device pasti bekerja di semua device.

 

 

6. Ganggu Proses di Tengah Jalan

Coba hentikan atau ganggu proses yang sedang berjalan.

Contoh

User sedang melakukan upload:

Upload
↓
50%
↓
Internet terputus

Periksa:

Apa yang terjadi?

Atau:

Payment
↓
Proses
↓
User menekan Back

Apakah aplikasi tetap aman?

Cara menerapkannya di perusahaan

Coba ganggu proses dengan:

• Mematikan internet.
• Putuskan koneksi
• Isi/ubah data saat proses berjalan
• Menekan Back.
• Refresh.
• Menutup aplikasi.
• Berpindah halaman.
• Menekan tombol berulang kali.

lalu lihat :

• Apakah data aman dan stabil

Intinya

Test apa yang terjadi ketika proses yang sedang berjalan tiba-tiba terganggu.

7. Fokus di Area yang Paling Sering Rusak

Tidak semua fitur memiliki risiko yang sama.

Sebagai QA, prioritaskan testing pada area yang:

• Sering mengalami bug.
• Banyak perubahan.
• Kompleks.
• Terhubung dengan banyak fitur.
• Berdampak besar jika gagal.
• Bug history
• Modul kritikal.
• Flow yang sering bermasalah.

Contoh

Dalam aplikasi e-commerce:

Login       → Risiko sedang
Search      → Risiko sedang
Payment     → Risiko tinggi

Payment biasanya perlu perhatian lebih karena bug dapat menyebabkan:

transaksi gagal, duplicate payment, atau masalah finansial.

 

Cara menerapkannya di perusahaan

Sebelum testing, tanyakan:

"Bagian mana yang paling berisiko jika terjadi bug?"

Mulai testing dari area tersebut.

Intinya

Jangan membagi waktu testing secara rata. Fokuskan effort pada area yang paling berisiko.

8. Kombinasikan Fitur

Bug tidak selalu muncul ketika fitur diuji sendiri. Kadang bug muncul ketika beberapa fitur digunakan bersama.

Contoh

Fitur:

Product
+
Voucher
+
Cart
+
Payment

Masing-masing mungkin bekerja dengan baik.

Tetapi ketika digunakan bersama:

Pilih Product
↓
Apply Voucher
↓
Add Cart
↓
Checkout
↓
Payment

bisa muncul masalah pada:

total harga, diskon, atau pembayaran.

Cara menerapkannya di perusahaan

Cari fitur yang saling berhubungan dan test sebagai satu flow.

Contoh:

Login → Product → Cart → Checkout → Payment

Intinya

Jangan hanya test fitur secara terpisah. Test juga bagaimana fitur bekerja ketika digabungkan. 

9. Test Interrupt

Interrupt adalah gangguan dari luar aplikasi yang terjadi ketika user sedang menggunakan aplikasi.

Contoh Mobile

User sedang melakukan pembayaran:

Payment
↓
Incoming Call

Setelah telepon selesai:

Apakah proses pembayaran tetap aman?

Contoh lain:

• Notification masuk.
• SMS masuk.
• Alarm muncul.
• User menerima telepon.
• User berpindah aplikasi.
• Aplikasi masuk background.

Cara menerapkannya di perusahaan

Cari gangguan yang realistis sesuai jenis aplikasi.

Untuk mobile, misalnya:

Payment → Incoming Call → kembali ke aplikasi → cek status payment.

Intinya

Test apakah aplikasi tetap menjaga state dan data ketika ada gangguan dari luar.

10. Mainkan Waktu

Beberapa fitur sangat bergantung pada waktu.

Contoh

OTP berlaku selama 5 menit.

Test:

4:59 → masih valid
5:00 → cek behavior
5:01 → expired

Contoh lain:

• Session timeout.
• Token expiration.
• Jadwal Promo (Ubah Tanggal & Ubah Waktu)
• Jadwal transaksi (Ubah Tanggal & 
• Ubah Waktu)
• Booking. 
• Tanggal jatuh tempo.

Cara menerapkannya di perusahaan

Jika fitur memiliki batas waktu, test:

Sebelum waktu → tepat pada waktu → setelah waktu.

Intinya

Kalau fitur bergantung pada waktu, jangan hanya test kondisi normal. Test juga sebelum dan setelah batas waktunya. 

11. Test dengan Data Kotor

Jangan hanya menggunakan data yang rapi dan benar. Coba gunakan data yang tidak ideal atau tidak sesuai format.

Contoh

Field nama:

Ainul Idham

Coba juga:

""
"   "
Ainul123
@#$%
Ainul        Idham

Untuk API, bisa mencoba:

{
  "age": "abc"
}

padahal seharusnya:

{
  "age": 33
}

Cara menerapkannya di perusahaan

Coba data seperti:

• Kosong.
• null.
• Spasi.
• Format salah.
• Tipe data salah.
• Terlalu panjang.
• Karakter khusus (special character).
• Data duplikat.
  
• Data tidak valid

Intinya

Jangan hanya test dengan data yang benar. Test juga bagaimana sistem menangani data yang buruk atau tidak sesuai.

 

12. Test Hak Akses

Pastikan user hanya dapat mengakses fitur dan data yang memang menjadi haknya.

Contoh

Misalnya terdapat tiga role:

User
Manager
Admin

User biasa:

View Product → ✅
Delete Product → ❌

Admin:

View Product → ✅
Delete Product → ✅

Cara menerapkannya di perusahaan

Jangan hanya mengecek apakah tombol terlihat atau tidak.

Coba akses langsung melalui:

• URL.
• API.
• Request dengan token role berbeda.

Contoh:

User Token
↓
DELETE /products/123
↓
403 Forbidden

Intinya

Jangan hanya memastikan user tidak melihat fitur. Pastikan user juga tidak bisa mengakses fitur tersebut tanpa permission.

Kesimpulan

Menemukan bug bukan hanya tentang menjalankan test case. QA perlu memiliki cara berpikir untuk melihat kemungkinan masalah dari berbagai sisi.

12 cara di atas dapat dirangkum menjadi:

Pahami user → cari kondisi tidak normal → uji batas → ganggu proses → prioritaskan risiko → kombinasikan fitur → uji keamanan.

Dengan menerapkan cara berpikir ini dalam pekerjaan sehari-hari, QA dapat menemukan bug yang lebih relevan, lebih kritis, dan lebih dekat dengan kondisi yang benar-benar mungkin terjadi di production.