Modul 1 — Dari Tumpukan Kasus Uji Menjadi Test Suite

Rapat yang membuat semua orang diam

Bayangkan kamu penguji yang baru dua minggu bergabung di tim SIMCUTI, aplikasi pengajuan cuti karyawan di PT Sinar Nusantara. Di hari pertama kamu diberi satu berkas: uji-simcuti.xlsx, berisi 96 baris kasus uji yang ditulis bergantian oleh empat orang selama satu setengah tahun. Berkas itu rapi. Kolomnya lengkap: nomor, judul, langkah, hasil yang diharapkan, status. Tidak ada yang malas di tim ini.

Lalu datang rapat kesiapan rilis. Manajer rilis mengajukan tiga pertanyaan, dan tidak satu pun bisa dijawab dari berkas tadi:

1. Kalau 96 baris ini dijalankan dan semuanya lulus, kebutuhan mana yang sudah terbukti berjalan?
2. Kebutuhan mana yang sampai sekarang belum disentuh oleh satu baris pun?
3. Minggu depan aturan sisa jatah cuti akan diubah. Baris mana saja yang harus dijalankan ulang?

Ruangan diam. Bukan karena tidak ada yang tahu aplikasinya — justru semua orang di ruangan itu hafal alur SIMCUTI. Diamnya karena berkas itu, seberapa pun rajin ditulis, memang tidak dirancang untuk menjawab pertanyaan semacam itu.

Masalahnya bukan jumlah, dan bukan kerajinan

Godaan pertama saat menghadapi situasi ini adalah menambah baris. Kalau pertanyaannya tidak terjawab, mungkin kasus ujinya kurang banyak. Tambah tiga puluh baris lagi, semoga cukup.

Tambahan itu tidak akan menolong. Berkas dengan 126 baris akan gagal menjawab ketiga pertanyaan tadi dengan cara yang persis sama, hanya butuh waktu lebih lama untuk dijalankan. Yang hilang dari berkas itu bukan volume, melainkan alamat: tidak ada satu pun baris yang menyatakan dari kebutuhan mana ia lahir dan bagian mana dari kebutuhan itu yang ia buktikan. Tanpa alamat, kumpulan kasus uji hanya bisa menjawab satu pertanyaan — apakah baris ini lulus atau gagal — dan tidak pernah bisa menjawab apa artinya kalau ia lulus.

Perbedaan antara tumpukan kasus uji dan sebuah test suite terletak persis di titik itu. Test suite bukan folder yang lebih rapi. Test suite adalah kumpulan kasus uji yang hubungannya dengan kebutuhan dinyatakan secara terbuka, sehingga hasil menjalankannya bisa dipertanggungjawabkan kepada orang yang memutuskan rilis.

Berkenalan dengan SIMCUTI

SIMCUTI akan menemani kamu sepanjang kelas ini, jadi mari kita pasang dasarnya sekarang. Sistem ini melayani pengajuan dan persetujuan cuti karyawan. Untuk modul Pengajuan Cuti Tahunan, dokumen kebutuhan PT Sinar Nusantara memuat empat butir berikut:

• KEB-01 — Karyawan tetap dengan masa kerja minimal 12 bulan berhak mengajukan cuti tahunan sebanyak-banyaknya 12 hari kerja dalam satu tahun berjalan.
• KEB-02 — Setiap pengajuan harus disetujui atasan langsung. Pengajuan yang tidak ditanggapi sampai akhir hari kerja ketiga naik otomatis ke atasan tingkat dua.
• KEB-03 — Sistem menolak pengajuan yang melebihi sisa jatah cuti dan menampilkan pesan yang memuat jumlah sisa jatah karyawan tersebut.
• KEB-04 — Karyawan kontrak dengan masa kerja kurang dari 12 bulan tidak dapat mengajukan cuti tahunan; menu pengajuan tidak aktif baginya.

Empat kebutuhan, ditulis dalam bahasa yang wajar dipakai tim SDM Indonesia. Sederhana, tetapi cukup untuk memperlihatkan seluruh persoalan keterlacakan yang akan kita bahas.

Ke mana modul ini membawa kamu

Modul ini punya satu tujuan praktis: membuat kamu sanggup berdiri di rapat seperti tadi dan menjawab ketiga pertanyaan itu dengan tenang. Jalannya begini.

