Cara Membuat Test Case

Apa saja yang perlu di perhatikan seblum membuat test case :

1. Test Case Per Fitur (Unit & Functional Testing)

Biasanya yang menjalankan QA (atau Developer) 

apa yang di cek : Detail teknis & logika fungsi.

Ini adalah fondasi. Kamu menguji setiap komponen secara isolasi.

• Tujuan: Memastikan tombol, form, dan logika hitungan di satu layar berjalan sesuai desain.

• Isinya: Detail-detail teknis.

• Contoh: 

• Di halaman Checkout, kamu hanya menguji: "Apakah tombol 'Tambah Barang' berfungsi menambah angka di keranjang?". Kamu tidak peduli dulu soal pembayaran, hanya fokus pada fungsi tombol itu saja.
• Test case untuk validasi kolom password (minimal 8 karakter, harus ada angka, dsb).

2. Integration Testing

Biasanya dilakukan QA
Apa yang di cek : Komunikasi antar modul/API.

Ini adalah tahap "menghubungkan". Kamu menguji apakah dua atau lebih modul bisa "berbicara" satu sama lain.

• Tujuan: Memastikan data dari Fitur A tersambung dengan benar ke Fitur B.

• Isinya: Skenario pengiriman data.

• Contoh: 

• Fitur Keranjang Belanja harus bisa mengirimkan data total harga ke fitur Pembayaran. Kamu menguji apakah harga yang tampil di keranjang sama dengan yang muncul di halaman pembayaran. (Seringkali bug muncul di sini, di mana data hilang saat dipindahkan antar modul).
• Memastikan bahwa saat user klik "Bayar" di aplikasi, API pembayaran menerima data order_id dan total_amount yang benar.

3. End-to-End (E2E) Testing / System Testing

Biasanya dilakukan oleh QA

Apa yang di cek : User Journey (Alur bisnis).

Ini adalah pengujian skenario lengkap dari kacamata pengguna.

• Tujuan: Memastikan seluruh alur sistem bekerja dari awal sampai akhir untuk mencapai satu tujuan bisnis.

• Isinya: Skenario alur kerja pengguna dari titik A ke titik Z.

• Contoh: 

• User login -> cari barang -> beli -> bayar -> dapat invoice. Kalau ada satu saja langkah yang macet di tengah, maka E2E failed. Inilah yang biasanya otomatisasi (seperti pakai Playwright) sangat diandalkan.
• User berhasil melakukan transaksi dari awal hingga mendapatkan notifikasi sukses di akhir.

4. User Acceptance Testing (UAT)

Biasanya dilakukan oleh User / Klien 
Apa yang di cek: Pengalaman & kebutuhan bisnis.

Ini adalah tahap akhir sebelum release. Penguji sebenarnya adalah pengguna asli atau klien (bukan QA).

• Tujuan: Memastikan aplikasi tersebut berguna dan sesuai dengan keinginan bisnis pengguna, bukan sekadar "tidak ada bug".

• Contoh: QA mungkin merasa aplikasi sudah sempurna karena semua test case (1-3) pass. Tapi saat UAT, pengguna bilang: "Langkah pembayarannya terlalu ribet, saya tidak suka." Itulah UAT—menguji usability dan kepuasan.

Test case adalah panduan langkah demi langkah untuk memastikan fitur atau aplikasi berjalan sesuai keinginan.

Penjelasan Variasi Berdasarkan Tahapan

1. Per Fitur (Unit & Functional)

   • Data Valid & Invalid: Kamu harus mencoba input yang benar dan yang salah untuk melihat apakah validasi di level field bekerja.

   • Boundary Value Analysis: Sangat krusial di sini untuk memastikan angka atau jumlah karakter yang berada di batas bawah dan atas berfungsi sesuai aturan.

   • Empty State: Menguji apakah sistem memberikan peringatan jika form tidak diisi.

2. Integration Testing

   • Data Flow: Fokus pada variasi apakah data yang dikirim dari satu modul (misal: Checkout) sampai dengan utuh dan benar ke modul tujuan (misal: Database atau Payment Gateway).

   • Respon Error: Jika modul A mengirim data yang salah, apakah modul B bisa menangani pesan error-nya dengan benar?

3. End-to-End (E2E) Testing

   • State Transition: Menguji pergerakan pengguna dari satu status ke status berikutnya (misal: dari "Login" ke "Pilih Barang" ke "Bayar").

   • Interupsi: Variasi skenario di mana proses di tengah jalan terganggu, seperti koneksi internet putus atau browser di-refresh.

   • Stress Testing: Menguji apakah tombol penting (seperti "Beli") tetap aman jika diklik berkali-kali oleh pengguna dalam alur yang utuh.

1. User Acceptance Testing (UAT)

   • Pengalaman Pengguna (UX): Variasi skenario di sini tidak lagi soal "apakah coding-nya benar", melainkan "apakah alur ini membuat user bingung".

   • Kesesuaian Bisnis: Memastikan apakah fitur tersebut sudah sesuai dengan kebutuhan nyata klien atau pemilik bisnis.

   • Cross-Environment/Compatibility: Memastikan aplikasi berjalan lancar di berbagai perangkat (HP/Desktop) atau browser yang digunakan oleh end-user.