Dalam artikel ini, saya akan membagikan "resep rahasia" bagaimana melakukan manual testing yang terstruktur, mulai dari persiapan hingga pelaporan bug yang membuat developer berterima kasih pada Anda. Mari kita bedah satu per satu!

Mengapa Manual Testing Tetap Tak Tergantikan?

Sebelum masuk ke teknis, kita perlu paham filosofinya. Manual testing bukan sekadar "klik-klik asal." Ini adalah seni memahami psikologi pengguna.

1. Observasi User Experience (UX): Automation hanya mengecek benar/salah secara logika. Manual testing mengecek feel. Apakah navigasinya intuitif? Apakah skema warnanya menyakitkan mata?

2. Exploratory Testing: Seringkali bug justru muncul saat kita melakukan hal-hal "aneh" yang tidak terpikirkan saat menulis skrip otomasi. Insting QA manusia dalam mengeksplorasi sudut-sudut gelap aplikasi sangat krusial.

3. Biaya dan Efisiensi pada Tahap Awal: Untuk fitur yang masih sering berubah (fase agile yang cepat), menulis skrip otomasi justru membuang waktu. Manual testing jauh lebih adaptif.

Tahap 1: Persiapan & Analisis Dokumen (SDLC Understanding)

Banyak QA junior langsung terjun ke aplikasi tanpa persiapan. Hasilnya? Mereka bingung membedakan mana "fitur" dan mana "bug".

Langkah pertama adalah memahami SDLC (Software Development Life Cycle) dan menganalisis dokumen requirement (PRD - Product Requirement Document).

• Apa tujuannya? Kamu harus tahu persis apa yang seharusnya dilakukan aplikasi.

• Case Study: Misal kita sedang menguji Fitur Input Stok Barang di aplikasi manajemen toko.

• Analisis: Jika dokumen bilang "Stok tidak boleh minus", maka itu adalah hukum mutlak yang harus kamu pegang. Jika dokumen tidak menyebutkan batas maksimal input, tanyakan ke Product Manager: "Apakah boleh user input 1 miliar stok?"

Tahap 2: Merancang Skenario (Test Case) – Black Box Testing

Setelah paham maunya aplikasi, saatnya menulis skenario. Dalam Black Box Testing, kita fokus pada input dan output tanpa perlu melihat kode di dalamnya. Ada dua jalur utama yang wajib ada:

1. Happy Path (Jalur Normal)

Ini adalah skenario di mana user adalah "anak baik" yang mengikuti aturan.

• Contoh: User memasukkan nama barang "Kopi Susu", jumlah "10", lalu klik simpan. Hasilnya? Data tersimpan sukses.

2. Negative Path (Jalur Error)

Ini adalah tempat di mana kebanyakan bug bersembunyi. Kita mencoba menjadi user yang "nakal" atau ceroboh.

• Contoh: Masukkan jumlah stok dengan huruf ("abc"), masukkan angka negatif ("-5"), atau biarkan kolom nama kosong lalu klik simpan.

• Pro Tip: Jangan lupa cek boundary value. Jika batas input stok adalah 1-1000, tes angka 0, 1, 1000, dan 1001.

Tahap 3: Eksekusi Testing & Test Environment

Sekarang saatnya "bermain". Tapi ingat, jangan menguji di tempat developer sedang koding. Pastikan kamu punya Test Environment (Staging/Sandbox) yang stabil.

Tips menjaga fokus saat pengujian berulang:

• Gunakan Checklist: Agar tidak ada skenario yang terlewat.

• Istirahat Sejenak: Mata QA bisa mengalami "blind spot" jika terus-menerus melihat layar yang sama selama 4 jam. Segarkan pikiran agar ketelitian tetap tajam.

• Gunakan Variasi Data: Jangan gunakan nama "Test 1", "Test 2" terus. Coba gunakan karakter unik (emoji, tanda petik) untuk melihat apakah aplikasi crash.

Tahap 4: Cara Menulis Bug Report yang Profesional

Inilah bagian yang membedakan QA Senior dan Junior. Laporan bug yang buruk akan membuat developer bolak-balik bertanya ke kamu. Laporan yang baik akan membuat bug cepat diperbaiki.

Komponen wajib dalam Bug Report:

1. Judul yang Jelas: Singkat namun deskriptif. (Contoh: [STOK] Error saat input stok dengan angka negatif di halaman Gudang).

2. Steps to Reproduce: Langkah-langkah detail untuk memunculkan kembali bug tersebut. Jangan ada langkah yang terlewat!

3. Actual Result: Apa yang terjadi sekarang? (Contoh: Aplikasi crash dan keluar pesan error server 500).

4. Expected Result: Apa yang seharusnya terjadi? (Contoh: Muncul pesan validasi 'Jumlah stok tidak boleh negatif').

5. Environment: Di HP apa? Browser apa? Versi aplikasi berapa?

6. Evidence: Screenshot atau rekaman layar (GIF/Video). Satu gambar lebih berarti dari seribu kata.

Tahap 5: Regression & Retesting (Memastikan Kualitas)

Setelah developer bilang "Bug sudah fix!", jangan langsung percaya.

• Retesting: Menguji kembali skenario yang tadinya gagal untuk memastikan sudah benar-benar oke.

• Regression Testing: Inilah yang sering dilupakan. Kamu harus mengecek fitur lain yang berkaitan.

• Analogi: Developer memperbaiki keran di kamar mandi, tapi gara-gara perbaikan itu, tiba-tiba wastafel di dapur jadi mati. Itulah gunanya regresi; memastikan perbaikan tidak merusak fitur lain yang sudah stabil.

Contoh Nyata: Menguji Fitur Upload komposisi produk

Mari kita praktiskan ilmu di atas ke dalam satu kasus nyata agar kamu punya gambaran utuh. (Secara garis besar)

Kesimpulan: Kualitas adalah Mindset

Belajar QA manual bukan soal teknis semata, tapi soal ketelitian dan rasa peduli terhadap pengguna akhir. Dengan mengikuti langkah-langkah di atas—mulai dari analisis dokumen hingga regresi—kamu sudah selangkah lebih maju untuk menjadi seorang QA Lead yang handal.