Unit berikutnya, unit kuliah, membedah empat istilah yang sering dipakai bergantian padahal fungsinya berbeda — test plan, test suite, test case, test run — lalu menyambungkannya menjadi satu rantai keterlacakan. Unit ketiga mengerjakan kasus SIMCUTI langkah demi langkah: kita ambil lima baris dari berkas tadi yang menyangkut modul Pengajuan Cuti Tahunan, memetakannya ke empat kebutuhan di atas, dan melihat sendiri di mana keterlacakannya putus. Sesudah itu ada unit miskonsepsi, unit refleksi untuk kamu terapkan pada pekerjaanmu sendiri, kuis, dan rangkuman.

Satu hal yang perlu kamu tahan sejak sekarang: sepanjang modul ini kita tidak akan menulis satu baris kode otomatisasi pun. Otomatisasi datang di modul-modul berikutnya. Alasannya sederhana — mengotomasi tumpukan yang tidak terlacak hanya membuat kamu mendapatkan jawaban yang salah lebih cepat.

Gagasan besar unit ini

Satu gagasan yang perlu kamu bawa keluar dari unit ini: yang membedakan test suite dari tumpukan kasus uji bukan isinya, melainkan strukturnya. Dua tim bisa memiliki kasus uji yang persis sama, satu tim memilikinya sebagai suite dan tim lain sebagai tumpukan. Bedanya ada pada apakah setiap kasus uji punya alamat kembali ke kebutuhan, dan apakah alamat itu bisa dibaca dari dua arah.

Untuk sampai ke sana, kita rapikan dulu empat istilah yang di lapangan sering dipakai bergantian.

Empat istilah, empat fungsi berbeda

Test case (kasus uji) adalah satu pemeriksaan yang bisa dijalankan: ada kondisi awal, data konkret, langkah, dan satu hasil yang diharapkan. Ciri kasus uji yang sehat: dua orang berbeda yang menjalankannya akan sampai pada kesimpulan lulus/gagal yang sama. Kalau hasilnya bergantung pada tafsiran pembaca, itu belum kasus uji — itu catatan niat.

Test suite adalah kumpulan kasus uji yang disusun untuk satu tujuan tertentu dan dijalankan sebagai satu kesatuan: suite regresi, suite modul Pengajuan Cuti Tahunan, suite asap sebelum rilis. Suite punya batas yang jelas — kamu bisa menyebutkan apa yang di dalam dan apa yang di luar — dan punya pernyataan cakupan: kebutuhan apa saja yang diklaim dijaga olehnya.

Test run (eksekusi uji) adalah satu kali menjalankan sebuah suite pada satu versi perangkat lunak, pada satu waktu, di satu lingkungan. Test run selalu punya tanggal dan versi. Suite yang sama dijalankan Senin pada versi 2.3 dan Kamis pada versi 2.4 menghasilkan dua test run berbeda dari satu suite yang sama. Ini titik yang paling sering kacau: orang menyebut hasil eksekusi sebagai 'suite', lalu bingung ketika hasilnya berubah padahal isinya tidak.

Test plan (rencana uji) adalah dokumen keputusan, bukan dokumen pemeriksaan. Ia menjawab pertanyaan-pertanyaan tingkat rilis: apa yang diuji dan apa yang sengaja tidak diuji, siapa mengerjakan, di lingkungan apa, kapan, dengan risiko apa, dan syarat apa yang harus dipenuhi agar rilis dianggap layak. Test plan tidak memuat langkah menekan tombol. Ia memuat alasan.

Hubungan keempatnya dalam siklus rilis bisa diringkas begini: test plan memutuskan apa yang perlu dijamin; test suite adalah alat penjaminannya; test case adalah satuan terkecil alat itu; test run adalah bukti bahwa alat itu benar-benar dipakai pada versi tertentu. Kalau rapat rilis menanyakan cakupan, jawabannya ada di suite. Kalau menanyakan hasil, jawabannya ada di run. Kalau menanyakan kenapa area tertentu tidak diuji, jawabannya ada di plan.

Rantai keterlacakan: empat simpul

Keterlacakan bukan kolom tambahan di spreadsheet. Ia adalah rantai dengan empat simpul yang harus tersambung utuh:

Kebutuhan → kondisi uji → kasus uji → hasil eksekusi.

Simpul kedua, kondisi uji, adalah yang paling sering dilewati orang, dan justru di situ sebagian besar lubang cakupan lahir. Kondisi uji adalah satu hal spesifik di dalam kebutuhan yang layak diperiksa secara terpisah. Sebuah kebutuhan yang tampak sederhana hampir selalu memuat beberapa kondisi uji sekaligus, karena setiap titik keputusan di dalamnya melahirkan kondisi baru: jalur normal ketika syarat terpenuhi, jalur penolakan ketika syarat dilanggar, dan nilai batas itu sendiri — persis di angka atau tenggat yang disebut kebutuhan. Kebutuhan yang menyebut angka atau tenggat waktu praktis selalu melahirkan lebih dari satu kondisi uji.

