Rencana pengujian menjelaskan apa yang akan diuji, mengapa, bagaimana, oleh siapa, dan dalam kondisi apa. Nilainya berasal dari pemahaman bersama tentang pendekatan dan batasannya, bukan dari panjangnya dokumen.
Ketika rencana pengujian berguna
- →Fungsionalitasnya besar, berisiko, atau mencakup tim.
- →Ruang lingkup, prioritas, lingkungan, peran, dan kriteria kesiapan memerlukan kesepakatan yang jelas.
- →Harapan eksternal mencakup audit, kepatuhan, peraturan, atau pelaporan formal.
- →Tanpa rencana yang disepakati, tim dapat menafsirkan kedalaman dan batasan pengujian secara berbeda.
Rencana yang bagus termasuk di dalamnya
- →Menguji tujuan dan risiko utama.
- →Cakupan yang disertakan dan dikecualikan.
- →Jenis dan level pengujian yang berlaku.
- →Lingkungan, data pengujian, dan ketergantungan.
- →Peran, tanggung jawab, waktu, dan kriteria penyelesaian.
Apa yang harus dihindari
- →Templat generik terputus dari produk.
- →Informasi berlebih tidak digunakan oleh siapa pun.
- →Dokumen statis yang ditulis sekali dan tidak pernah diperbarui.
- →Mengganti pemikiran risiko dan strategi aktual dengan dokumen.
Panduan praktis
Rencana yang baik menjawab pertanyaan-pertanyaan nyata: apa yang penting, di mana letak risikonya, apa yang masih belum diuji, apa yang kurang dalam kualitas, dan bukti apa yang mendukung pelepasan. Jika hal ini tidak membantu pengambilan keputusan, maka hal tersebut terlalu rumit atau abstrak.
Contoh yang diisi: rilis formulir pembayaran kecil
Segala sesuatu dalam rencana ini adalah asumsi pelatihan fiktif. Ini bukan laporan tentang bank, pelanggan, atau rilis yang dikirimkan. Aplikasi menerima token pembayaran sintetis dan memanggil stub penyedia lokal yang mengembalikan disetujui, ditolak, atau batas waktu. Tidak ada detail kartu, rekening, atau uang yang sebenarnya. Jumlahnya adalah sen bilangan bulat dalam satu mata uang demo yang dikonfigurasi secara eksplisit.
ID rencana: PAY-DEMO-1; versi: 1; peran penanggung jawab: engineer QA
Tujuan: memvalidasi formulir pembayaran dan mencegah pembayaran sukses ganda.
Objek uji: build demo yang dibekukan; catat commit dan konfigurasi sebenarnya sebelum eksekusi.
Dalam cakupan: pengiriman, validasi, hasil provider, pengulangan request, pengulangan callback, refresh halaman hasil, keyboard, dan tata letak 375 px.
Di luar cakupan: provider nyata, penyelesaian pembayaran nyata, refund, langganan, 3-D Secure, mata uang lain, sertifikasi beban/keamanan.
Lingkungan: aplikasi lokal sementara + stub provider + database uji dengan data awal.
Data: pelanggan/pesanan sintetis baru untuk setiap kasus; reset jurnal stub antar kasus.
Pengamatan: ID request, jurnal pembayaran stub, dan catatan pesanan hanya-baca.
Tim: satu engineer QA; developer tersedia untuk perbaikan; product owner memutuskan risiko tersisa yang diterima.
Estimasi, bukan komitmen: dua hari kerja masing-masing 6 jam QA; 2 jam dukungan developer dan 1 jam tinjauan owner.
Hasil kerja: pemetaan persyaratan/kasus, log eksekusi, bukti tanpa data sensitif, defect, dan rekomendasi rilis.Cakupan berbasis risiko dengan hasil yang dapat diobservasi
Kasus C01–C08, C11 dan C12 berisiko tinggi dalam contoh ini: pembayaran ganda, jumlah yang salah, keberhasilan palsu, atau kesalahan pemutaran ulang dapat merusak kondisi keuangan. C09–C10 merupakan pemeriksaan kegunaan dan masih termasuk dalam cakupan. Harapan berikut adalah persyaratan demo, bukan perilaku pembayaran universal API.
ID Skenario Hasil yang diharapkan
C01 token approved Satu pesanan terkonfirmasi senilai 1999 sen; satu pembayaran diterima
C02 token declined Pesan ditolak; tidak ada pesanan dibayar atau pembayaran sukses
C03 token timeout Status tertunda/tidak diketahui ditampilkan; tidak ada pembayaran kedua otomatis
C04 kunci sama, payload sama dua kali Hasil tersimpan yang sama; satu pembayaran dan satu pesanan
C05 kunci sama, jumlah berubah Konflik dilaporkan; tidak ada pembayaran atau pesanan baru
C06 token pembayaran tidak ada Kesalahan kolom; tidak ada permintaan pembayaran
C07 server menerima jumlah nol Ditolak oleh API; tidak ada pembayaran atau pesanan
C08 callback approved duplikat Satu transisi ke paid; ledger pembayaran mencatat satu keberhasilan
C09 hanya keyboard Semua kontrol terjangkau; pengiriman dan kesalahan dapat ditangani tanpa mouse
C10 viewport 375 px Tidak ada luapan horizontal; total dan kontrol kirim terlihat
C11 refresh halaman hasil Pesanan yang sudah ada ditampilkan; pembayaran tidak dikirim ulang
C12 periksa transaksi 1999 sen UI, request, dan pesanan tersimpan memiliki jumlah dan mata uang yang samaKriteria masuk, penangguhan dan keluar
Kriteria masuk: seluruh 12 hasil yang diharapkan telah ditinjau; identitas build dicatat; mode stub approved/declined/timeout diverifikasi; pelanggan uji dibuat; jurnal pembayaran dapat dibaca; smoke test lingkungan lulus. Jika salah satu syarat gagal, catat penghambatnya alih-alih menyatakan build telah diuji sepenuhnya.
Hentikan sementara ketika jurnal tidak tersedia, fixture tidak dapat direset, atau pembayaran ganda yang diamati mengancam validitas kasus berikutnya. Simpan bukti. Lanjutkan setelah penyebabnya diperbaiki, smoke test lingkungan lulus, serta kasus terdampak direset dan dijalankan ulang.
Kriteria keluar untuk rekomendasi: seluruh 12 kasus dijalankan dengan bukti; seluruh 10 kasus berisiko tinggi lulus; C09 dan C10 lulus atau memiliki pengecualian terdokumentasi dari penanggung jawab yang disebutkan; tidak ada defect terbuka yang menyebabkan keberhasilan ganda, jumlah salah, atau status pembayaran palsu; setiap defect berisiko tinggi yang diperbaiki telah diuji ulang dan pemeriksaan regresi terdampak lulus. Laporkan setiap fungsi yang dikecualikan secara eksplisit. Tenggat waktu saja tidak memenuhi kriteria ini.
Contoh jadwal: hari 1 — peninjauan persyaratan 1 jam, lingkungan/data 1 jam, persiapan kasus 2 jam, eksekusi 2 jam. Hari 2 - sisa eksekusi 2 jam, perbaikan dan pengujian ulang 2 jam, regresi terpengaruh 1 jam, ringkasan 1 jam. Jika perilaku penyedia berubah atau build diganti, perkirakan ulang dan jalankan kembali pemeriksaan yang terkena dampak; jangan diam-diam mempertahankan status “lulus” yang lama.
Templat rencana yang dapat disalin
Rencana / versi / penanggung jawab:
Perubahan dan tujuan bisnis:
Objek uji / build / konfigurasi:
Persyaratan dan risiko utama:
Dalam cakupan / di luar cakupan:
Lingkungan / data sintetis / prosedur reset:
Mekanisme pengamatan dan bukti:
ID kasus yang dipetakan ke risiko dan hasil yang diharapkan:
Peran / kapasitas / estimasi / ketergantungan:
Kriteria masuk:
Kriteria penghentian sementara / melanjutkan:
Kriteria keluar dan pengambil keputusan:
Risiko tersisa / pengecualian / tanggal tinjauan berikutnya:
Tautan laporan eksekusi:Dokumen ini merinci pekerjaan yang harus dilakukan; ia tidak mengklaim kedua belas kasus telah lolos dalam aplikasi pembayaran yang sebenarnya. Selama eksekusi, tambahkan hasil aktual, status, bukti, dan tautan cacat ke setiap kasus. Kirimkan kepada pemilik keputusan rilis cakupan dan risiko yang tersisa, bukan hanya persentase kelulusan.
Lanjutkan belajar
Hubungkan rencana rilis untuk menguji strategi