Ambil KEB-03 SIMCUTI: sistem menolak pengajuan yang melebihi sisa jatah dan menampilkan pesan yang memuat jumlah sisa. Di dalam satu kalimat itu ada tiga hal yang bisa gagal secara terpisah — perilaku ketika pengajuan sama dengan sisa jatah, perilaku ketika melebihi, dan isi pesan yang muncul. Satu kasus uji tidak akan menutup ketiganya sekaligus tanpa menjadi kasus uji yang kabur.

Hubungan antarsimpul ini bukan satu lawan satu. Satu kebutuhan biasanya melahirkan beberapa kondisi uji; satu kasus uji kadang menutup dua kondisi uji sekaligus; satu kondisi uji kadang butuh beberapa kasus uji dengan data berbeda. Yang penting bukan angkanya, melainkan tidak ada simpul yang menggantung.

Empat penanda sebuah suite

Untuk menilai apakah yang kamu pegang sudah suite atau masih tumpukan, pakai empat penanda ini:

1. Cakupan yang dinyatakan. Setiap kebutuhan dalam lingkup suite punya alamat: kamu bisa menunjuk kasus uji mana yang menjaganya, atau menyatakan secara sadar bahwa ia sengaja belum dijaga.
2. Keterlacakan dua arah. Dari kebutuhan kamu bisa turun ke kasus uji, dan dari kasus uji kamu bisa naik ke kebutuhan. Arah kedua ini yang membongkar kasus uji yatim.
3. Kriteria selesai yang eksplisit. Ada pernyataan kapan suite dianggap lulus — misalnya seluruh kasus uji prioritas tinggi lulus dan tidak ada cacat terbuka berkategori pemblokir.
4. Dapat dijalankan ulang secara utuh. Suite bisa dijalankan lagi kapan saja pada versi berikutnya, dan hasil run baru bisa dibandingkan langsung dengan run sebelumnya.

Gagal di penanda mana pun berarti kamu masih memegang tumpukan. Kerangka istilah yang dipakai di kelas ini sejalan dengan silabus dasar pengujian perangkat lunak yang diterbitkan ISTQB; kalau kamu ingin membandingkan padanan istilah bahasa Inggrisnya, dokumen itu bisa diunduh bebas.

Bahan yang kita pegang

Dari 96 baris di uji-simcuti.xlsx, hanya lima baris yang ditandai modul Pengajuan Cuti Tahunan. Sembilan puluh satu baris sisanya menumpuk di layar master data dan pengaturan hak akses — layar yang paling mudah diuji. Ketimpangan itu sendiri sudah temuan pertama kita, tapi mari kita kerjakan yang lima dulu.

Inilah kelimanya, apa adanya, tanpa dirapikan:

Kita akan menilainya dalam enam langkah.

Langkah 1 — Kumpulkan kebutuhan yang berlaku

Empat kebutuhan modul ini sudah kita kenal: KEB-01 (hak 12 hari kerja bagi karyawan tetap bermasa kerja minimal 12 bulan), KEB-02 (persetujuan atasan langsung, eskalasi otomatis setelah akhir hari kerja ketiga), KEB-03 (tolak pengajuan melebihi sisa jatah, pesan memuat jumlah sisa), KEB-04 (karyawan kontrak bermasa kerja di bawah 12 bulan, menu pengajuan tidak aktif).

Langkah 2 — Turunkan kondisi uji dari tiap kebutuhan

Sebelum menyentuh kasus uji yang ada, kita bangun dulu daftar kondisi ujinya. Kalau langkah ini dilewati, kita hanya akan menilai kasus uji terhadap dirinya sendiri.

• Dari KEB-01: KU-01a karyawan tetap dengan masa kerja tepat 12 bulan boleh mengajukan; KU-01b karyawan tetap dengan masa kerja 11 bulan belum boleh.
• Dari KEB-02: KU-02a atasan menyetujui dalam tenggat; KU-02b atasan menolak; KU-02c tidak ada tanggapan sampai akhir hari kerja ketiga sehingga naik ke atasan tingkat dua.
• Dari KEB-03: KU-03a jumlah hari yang diajukan sama dengan sisa jatah, pengajuan diterima; KU-03b jumlah hari melebihi sisa jatah, pengajuan ditolak; KU-03c pesan penolakan memuat angka sisa jatah yang benar.
• Dari KEB-04: KU-04a menu pengajuan tidak aktif bagi karyawan kontrak; KU-04b akses langsung ke alamat form ditolak.

Total sepuluh kondisi uji dari empat kebutuhan. Perhatikan bahwa KEB-03 sendirian melahirkan tiga.

Langkah 3 — Daftarkan kasus uji apa adanya

Sudah kita lakukan di tabel atas. Aturannya: jangan memperbaiki apa pun di langkah ini. Kalau kamu merapikan sambil mendaftar, kamu akan kehilangan gambaran seberapa parah keadaannya.

Langkah 4 — Petakan ke matriks

CUTI-001 tidak masuk ke baris mana pun. Bukan karena ia buruk niatnya, tetapi karena ia tidak menyebutkan status kepegawaian, masa kerja, sisa jatah, maupun jumlah hari yang diajukan. Tanpa data itu, kita tidak bisa memastikan ia menutup KU-01a atau KU-03a — bisa jadi keduanya, bisa jadi tak satu pun, tergantung akun yang kebetulan dipakai penguji hari itu. Kasus uji tanpa data konkret tidak menutup kondisi uji apa pun secara meyakinkan.

CUTI-004 juga tidak masuk: ia menguji autentikasi, bukan pengajuan cuti. CUTI-005 adalah duplikat CUTI-001 dengan judul berbeda, ditulis penguji lain yang tidak tahu CUTI-001 sudah ada.

Langkah 5 — Baca matriks dari dua arah

Arah turun (kebutuhan → kasus uji). Dari sepuluh kondisi uji, hanya dua yang tertutup: KU-02a dan KU-03b. Delapan kosong. KEB-04 tidak punya satu kasus uji pun — seluruh aturan karyawan kontrak tidak pernah diperiksa. Dan meski KEB-03 punya CUTI-002, isi pesan penolakan tidak pernah dilihat karena hasil yang diharapkan cuma ditulis 'muncul error'.

Arah naik (kasus uji → kebutuhan). Tiga kasus uji tidak bisa dilacak ke kebutuhan mana pun: CUTI-001 (kabur), CUTI-004 (yatim, salah modul), CUTI-005 (duplikat). Kasus uji yatim seperti CUTI-004 selalu berarti salah satu dari dua hal: kasus ujinya memang tidak diperlukan di sini, atau ada kebutuhan yang tidak pernah ditulis. Kita periksa dokumen kebutuhan modul Autentikasi, dan ternyata aturan login akun kontrak memang ada di sana. Jadi CUTI-004 bukan sampah — ia hanya salah alamat.

Langkah 6 — Putuskan tindakan

• CUTI-001 ditulis ulang dengan data konkret: karyawan tetap, masa kerja tepat 12 bulan, sisa jatah 12 hari kerja, mengajukan 4 hari. Kini menutup KU-01a.
• CUTI-002 ditulis ulang: sisa jatah 3 hari kerja, mengajukan 5 hari; hasil yang diharapkan pengajuan ditolak dan pesan memuat angka sisa jatah 3 hari kerja. Menutup KU-03b dan KU-03c sekaligus.
• CUTI-003 dipertahankan apa adanya. Menutup KU-02a.
• CUTI-004 dipindahkan ke suite modul Autentikasi, tidak dihapus.
• CUTI-005 dihapus karena duplikat CUTI-001.
• CUTI-006 dibuat: sisa jatah 3 hari kerja, mengajukan tepat 3 hari, pengajuan diterima. Menutup KU-03a.
• CUTI-007 dibuat: pengajuan tidak ditanggapi sampai akhir hari kerja ketiga, lalu naik ke atasan tingkat dua. Menutup KU-02c.
• CUTI-008 dibuat: akun karyawan kontrak dengan masa kerja 7 bulan; menu pengajuan tidak aktif dan akses langsung ke alamat form ditolak. Menutup KU-04a dan KU-04b.

Hasilnya: suite modul Pengajuan Cuti Tahunan berisi enam kasus uji (CUTI-001, 002, 003, 006, 007, 008) yang menutup delapan dari sepuluh kondisi uji. Dua yang belum tertutup — KU-01b dan KU-02b — dicatat terbuka sebagai lubang yang diketahui dan dijadwalkan pada iterasi berikutnya.

Perhatikan apa yang berubah. Jumlah kasus uji naik dari lima menjadi enam saja, nyaris tidak berarti. Yang berubah drastis adalah kemampuan menjawab: sekarang kamu bisa berdiri di rapat rilis dan berkata dua kondisi masih terbuka, ini yang mana, dan ini konsekuensinya.

Lima salah paham berikut muncul berulang di tim mana pun yang baru merapikan pengujiannya. Semuanya masuk akal pada pandangan pertama — itu sebabnya mereka bertahan lama.

1. 'Test suite itu cuma folder berisi kasus uji'

Kenapa terasa benar. Secara fisik memang begitu: satu folder, satu berkas, satu proyek di perkakas manajemen uji. Kalau semua kasus uji modul cuti ada di satu tempat, bukankah itu sudah suite?

Koreksinya. Folder menjawab pertanyaan di mana berkasnya. Suite menjawab pertanyaan apa yang dijaminnya. Berkas SIMCUTI di unit pengantar adalah satu berkas rapi dengan 96 baris, dan ia tetap tidak bisa menjawab kebutuhan mana yang terbukti berjalan. Yang mengubahnya menjadi suite bukan pemindahan berkas, melainkan penambahan tautan ke kebutuhan dan pernyataan cakupan. Ujilah dirimu dengan pertanyaan ini: kalau seseorang menghapus satu kasus uji dari koleksimu, apakah kamu langsung tahu kebutuhan mana yang jadi telanjang? Kalau tidak, itu masih folder.

2. 'Satu kebutuhan cukup satu kasus uji'

Kenapa terasa benar. Terlihat rapi dan simetris. Matriks jadi diagonal bersih, mudah dilaporkan, dan gampang dijaga.

Koreksinya. Kebutuhan ditulis dalam bahasa manusia, dan satu kalimat manusia bisa memuat beberapa keputusan sekaligus. KEB-03 SIMCUTI adalah satu kalimat, tetapi melahirkan tiga kondisi uji: perilaku saat pengajuan sama dengan sisa jatah, perilaku saat melebihi, dan isi pesan penolakan. Menutupnya dengan satu kasus uji berarti memaksa satu pemeriksaan mengecek tiga hal, dan ketika ia gagal kamu tidak tahu mana yang rusak. Aturan praktisnya: hitung titik keputusan di dalam kebutuhan, bukan jumlah kalimatnya.

3. 'Semua kasus uji lulus berarti kebutuhan sudah terpenuhi'

Kenapa terasa benar. Laporan berwarna hijau semua memberi rasa aman yang kuat, apalagi di rapat.

Koreksinya. Hasil test run hanya berbicara tentang kasus uji yang ada di dalam suite. Ia sama sekali diam tentang kebutuhan yang tidak punya kasus uji. Di SIMCUTI sebelum perbaikan, kelima kasus uji bisa saja lulus semua, dan KEB-04 tetap tidak pernah diperiksa satu kali pun — menu pengajuan bisa saja aktif bagi karyawan kontrak selama berbulan-bulan tanpa ada yang tahu. Warna hijau menjawab apakah yang kita periksa berjalan, bukan apakah kita memeriksa hal yang benar. Pertanyaan kedua hanya bisa dijawab oleh matriks keterlacakan.

4. 'Test plan dan test suite itu sama, cuma beda nama dokumen'

Kenapa terasa benar. Di banyak tim kecil keduanya memang tinggal di satu berkas yang sama, dan kata 'rencana pengujian' dipakai untuk apa saja.

Koreksinya. Keduanya menjawab pertanyaan yang berbeda dan dibaca oleh orang yang berbeda. Test plan memuat keputusan dan alasan: apa yang sengaja tidak diuji, risiko apa yang diterima, siapa yang berhak menyatakan rilis layak. Test suite memuat pemeriksaan yang bisa dijalankan mesin atau manusia. Akibat mencampurnya nyata: ketika ada yang bertanya 'kenapa modul laporan tidak diuji sama sekali?', jawabannya harus berupa keputusan sadar yang tercatat di plan. Kalau plan tidak ada, jawaban yang tersisa hanyalah 'kelupaan', dan itu jawaban yang tidak bisa dipertanggungjawabkan.

5. 'Keterlacakan itu birokrasi audit; tim kecil tidak perlu'

Kenapa terasa benar. Kata 'keterlacakan' berbau dokumen tebal, dan tim beranggota tiga orang merasa cukup saling tahu.

Koreksinya. Keterlacakan bukan dokumen, melainkan jawaban atas pertanyaan yang muncul justru saat tim sedang buru-buru: aturan sisa jatah berubah minggu depan — kasus uji mana yang harus dijalankan ulang? Tanpa tautan ke kebutuhan, satu-satunya jawaban aman adalah menjalankan semuanya, dan itu justru beban yang lebih besar daripada memelihara tautannya. Bentuknya boleh sangat sederhana: satu kolom tambahan berisi kode kebutuhan di spreadsheet yang sudah kamu punya. Ukuran tim menentukan seberapa formal bentuknya, bukan apakah keterlacakannya ada.

Benang merahnya

Kelimanya berbagi satu akar: mengira pengujian adalah soal mengumpulkan pemeriksaan, padahal ia soal menyatakan jaminan. Kumpulan pemeriksaan bisa tumbuh tanpa batas dan tetap tidak menjamin apa pun. Jaminan lahir hanya ketika setiap pemeriksaan punya alamat, dan setiap alamat bisa ditelusuri balik.

Kenapa unit ini penting

SIMCUTI adalah kasus yang sudah dibersihkan untuk keperluan belajar: kebutuhannya empat, tertulis rapi, dan tidak saling bertentangan. Pekerjaanmu hampir pasti lebih berantakan dari itu. Unit ini mengajakmu memindahkan cara pandang yang baru kamu pelajari ke bahan aslimu sendiri, sebelum kebiasaan lama menutupnya kembali.

Kalau kamu belum bekerja di proyek perangkat lunak, pakai apa saja yang punya aturan dan pemeriksaan: prosedur pengajuan reimbursement di kantormu, alur pendaftaran siswa baru di sekolah, atau ketentuan pengembalian barang di toko daring yang sering kamu pakai. Yang dilatih di sini adalah cara berpikirnya, bukan perkakasnya.

Empat pertanyaan untuk dijawab tertulis

Jawab keempatnya dengan menulis, bukan sekadar memikirkannya. Perbedaannya besar: menulis memaksa kamu berhenti di tempat yang kabur.

Pertanyaan 1 — Di mana kebutuhanmu tinggal?
Sebutkan secara konkret di mana kebutuhan produkmu tercatat: tiket di papan tugas, dokumen di penyimpanan bersama, obrolan grup, atau hanya di kepala seseorang. Kalau jawabanmu 'di kepala seseorang', tuliskan siapa. Ini bukan pertanyaan retoris — keterlacakan mustahil dibangun ke sesuatu yang tidak punya wujud dan alamat.

Pertanyaan 2 — Berapa kondisi uji yang tersembunyi dalam satu kebutuhanmu?
Ambil satu kebutuhan produkmu, salin kalimatnya utuh, lalu lingkari setiap titik keputusan di dalamnya: setiap angka, setiap tenggat, setiap kata 'jika', 'kecuali', 'minimal', 'maksimal'. Tulis satu kondisi uji untuk tiap lingkaran, ditambah kondisi untuk nilai batasnya. Bandingkan jumlahnya dengan jumlah kasus uji yang kini kamu punya untuk kebutuhan itu. Kalau jumlah kasus ujimu lebih sedikit, kamu baru saja menemukan lubang pertamamu.

Pertanyaan 3 — Adakah kasus uji yatim di tempatmu?
Ambil sepuluh kasus uji secara acak dari koleksimu — acak sungguhan, jangan pilih yang kamu ingat bagus. Untuk masing-masing, coba naik ke kebutuhannya dalam waktu tiga puluh detik. Yang tidak sampai dalam tiga puluh detik masuk daftar yatim sementara. Lalu untuk tiap yatim, putuskan: apakah ia memeriksa perilaku yang memang tidak diperlukan, ataukah ia memeriksa perilaku nyata yang kebutuhannya tidak pernah ditulis? Ingat kasus CUTI-004 di unit contoh — kasus uji yang salah alamat tidak sama dengan kasus uji yang tidak berguna.

Pertanyaan 4 — Pertanyaan rilis mana yang belum bisa kamu jawab?
Tuliskan satu pertanyaan yang pernah diajukan atasan, klien, atau rekan setimmu tentang kesiapan rilis, yang saat itu tidak bisa kamu jawab dengan yakin. Lalu tentukan: pertanyaan itu semestinya dijawab oleh suite, oleh test run, atau oleh test plan? Ini latihan yang paling cepat menajamkan pembedaan keempat istilah tadi, karena kamu memakainya untuk mendiagnosis kekosongan yang nyata, bukan yang dikarang.

Latihan kecil sebelum lanjut

Kerjakan ini dalam waktu sekitar tiga puluh menit. Jangan menyempurnakannya; tujuannya membuat sesuatu yang bisa diperbaiki, bukan sesuatu yang selesai.

1. Pilih satu modul kecil dari produkmu — sekecil mungkin, satu layar sudah cukup.
2. Tulis kebutuhannya dalam tiga sampai lima kalimat, beri kode sendiri jika belum ada kodenya.
3. Turunkan kondisi uji dari tiap kebutuhan, termasuk jalur penolakan dan nilai batasnya.
4. Buat tabel dua kolom: kondisi uji di kiri, kasus uji yang menutupnya di kanan. Biarkan sel yang kosong tetap kosong.

Tabel dengan banyak sel kosong bukan kegagalan latihan. Itu justru hasilnya. Sel kosong adalah hal yang sebelumnya tidak kamu ketahui, dan sekarang kamu ketahui.

Rambu-rambu

Dua kesalahan yang paling sering muncul di latihan ini. Pertama, mengisi paksa sel kosong dengan menautkan kasus uji terdekat yang sebenarnya tidak memeriksa kondisi itu. Matriks yang penuh karena dipaksa lebih berbahaya daripada matriks yang jujur berlubang, karena ia membuat kamu berhenti mencari. Kedua, memperbaiki kasus uji sambil mendaftarnya. Selesaikan pendaftaran apa adanya lebih dulu; kalau kamu merapikan sambil berjalan, gambaran keseluruhan tidak akan pernah terlihat.

Simpan hasil latihanmu. Di modul berikutnya, tabel inilah yang akan kita pakai sebagai bahan mentah — jauh lebih bermanfaat belajar dengan bahan sendiri daripada terus memakai SIMCUTI.

Petunjuk pengerjaan

Kuis ini berisi empat soal pilihan ganda. Semuanya memakai kasus yang belum pernah muncul di modul ini — bukan SIMCUTI — karena yang diukur adalah apakah kamu bisa memakai cara berpikirnya pada bahan baru, bukan apakah kamu ingat pembahasan sebelumnya.

Beberapa hal yang perlu kamu tahu sebelum mulai:

• Tiap soal punya satu jawaban yang paling tepat. Beberapa pilihan lain mengandung sebagian kebenaran, jadi bacalah sampai habis sebelum memilih.
• Tidak ada batas waktu, tetapi usahakan tidak lebih dari lima menit per soal. Kalau kamu terjebak lebih lama dari itu, kemungkinan besar yang perlu kamu tinjau ulang adalah pembedaan empat istilah di unit kuliah, bukan detail soalnya.
• Kamu boleh membuka kembali unit mana pun sambil mengerjakan. Ini bukan ujian hafalan.
• Sesudah menjawab, baca pembahasannya sampai selesai — termasuk untuk soal yang kamu jawab benar. Pembahasan menjelaskan kesalahan berpikir apa yang diwakili tiap pilihan yang salah, dan bagian itu sering lebih berguna daripada kunci jawabannya sendiri.

Cara membaca soal yang menolong: sebelum melihat pilihan jawaban, tanyakan dulu pada dirimu sendiri — pertanyaan ini sebenarnya soal cakupan, soal hasil eksekusi, atau soal keputusan rilis? Menempatkan soal pada tempat yang benar biasanya sudah menyingkirkan separuh kebingungan.

Ambang lulus yang disarankan adalah tiga dari empat. Kalau kamu di bawah itu, jangan langsung mengulang kuisnya; baca ulang unit kuliah dan unit contoh dulu, lalu kembali.

Yang sudah kamu bangun di modul ini

Modul ini berangkat dari satu situasi yang mungkin terasa akrab: berkas berisi puluhan kasus uji yang rapi, ditulis oleh orang-orang yang rajin, tetapi tidak sanggup menjawab pertanyaan paling dasar di rapat rilis. Kesimpulannya satu — persoalannya bukan jumlah, melainkan tidak adanya alamat yang menghubungkan tiap kasus uji ke kebutuhan yang melahirkannya.

Empat istilah dan fungsinya. Test case adalah satu pemeriksaan yang bisa dijalankan dengan data konkret dan satu hasil yang diharapkan. Test suite adalah kumpulan berbatas yang punya pernyataan cakupan. Test run adalah satu kali menjalankan suite pada satu versi dan satu tanggal. Test plan adalah dokumen keputusan yang memuat lingkup, risiko, dan alasan. Dalam siklus rilis, plan memutuskan apa yang perlu dijamin, suite adalah alat penjaminannya, case adalah satuan terkecil alat itu, dan run adalah buktinya. Pertanyaan cakupan dijawab suite, pertanyaan hasil dijawab run, pertanyaan alasan tidak diuji dijawab plan.

Rantai keterlacakan berisi empat simpul: kebutuhan, kondisi uji, kasus uji, hasil eksekusi. Simpul kondisi uji adalah yang paling sering dilewati, dan justru di situ lubang cakupan lahir. Satu kebutuhan yang memuat angka atau tenggat hampir selalu melahirkan beberapa kondisi uji — jalur normal, jalur penolakan, dan nilai batasnya. Hubungan antarsimpul tidak satu lawan satu.

Empat penanda suite: cakupan yang dinyatakan, keterlacakan dua arah, kriteria selesai yang eksplisit, dan kemampuan dijalankan ulang secara utuh.

Dari kasus SIMCUTI, kamu melihat penerapannya pada bahan nyata. Empat kebutuhan modul Pengajuan Cuti Tahunan melahirkan sepuluh kondisi uji. Lima kasus uji warisan ternyata hanya menutup dua dari sepuluh kondisi itu. Sesudah CUTI-004 dipindahkan ke suite Autentikasi, CUTI-005 dihapus sebagai duplikat, CUTI-001 dan CUTI-002 ditulis ulang dengan data konkret, serta CUTI-006, CUTI-007, dan CUTI-008 ditambahkan, suite berisi enam kasus uji yang menutup delapan dari sepuluh kondisi. Dua sisanya, KU-01b dan KU-02b, dicatat terbuka. Jumlah kasus uji nyaris tidak bertambah; yang berubah adalah kemampuan menjawab.

Lima miskonsepsi yang perlu terus kamu waspadai: suite dikira folder; satu kebutuhan dikira cukup satu kasus uji; laporan hijau dikira bukti kebutuhan terpenuhi; test plan disamakan dengan test suite; dan keterlacakan dianggap birokrasi audit yang tidak relevan untuk tim kecil.

Daftar periksa mandiri sebelum lanjut

Centang butir-butir berikut dengan jujur. Butir yang belum tercentang menandakan bagian mana yang perlu kamu baca ulang, dan unit mana yang perlu kamu buka lagi.

1. Aku bisa menjelaskan beda test suite dan test run kepada rekan setim tanpa membuka catatan, dan bisa menyebutkan satu contoh dari pekerjaanku sendiri untuk masing-masing.
2. Diberi satu pertanyaan tentang kesiapan rilis, aku bisa menentukan apakah jawabannya semestinya ada di suite, di run, atau di test plan.
3. Diberi satu kalimat kebutuhan yang memuat angka atau tenggat waktu, aku bisa menurunkan sekurang-kurangnya tiga kondisi uji darinya, termasuk kondisi untuk nilai batasnya.
4. Aku paham kenapa kasus uji tanpa data konkret tidak dapat dianggap menutup kondisi uji mana pun, dan bisa menjelaskan alasannya dengan bahasaku sendiri.
5. Aku bisa membaca matriks keterlacakan dari dua arah, dan tahu temuan apa yang muncul dari masing-masing arah.
6. Menemukan kasus uji yatim, aku tahu bahwa langkah pertamanya adalah menelusuri kemungkinan kebutuhan yang belum tertulis, bukan langsung menghapus atau langsung menautkan paksa.
7. Aku sudah mengerjakan latihan di unit refleksi pada satu modul kecil dari pekerjaanku sendiri, dan tabel dua kolomnya sudah jadi — termasuk sel-sel yang masih kosong.
8. Aku bisa menyebutkan sekurang-kurangnya dua dari lima miskonsepsi di unit empat yang pernah aku percayai, dan tahu koreksinya.

Delapan butir. Kalau ada tiga atau lebih yang belum tercentang, tinjau ulang unit kuliah dan unit contoh sebelum melanjutkan; modul berikutnya membangun langsung di atas keduanya.

Ke mana selanjutnya

Sampai titik ini kamu sudah bisa menilai dan menata sebuah suite. Yang belum kita sentuh sama sekali adalah bagaimana merancang kasus uji yang efisien sejak awal — supaya kamu tidak menurunkan tiga puluh kondisi uji dari satu kebutuhan yang sebenarnya cukup lima. Itu pekerjaan modul berikutnya, dan bahan mentahnya adalah tabel dua kolom yang baru saja kamu buat sendiri.