Modul 1 · Kenapa Uji Dijalankan: Cacat, Kegagalan, dan Ongkos Menemukannya Terlambat

Kalimat yang selalu ditolak

Kalau kamu pernah diminta "coba tes dulu ya" sebelum sebuah aplikasi dipakai orang, kemungkinan besar kamu pernah mengalami ini: kamu menemukan sesuatu yang aneh, kamu melaporkannya, lalu laporanmu kembali dengan satu baris jawaban, tidak bisa direproduksi. Kamu yakin kamu melihatnya. Pengembang yakin di komputernya semua baik-baik saja. Tidak ada yang berbohong. Yang hilang adalah cara bicara yang sama tentang apa yang sebenarnya terjadi.

Modul ini menutup celah itu. Bukan dengan teori panjang, melainkan dengan satu kasus yang akan kita bawa dari awal sampai akhir.

Sabtu pagi di Koperasi Warga Melati

Koperasi Warga Melati memakai TOKOWARGA, aplikasi kasir sederhana untuk toko koperasi. Anggota bisa membayar tunai, atau memotong langsung dari saldo simpanan yang mereka titipkan di koperasi.

Sabtu pagi, antrean panjang. Anggota bernomor A-0142 berbelanja senilai Rp150.000. Saldo simpanannya, dilihat dari layar kasir, tepat Rp150.000. Kasir menekan tombol Bayar dengan Saldo. Layar menjawab:

Saldo simpanan tidak mencukupi.

Transaksi batal. Struk tidak terbit. Anggota A-0142 bertanya ke mana uangnya. Kasir mengulang dua kali, hasilnya sama. Antrean berhenti sekitar sepuluh menit sampai kasir menyerah dan meminta anggota membayar tunai. Sore harinya pengurus menelepon pengembang dengan kalimat yang paling sering didengar seorang penguji: "Aplikasinya error."

Kenapa kalimat itu tidak cukup

"Aplikasinya error" adalah kesimpulan, bukan informasi. Ia tidak memberi tahu siapa pun apa yang harus dikerjakan besok pagi. Coba perhatikan bahwa di dalam satu kejadian tadi sebenarnya ada tiga hal yang berbeda, dan ketiganya sering ditumpuk jadi satu kata "error":

1. Ada sesuatu yang dilihat orang, layar menolak pembayaran padahal saldo cukup.
2. Ada sesuatu yang tertanam di dalam produk dan sudah ada di sana sejak sebelum Sabtu pagi, diam saja, tidak terlihat siapa pun.
3. Ada tindakan manusia di masa lalu yang menaruh benda itu di sana, seseorang menerjemahkan aturan koperasi ke dalam kalimat kode, dan terjemahannya meleset sedikit.

Orang awam menyebut ketiganya "error". Seorang penguji memisahkannya, karena ketiganya punya alamat yang berbeda: yang pertama dilaporkan, yang kedua diperbaiki, yang ketiga dicegah agar tidak terulang di fitur berikutnya.

Yang sebenarnya dikerjakan seorang penguji

Pekerjaan eksekusi pengujian bukan "mencoba-coba aplikasi sampai rusak". Pekerjaannya lebih tenang dari itu: menjalankan langkah yang sudah ditentukan, membandingkan apa yang terjadi dengan apa yang seharusnya terjadi, lalu meninggalkan jejak yang cukup rapi sehingga orang lain, yang tidak ada di ruangan saat itu, bisa mengulang kejadian yang sama.

Jejak itu yang kita sebut bukti. Tanpa bukti, laporanmu adalah pendapat. Dengan bukti, laporanmu adalah temuan.

Dan soal ongkos

Ada satu hal lagi yang membuat pekerjaan ini bernilai, dan itu jarang dijelaskan kepada pemula. Penolakan pembayaran tadi, andai ditemukan saat fitur itu masih ditulis, hanya menyentuh satu baris kode dan selesai dalam hitungan menit. Karena baru ketahuan Sabtu pagi di depan antrean, yang tersentuh jauh lebih banyak: waktu kasir, kepercayaan seorang anggota, waktu pengurus, dan pekerjaan menelusuri apakah ada anggota lain yang mengalami hal serupa tanpa melapor. Kodenya tetap satu baris. Ongkosnya tidak.

Yang akan kita kerjakan

Delapan unit dalam modul ini bergerak dari kasus tadi:

• Unit 2 membedah rantai dari tindakan manusia sampai perilaku yang teramati, lalu memetakan tujuh titik penyaring dalam alur kerja pengembangan dan empat penerima keluaran eksekusi uji.
• Unit 3 mengerjakan kasus uji UJI-BAYAR-07 langkah demi langkah pada TOKOWARGA versi 2.4.1, mencatat buktinya, dan menyusun laporan cacat TW-1188.
• Unit 4 meluruskan enam salah paham yang paling sering menempel pada pemula.
• Unit 5 memberimu satu bacaan berupa notulen rapat evaluasi insiden lain di koperasi yang sama, untuk kamu analisis sendiri.
• Unit 6 mengajakmu merefleksikan pengalamanmu sendiri, Unit 7 menguji keputusanmu lewat empat kasus baru, dan Unit 8 menutup dengan daftar periksa mandiri.

Satu pesan sebelum lanjut: kamu tidak sedang belajar menghakimi pekerjaan orang lain. Kamu sedang belajar membuat sesuatu yang diam menjadi terlihat, cukup awal, sebelum ia berdiri di depan antrean hari Sabtu.

Gagasan besar unit ini

Sebuah cacat bisa berada di dalam aplikasi selama berbulan-bulan tanpa ada yang tahu. Ia tidak berbunyi, tidak menyala, tidak mengirim notifikasi. Ia baru bersuara kalau ada orang yang kebetulan menjalankan aplikasi dengan kombinasi data dan langkah yang tepat. Eksekusi pengujian adalah pekerjaan membuat cacat bersuara lebih awal: di ruangan yang aman, bukan di depan antrean.

Seluruh unit ini membedah gagasan itu sampai tuntas: rantainya, tempatnya dalam alur kerja, dan kepada siapa hasilnya diserahkan.

1. Rantai: kesalahan → cacat → kegagalan

Tiga kata ini terdengar mirip dalam percakapan sehari-hari. Dalam pekerjaan pengujian, ketiganya menunjuk pada tiga benda yang berbeda dan tidak bisa saling menggantikan.

Kesalahan adalah tindakan manusia yang keliru. Ia terjadi di kepala dan di jari seseorang, pada satu momen di masa lalu. Pada kasus TOKOWARGA, aturan koperasi berbunyi "saldo simpanan harus cukup untuk menutup total belanja". Saat menulis fitur pembayaran, kalimat itu diterjemahkan menjadi "saldo harus lebih besar dari total belanja". Terjemahan yang meleset satu kata itulah kesalahannya. Kesalahan bukan kejahatan dan bukan kebodohan; ia hasil wajar dari bahasa manusia yang selalu sedikit longgar.

Cacat adalah wujud kekeliruan itu yang tertinggal di dalam produk kerja. Ia adalah benda, bukan peristiwa. Pada kasus kita, cacatnya adalah kondisi pemeriksaan saldo > total di dalam fungsi yang menentukan boleh atau tidaknya pembayaran dengan saldo. Kondisi itu tersimpan di berkas kode, ikut terbawa ke setiap pemasangan aplikasi, dan tetap ada baik ada orang yang memakainya maupun tidak. Perlu dicatat: cacat tidak hanya hidup di kode. Ia bisa juga bersarang di dokumen kebutuhan, di rancangan layar, atau di data acuan.

Kegagalan adalah perilaku menyimpang yang teramati ketika aplikasi dijalankan. Ia peristiwa, terikat waktu dan saksi. Pada kasus kita, kegagalannya adalah: aplikasi menampilkan "Saldo simpanan tidak mencukupi" dan membatalkan transaksi, padahal saldo sama dengan total belanja. Perhatikan bahwa antrean yang berhenti dan kekecewaan anggota A-0142 bukan kegagalan, itu dampak dari kegagalan. Membedakan keduanya penting karena laporan yang mencampurnya sulit ditindaklanjuti.

Arah rantai ini satu arah dan tidak simetris, dan di sinilah letak inti pekerjaan kita:

• Setiap kegagalan pasti berasal dari cacat.
• Tidak setiap cacat pernah menghasilkan kegagalan yang teramati.

Cacat saldo > total sudah ada di TOKOWARGA sejak fitur itu selesai ditulis. Selama berminggu-minggu tidak ada anggota yang belanjanya persis sama dengan saldonya, jadi tidak ada yang melihat apa pun. Cacatnya diam. Ia tidak menjadi lebih ringan karena diam.

2. Kasus uji dan bukti

Kalau cacat hanya bersuara pada kombinasi tertentu, maka pekerjaan penguji adalah menyiapkan kombinasi itu dengan sengaja, bukan menunggu keberuntungan.

Kasus uji adalah deskripsi tertulis berisi kondisi awal, data yang dipakai, langkah yang dijalankan, dan hasil yang diharapkan. Bagian "hasil yang diharapkan" ditulis sebelum eksekusi. Kalau kamu menjalankan dulu baru memutuskan apa yang seharusnya terjadi, kamu tidak sedang menguji, kamu sedang membenarkan apa pun yang muncul di layar.

Bukti adalah rekaman yang membuat hasil eksekusi dapat diperiksa ulang orang lain. Bukti yang berguna menjawab pertanyaan pengembang tanpa perlu ada percakapan susulan: versi berapa, kapan, di lingkungan apa, dengan data apa, langkah apa persisnya, apa yang diharapkan, apa yang muncul. Inilah yang membedakan temuan dari pendapat, dan inilah yang membuat balasan "tidak bisa direproduksi" jarang muncul.

3. Tujuh titik penyaring

Sebuah cacat berpeluang tertangkap di beberapa titik sepanjang alur kerja pengembangan. Ada tujuh titik yang perlu kamu kenali:

1. Tinjauan kebutuhan dan kriteria penerimaan, membaca ulang rumusan aturan sebelum ada kode. Di sini pertanyaan "apa yang terjadi kalau saldo persis sama dengan total?" seharusnya diajukan.
2. Tinjauan rancangan dan kode, membaca rancangan atau kode buatan rekan sebelum digabungkan.
3. Uji unit, menguji satu fungsi secara terpisah, biasanya oleh pemrogramnya sendiri.
4. Uji integrasi, menguji apakah dua modul atau lebih benar-benar cocok saat bertukar data.
5. Uji sistem, menjalankan alur ujung ke ujung pada aplikasi yang sudah utuh.
6. Uji penerimaan pengguna, pihak yang akan memakai mencoba dengan skenario kerjanya sendiri.
7. Operasi, aplikasi sudah dipakai orang sungguhan; cacat muncul sebagai insiden.

Eksekusi pengujian yang kita pelajari di kelas ini terutama menempati titik 4 sampai 6, tetapi seorang penguji yang baik ikut menyumbang di titik 1 dan 2 dengan cara mengajukan pertanyaan yang tidak nyaman lebih awal.

Semakin ke kanan sebuah cacat baru tertangkap, semakin mahal ia. Bukan karena kodenya jadi lebih panjang, melainkan karena semakin banyak pekerjaan yang sudah menumpuk di atasnya: modul lain yang terlanjur ikut memakai perilaku keliru itu, data yang sudah tersimpan dan perlu dikoreksi, panduan yang sudah dicetak, kasir yang sudah dilatih, dan pengguna yang sudah membentuk kesan. Di titik 7, ongkos yang paling besar biasanya bukan ongkos teknis sama sekali.

4. Empat penerima keluaran eksekusi uji

Hasil kerjamu bukan berhenti di dirimu sendiri. Ada empat pihak yang menerimanya, dan masing-masing membutuhkan hal yang berbeda:

1. Pengembang yang akan memperbaiki, butuh langkah reproduksi, data persis, versi, dan bukti. Ia tidak butuh dugaanmu tentang letak cacatnya.
2. Pemimpin tim atau pengelola rilis, butuh status kasus uji dan seberapa berat dampaknya, untuk menyusun urutan pengerjaan.
3. Pemilik produk, dalam kasus kita pengurus koperasi, butuh dampak terhadap anggota dan seberapa sering kegagalan itu muncul, untuk memutuskan rilis ditunda atau tidak.
4. Petugas lapangan, dalam kasus kita kasir dan pengurus toko, butuh cara menghindari sementara selama perbaikan belum turun.

5. Batas peran yang perlu kamu jaga

Penguji menyediakan informasi; penguji tidak memutuskan rilis dan tidak memperbaiki cacat. Batas ini bukan soal kerendahan hati, melainkan soal pembagian kerja: begitu kamu ikut memperbaiki kode yang kamu uji, kamu kehilangan sudut pandang orang luar yang justru menjadi nilai utamamu.

Situasi

Kamu penguji di tim TOKOWARGA. Hari ini, Jumat 4 September 2026, kamu mendapat giliran menjalankan sekumpulan kasus uji untuk fitur pembayaran dengan saldo simpanan. Kita kerjakan satu di antaranya, pelan-pelan, sampai jadi laporan.

Langkah 1: Catat lingkungan sebelum menyentuh apa pun

Sebelum menekan tombol, catat dulu di mana kamu berdiri. Ini bagian yang paling sering dilewati pemula dan paling sering diminta pengembang.

Langkah 2: Siapkan data uji

Kasus uji ini menyasar satu titik yang sering luput: nilai yang berada tepat di batas antara dua keputusan. Aturan koperasi berbunyi "saldo simpanan harus cukup untuk menutup total belanja". Kata "cukup" punya tiga kemungkinan hubungan angka: saldo kurang, saldo lebih, dan saldo persis sama. Yang ketiga inilah batasnya, dan justru yang paling jarang dicoba orang.

Data yang kamu siapkan:

• Anggota uji A-0142, saldo simpanan Rp150.000.
• Keranjang belanja dengan total Rp150.000.

Langkah 3: Baca kasus ujinya, jangan mengarang di tempat

UJI-BAYAR-07: Bayar penuh dengan saldo simpanan tepat sama dengan total belanja

• Prakondisi: kasir sudah masuk aplikasi; anggota A-0142 punya saldo Rp150.000; tidak ada tagihan tertunggak.
• Langkah: (1) pindai barang hingga total Rp150.000; (2) pilih anggota A-0142; (3) tekan Bayar dengan Saldo; (4) konfirmasi.
• Hasil yang diharapkan: transaksi tersimpan, struk terbit, saldo A-0142 menjadi Rp0.

Perhatikan bahwa hasil yang diharapkan sudah tertulis di sini, sebelum kamu menjalankan apa pun. Itu yang membuatmu punya pembanding.

Langkah 4: Jalankan, jangan menolong aplikasi

Jalankan persis empat langkah di atas. Godaan terbesar pemula adalah "menolong" aplikasi: menekan tombol lain, menyegarkan halaman, mengulang dengan cara berbeda, lalu melaporkan hasil dari cara yang berbeda itu. Jalankan apa yang tertulis, catat apa yang muncul.

Langkah 5: Catat hasil aktual dan kumpulkan bukti

Yang muncul pukul 09.12 WIB:

Saldo simpanan tidak mencukupi.

Transaksi tidak tersimpan, struk tidak terbit, saldo A-0142 tetap Rp150.000.

Bukti yang kamu kumpulkan:

• Tangkapan layar UJI-BAYAR-07_2026-09-04_0912.png yang memperlihatkan total belanja, saldo, dan pesan galat dalam satu layar.
• Potongan catatan sistem bayar-2026-09-04.log pada rentang waktu yang sama.

Satu petunjuk praktis: tangkapan layar yang memuat angka pemicu dan pesan galat sekaligus jauh lebih berguna daripada dua tangkapan layar terpisah.

Langkah 6: Tetapkan status

Status kasus uji hanya punya tiga kemungkinan, dan semuanya soal fakta, bukan penilaian tentang penyebab:

• LULUS, hasil aktual sama dengan hasil yang diharapkan.
• GAGAL, hasil aktual berbeda dari hasil yang diharapkan.
• TERHALANG, kasus uji tidak bisa dijalankan sampai selesai, misalnya karena data belum siap atau ada cacat lain yang menghalangi.

UJI-BAYAR-07 berstatus GAGAL.

Langkah 7: Persempit dengan satu uji tambahan

Sebelum melapor, satu langkah kecil sangat menaikkan mutu laporanmu: ubah satu hal saja, lalu jalankan ulang. Kamu naikkan saldo A-0142 menjadi Rp150.001 dan mengulang langkah yang sama pada pukul 09.21 WIB. Hasilnya: transaksi berhasil, struk terbit, saldo menjadi Rp1.

Sekarang laporanmu bisa berkata: kegagalan muncul saat saldo sama dengan total, dan hilang saat saldo lebih besar satu rupiah. Itu informasi yang menghemat berjam-jam penelusuran bagi pengembang. Kamu tidak menebak letak cacatnya; kamu hanya melaporkan pola yang kamu amati.

Langkah 8: Pisahkan tiga istilah pada kasus ini

• Kesalahan: aturan "saldo harus cukup untuk menutup total" diterjemahkan menjadi "saldo harus lebih besar dari total" saat fitur pembayaran dirancang dan ditulis.
• Cacat: kondisi pemeriksaan saldo > total yang tertanam di fungsi penentu kelayakan bayar pada TOKOWARGA 2.4.1.
• Kegagalan: pada 4 September 2026 pukul 09.12 WIB, aplikasi menampilkan "Saldo simpanan tidak mencukupi" dan membatalkan transaksi meskipun saldo Rp150.000 sama dengan total belanja Rp150.000.

Langkah 9: Tulis laporan cacat TW-1188

TW-1188: Pembayaran dengan saldo ditolak ketika saldo sama persis dengan total belanja

• Versi: TOKOWARGA 2.4.1 · Lingkungan: tablet kasir, basis data uji
• Kasus uji: UJI-BAYAR-07 · Status: GAGAL
• Langkah: pindai barang hingga total Rp150.000 → pilih anggota A-0142 (saldo Rp150.000) → tekan Bayar dengan Saldo → konfirmasi.
• Hasil yang diharapkan: transaksi tersimpan, struk terbit, saldo menjadi Rp0.
• Hasil aktual: pesan "Saldo simpanan tidak mencukupi", transaksi batal, saldo tetap Rp150.000.
• Catatan penyempitan: dengan saldo Rp150.001 pada langkah yang sama, transaksi berhasil.
• Dampak: anggota dengan saldo pas tidak dapat membayar; kasir harus meminta pembayaran tunai di depan antrean.
• Bukti: UJI-BAYAR-07_2026-09-04_0912.png, bayar-2026-09-04.log.

Tidak ada satu pun kalimat di laporan itu yang menyebut nama orang atau menuding siapa yang salah menulis kode. Itu bukan kesopanan belaka, nama pemrogram tidak membantu siapa pun mengulang kejadian.

Langkah 10: Tentukan titik penyaring yang seharusnya menangkapnya

Dari tujuh titik penyaring di Unit 2, cacat ini paling awal bisa tertangkap di titik 1, tinjauan kebutuhan dan kriteria penerimaan: kriteria penerimaan fitur ini hanya menyebut "saldo cukup" dan "saldo kurang", tanpa pernah menyebut apa yang terjadi ketika keduanya sama. Kalau pertanyaan itu diajukan saat dokumen dibaca, cacatnya tidak pernah lahir.

Penyaring berikutnya adalah titik 3, uji unit: fungsi penentu kelayakan bayar seharusnya diuji dengan nilai tepat di batas, bukan hanya dengan angka yang jelas kurang dan jelas lebih.

Karena keduanya terlewat, cacat ini baru tertangkap di uji sistem. Masih jauh lebih baik daripada Sabtu pagi di depan antrean, tetapi sudah lebih mahal daripada seharusnya.

Berikut enam salah paham yang paling sering muncul di bulan-bulan pertama seseorang bekerja sebagai penguji. Masing-masing terdengar masuk akal, dan justru itu yang membuatnya bertahan lama.

1. "Tidak ada kegagalan berarti tidak ada cacat"

Salahnya di mana. Ini membalik arah rantai yang sudah kita bahas. Kegagalan memang selalu berasal dari cacat, tetapi cacat sama sekali tidak wajib menghasilkan kegagalan yang teramati.

Koreksi. Cacat saldo > total di TOKOWARGA sudah ada sejak fitur pembayaran selesai ditulis. Selama berminggu-minggu tidak ada anggota yang belanjanya persis sama dengan saldonya, jadi tidak ada yang melihat apa pun. Diamnya cacat itu bukan bukti kesehatan aplikasi; ia hanya bukti bahwa kombinasi pemicunya belum kebetulan terjadi. Kalimat yang benar untuk diucapkan adalah "kami belum menemukan kegagalan pada skenario yang kami jalankan", bukan "tidak ada cacat".

2. "Cacat itu kesalahan pemrogram, jadi tugas penguji mencari siapa yang salah"

Salahnya di mana. Cacat memang berasal dari kesalahan manusia, tetapi manusianya tidak selalu pemrogram, dan identitasnya tidak menambah nilai apa pun pada laporan.

Koreksi. Pada kasus kita, kesalahannya terjadi jauh sebelum pengodean: kriteria penerimaan tidak pernah menyebut apa yang terjadi ketika saldo sama dengan total. Pemrogram menuliskan tafsir yang wajar dari kalimat yang memang longgar. Lagi pula, coba periksa isi laporan TW-1188 di Unit 3, tidak ada satu pun kalimat yang lebih mudah diperbaiki hanya karena kita tahu siapa yang mengetiknya. Tim yang sibuk mencari orang akan cepat berhenti melaporkan temuan, dan saat itu terjadi, kamu kehilangan sumber informasi terbaikmu.

3. "Kalau semua kasus uji lolos, perangkat lunaknya sudah benar"

Salahnya di mana. Kasus uji hanya mencoba sebagian kecil dari kombinasi yang mungkin terjadi. Lolosnya semua kasus uji berarti aplikasi berperilaku benar pada kombinasi yang kamu coba, bukan pada seluruh kombinasi yang ada.

Koreksi. Sebelum UJI-BAYAR-07 ditulis, kemungkinan besar fitur pembayaran sudah pernah diuji dengan saldo Rp500.000 untuk belanja Rp150.000 dan lolos. Uji itu benar, hasilnya jujur, dan tetap saja tidak menyentuh cacatnya. Karena itu laporan pengujian menyampaikan apa yang sudah dijalankan dan apa yang belum, bukan menyatakan aplikasi bebas cacat.

4. "Penguji yang menemukan cacat sebaiknya sekalian memperbaikinya"

Salahnya di mana. Terdengar efisien, tetapi menghapus justru nilai utama seorang penguji: sudut pandang orang luar yang belum tahu bagaimana kode itu "seharusnya" bekerja.

Koreksi. Begitu kamu ikut menyunting kode yang kamu uji, kamu mulai menguji berdasarkan asumsi yang sama dengan asumsi yang melahirkan cacatnya. Ada juga alasan praktis: perbaikan yang dikerjakan tanpa memahami bagian lain sistem sering memindahkan masalah, bukan menyelesaikannya. Batasnya jelas, kamu boleh dan sebaiknya menyempitkan temuan, seperti uji tambahan dengan saldo Rp150.001 di Unit 3; kamu tidak menyunting fungsi yang bermasalah.

5. "Laporan cukup berbunyi 'aplikasi error saat bayar'"

Salahnya di mana. Kalimat itu menyampaikan perasaanmu, bukan kejadiannya. Pengembang yang membacanya tetap harus menebak versi, data, dan langkah, dan tebakan yang gagal berujung pada balasan "tidak bisa direproduksi".

Koreksi. Ukurannya sederhana dan bisa kamu periksa sendiri: bisakah orang yang tidak hadir saat kejadian mengulang kegagalan itu hanya dengan membaca laporanmu? Kalau ya, laporanmu cukup. Kalau tidak, ada butir yang hilang, biasanya data pemicu atau versi. Panjang laporan bukan ukurannya; keterulangan yang jadi ukurannya.

6. "Cacat yang lolos ke pengguna hanya menambah ongkos perbaikan kode"

Salahnya di mana. Ini menghitung ongkos hanya dari sisi tim pengembang, dan biasanya justru sisi itu yang paling kecil.

Koreksi. Perbaikan kondisi saldo > total menjadi saldo >= total adalah pekerjaan singkat, sama singkatnya baik dikerjakan bulan lalu maupun hari ini. Yang berbeda adalah semua hal di sekitarnya: waktu kasir yang terpakai, antrean yang berhenti, penelusuran untuk mencari anggota lain yang mungkin mengalami hal serupa tanpa melapor, penjelasan pengurus ke anggota, dan kesan yang terbentuk bahwa "saldo di koperasi tidak bisa dipercaya". Kesan terakhir itu yang paling lama dipulihkan dan paling tidak bisa dikerjakan oleh siapa pun di tim teknis.

Benang merah keenamnya. Lima salah paham pertama membuat seseorang melaporkan lebih sedikit dari yang seharusnya; yang keenam membuat orang meremehkan apa yang sudah dilaporkan. Kalau kamu hanya sempat mengingat satu kalimat dari unit ini, ingat yang ini: yang kamu laporkan adalah apa yang kamu amati dan cara mengulanginya, bukan siapa penyebabnya, bukan pula seberapa berat menurut perasaanmu.

Cara memakai bacaan ini

Sampai sini kamu sudah melihat satu kasus dibedah sampai tuntas oleh orang lain, yaitu insiden pembayaran di Unit 3. Bacaan berikut adalah insiden berbeda di koperasi yang sama, terjadi lebih dulu dan pada versi aplikasi yang lebih lama. Kali ini tidak ada yang membedahkannya untukmu. Baca sekali untuk memahami ceritanya, lalu baca kedua kali sambil menjawab empat pertanyaan pemandu di bawah. Sediakan sekitar lima belas menit.

Bacaan wajib

NOTULEN RAPAT EVALUASI: KOPERASI WARGA MELATI

Hari/tanggal: Kamis, 13 Agustus 2026 · Ruang: kantor koperasi · Hadir: pengurus toko, dua kasir, satu pengembang TOKOWARGA

1. Latar kejadian. Pada penghitungan stok rutin Rabu, 12 Agustus 2026, ditemukan selisih pada barang minyak goreng kemasan satu liter. Jumlah menurut TOKOWARGA versi 2.3.0 adalah 40 botol. Jumlah hasil hitungan fisik di rak dan gudang adalah 34 botol. Selisih 6 botol.

2. Penelusuran awal. Pengurus toko semula menduga ada pengambilan barang tanpa pencatatan. Seluruh kasir ditanyai dan tidak ada yang mengaku. Suasana rapat sempat tidak nyaman dan seorang kasir menyatakan tersinggung.

3. Temuan dari catatan transaksi. Pengembang membuka catatan transaksi tanggal 12 Agustus dan menemukan 6 transaksi berstatus dibatalkan. Keenamnya dibatalkan oleh kasir setelah struk tercetak, karena pembeli berubah pikiran di depan meja kasir. Keenam transaksi itu masing-masing memuat satu botol minyak goreng kemasan satu liter.

4. Percobaan ulang di depan rapat. Pengembang menjalankan satu transaksi berisi satu botol minyak goreng, mencetak struk, lalu membatalkannya. Layar stok sebelum transaksi menunjukkan 34 botol. Setelah pembatalan, layar stok tetap menunjukkan 33 botol. Baris penjualan hilang dari laporan penjualan harian, tetapi jumlah stok tidak kembali.

5. Penjelasan pengembang. Fitur pembatalan transaksi ditambahkan pada versi 2.3.0 atas permintaan pengurus. Saat menulisnya, pengembang mengira pengembalian jumlah stok sudah ditangani oleh modul stok setiap kali ada perubahan pada laporan penjualan. Asumsi itu tidak pernah dituliskan di mana pun dan tidak pernah ditanyakan kepada siapa pun. Modul stok memang mendengarkan peristiwa penjualan, tetapi tidak mendengarkan peristiwa pembatalan.

6. Catatan pengujian sebelum rilis 2.3.0. Fitur pembatalan pernah diuji dan dinyatakan lolos. Kasus uji yang dijalankan memeriksa bahwa setelah pembatalan, baris transaksi hilang dari laporan penjualan harian dan struk pembatalan tercetak. Tidak ada kasus uji yang memeriksa jumlah stok setelah pembatalan.

7. Keputusan rapat. (a) Pengurus toko mencabut dugaan terhadap kasir dan menyampaikan permintaan maaf di rapat. (b) Stok 6 botol dikoreksi manual dengan berita acara. (c) Pengembang memperbaiki fitur pembatalan pada versi berikutnya. (d) Untuk sementara, setiap pembatalan dicatat di buku dan stoknya dikoreksi manual di akhir hari.

Empat pertanyaan pemandu

Jawab singkat, satu sampai tiga kalimat masing-masing. Simpan jawabanmu; kamu akan memakainya di Unit 6.

1. Tuliskan tiga kalimat terpisah untuk insiden ini: satu kalimat kesalahan, satu kalimat cacat, satu kalimat kegagalan. Ingat bahwa selisih 6 botol dan tuduhan terhadap kasir adalah dampak, bukan kegagalan.
2. Butir 6 mengatakan fitur pembatalan pernah diuji dan lolos. Salah paham mana dari Unit 4 yang paling pas menjelaskan kenapa "lolos" di sini tidak berarti "benar"?
3. Dari tujuh titik penyaring di Unit 2, di titik mana cacat ini paling tepat tertangkap, dan kenapa uji unit atas fungsi pembatalan saja kemungkinan besar tidak akan menemukannya?
4. Butir 2 memperlihatkan ongkos yang tidak berupa uang. Sebutkan dua ongkos semacam itu dari notulen ini, dan jelaskan kenapa keduanya tidak muncul dalam perkiraan waktu perbaikan kode.

Catatan tentang kunci jawaban

Jawaban untuk empat pertanyaan di atas tidak disediakan di modul ini, dan itu disengaja. Bandingkan jawabanmu dengan pembahasan pada Unit 3, bukan untuk mencari kalimat yang sama, melainkan untuk memeriksa apakah kamu memisahkan tiga istilah dengan cara yang sama.

Kalau kamu ingin menelusuri lebih jauh

Istilah yang kita pakai di modul ini, kesalahan, cacat, kegagalan, kasus uji, serta teknik pengujian nilai batas yang kita praktikkan pada UJI-BAYAR-07, punya rumusan baku yang dipelihara secara terbuka dalam glosarium daring ISTQB. Membacanya berguna kalau kamu bekerja dengan tim yang memakai istilah bahasa Inggris. Bacalah sebagai pembanding, bukan sebagai hafalan: yang dinilai di kelas ini adalah kemampuanmu memisahkan ketiga hal itu pada kasus nyata, bukan kemampuanmu mengulang definisi.

Kenapa unit ini ada

Kosakata baru hanya menempel kalau ditempelkan pada pengalamanmu sendiri. Kamu hampir pasti pernah berada di salah satu sisi kasus TOKOWARGA, sebagai orang yang aplikasinya bermasalah, sebagai orang yang laporannya tidak ditanggapi, atau sebagai orang yang membuat sesuatu lalu kaget melihat cara orang lain memakainya. Unit ini mengajakmu menaruh pengalaman itu ke dalam kerangka yang baru saja kamu pelajari. Sediakan sekitar sepuluh menit dan tulis jawabanmu, bukan sekadar memikirkannya.

Bagian A: Empat pertanyaan reflektif

1. Kegagalan yang kamu alami sendiri. Ingat satu kali kamu memakai aplikasi apa pun, dompet digital, aplikasi pesan antar, sistem presensi kantor, dan ia berperilaku tidak seperti yang kamu harapkan. Tuliskan kejadiannya dalam bentuk yang sudah kita pakai: apa yang kamu harapkan terjadi, dan apa yang benar-benar muncul. Lalu perhatikan: seberapa banyak dari tulisanmu itu berupa fakta yang bisa diulang orang lain, dan seberapa banyak berupa kesimpulan atau perasaan?

2. Data yang tidak pernah kamu coba. Pada kasus TOKOWARGA, cacatnya tersembunyi di satu titik yang jarang disentuh: saldo yang persis sama dengan total. Pikirkan satu formulir atau fitur yang sering kamu pakai. Nilai apa yang hampir tidak pernah dicoba siapa pun di sana, nol, angka paling besar yang diizinkan, tanggal hari ini, nama dengan tanda petik, kolom yang dibiarkan kosong? Tulis dua di antaranya dan tebak apa yang mungkin terjadi.

3. Laporan yang pernah gagal sampai. Ingat satu kali kamu melaporkan masalah kepada orang lain, ke tim teknologi informasi kantor, ke layanan pelanggan, atau ke temanmu sendiri, dan laporanmu tidak ditindaklanjuti. Dengan ukuran dari Unit 4 (bisakah orang yang tidak hadir mengulang kejadiannya hanya dengan membaca laporanmu?), butir mana yang sebenarnya hilang dari laporanmu waktu itu?

4. Ongkos yang tidak terlihat. Kembali ke jawabanmu untuk pertanyaan pemandu nomor 4 pada bacaan Unit 5. Sekarang terapkan pertanyaan yang sama pada organisasi tempatmu bekerja atau belajar: kalau sebuah cacat lolos ke pengguna di sana, siapa saja yang waktunya ikut terpakai selain orang yang memperbaiki kodenya?

Bagian B: Tugas menulis pendek

Tulis satu paragraf sepanjang kurang lebih 200 kata dengan judul: "Satu cacat yang seharusnya tertangkap lebih awal".

Gunakan kasus dari pengalamanmu sendiri, atau kalau tidak ada, gunakan insiden stok minyak goreng dari bacaan Unit 5. Paragrafmu harus memuat empat hal:

1. Kegagalan yang teramati, ditulis sebagai peristiwa dengan waktu dan perilaku yang terlihat.
2. Cacat yang kamu duga tertanam di baliknya, ditulis sebagai benda yang ada di dalam produk.
3. Titik penyaring, dari tujuh titik di Unit 2, yang menurutmu paling tepat menangkapnya, disertai alasan.
4. Satu ongkos yang bukan berupa waktu pemrogram.

Bagian C: Periksa tulisanmu sendiri

Sebelum menutup unit ini, baca ulang paragrafmu dengan tiga pertanyaan berikut:

• Apakah kalimat "kegagalan"-mu bisa dibaca orang yang tidak hadir, lalu ia bisa membayangkan layarnya? Kalau isinya masih "sistemnya kacau", ganti dengan apa yang benar-benar terlihat.
• Apakah kalimat "cacat"-mu menyebut sesuatu yang ada di dalam produk, kondisi, aturan, rumusan kebutuhan, dan bukan menyebut orang atau menyebut akibat di dunia nyata?
• Apakah alasan pemilihan titik penyaringmu berbicara tentang sifat cacatnya? Cacat pada satu fungsi tunggal, cacat pada pertukaran data antarmodul, dan cacat pada rumusan kebutuhan tidak tertangkap di titik yang sama.

Kalau ketiganya sudah kamu jawab "ya", kamu siap ke kuis.

Petunjuk pengerjaan

Kuis ini berisi empat soal pilihan ganda. Semuanya memakai aplikasi dan kasus yang belum pernah muncul di unit mana pun: layanan pemesanan tiket bus, aplikasi angsuran koperasi simpan pinjam, aplikasi rapor sekolah, dan aplikasi kantin sekolah. Kamu tidak akan menemukan jawabannya dengan mencari kalimat yang mirip di unit sebelumnya, karena kalimat itu memang tidak ada di sana. Yang dipindahkan dari materi ke soal bukan jawabannya, melainkan cara berpikirnya.

Waktu. Sediakan sekitar dua belas menit. Rata-rata tiga menit per soal sudah cukup longgar. Kalau satu soal menahanmu lebih dari empat menit, tandai dan lanjut; kembali lagi di akhir.

Cara membaca soal. Setiap soal dimulai dengan cerita pendek berisi fakta yang lengkap. Baca ceritanya sampai habis sebelum melihat pilihan jawaban. Kebiasaan melompat ke pilihan lebih dulu membuatmu mencocokkan kata, dan itu persis kebiasaan yang ingin dilatih pergi oleh kelas ini.

Tentang pilihan jawaban. Tiga pilihan yang keliru pada setiap soal bukan pilihan asal-asalan. Masing-masing menggambarkan cara berpikir yang benar-benar sering muncul di tim pengujian: membalik urutan rantai, mencampur dampak dengan perilaku sistem, menyerahkan penemuan cacat teknis kepada pengguna akhir, mencampur urgensi dengan keterulangan, dan melangkahi batas peran penguji. Karena itu, saat kamu ragu antara dua pilihan, jangan mencari mana yang terdengar paling lengkap atau paling sopan. Tanyakan hal yang lebih tajam: fakta mana di dalam cerita yang membuat satu pilihan cocok dan pilihan lain tidak? Kalau kamu tidak bisa menunjuk faktanya, kamu sedang menebak.

Yang diuji. Soal-soal ini menguji keputusan, bukan ingatan. Tidak ada satu pun yang meminta kamu mengulang definisi. Yang diminta adalah: memasangkan istilah pada fakta yang tepat, memilih titik penyaring yang sesuai dengan sifat sebuah cacat, menilai kecukupan sebuah laporan, dan menimbang apa yang pantas disampaikan seorang penguji ketika ada tekanan jadwal rilis.

Sebelum mulai, pastikan kamu bisa menjawab tiga hal ini tanpa membuka catatan. Pertama, apa beda benda dan peristiwa dalam rantai kesalahan-cacat-kegagalan. Kedua, apa yang membedakan sebuah cacat yang hidup di dalam satu fungsi dari cacat yang hidup di antara dua modul. Ketiga, informasi apa yang membuat sebuah laporan bisa diulang oleh orang yang tidak hadir saat kejadian. Kalau salah satu dari ketiganya masih kabur, kembali ke Unit 2 dan Unit 3 sebentar; mengerjakan kuis dengan dasar yang goyah hanya akan memberimu skor, bukan kemampuan.

Setelah selesai. Baca pembahasan setiap soal, termasuk soal yang kamu jawab benar. Pembahasan tidak hanya menjelaskan kenapa satu pilihan benar, tetapi juga menyebut kesalahan berpikir apa yang diwakili oleh setiap pilihan yang keliru. Bagian terakhir itu yang paling berguna: kalau kamu mengenali satu di antaranya sebagai kebiasaanmu sendiri, catat di catatan refleksimu dari Unit 6.

Ambang. Kamu dianggap siap melanjutkan ke modul berikutnya kalau menjawab benar minimal tiga dari empat soal dan bisa menjelaskan alasan jawabanmu dengan kalimatmu sendiri. Syarat kedua tidak bisa diperiksa oleh sistem mana pun; hanya kamu yang bisa jujur soal itu.

Yang sudah kamu bangun di modul ini

Rantai kesalahan, cacat, kegagalan. Kesalahan adalah tindakan manusia yang keliru. Cacat adalah wujud kekeliruan itu yang tertinggal di dalam produk, di kode, di rancangan, atau di rumusan kebutuhan. Kegagalan adalah perilaku menyimpang yang teramati saat aplikasi dijalankan. Ketiganya bukan sinonim: yang satu tindakan, yang kedua benda, yang ketiga peristiwa. Pada kasus TOKOWARGA, ketiganya berbunyi seperti ini, aturan "saldo harus cukup" diterjemahkan menjadi "saldo harus lebih besar dari total"; kondisi saldo > total tertanam di fungsi penentu kelayakan bayar; dan pada 4 September 2026 aplikasi menolak pembayaran anggota A-0142 padahal saldonya Rp150.000 sama dengan total belanjanya.

Rantai itu tidak simetris. Setiap kegagalan berasal dari cacat, tetapi tidak setiap cacat pernah menghasilkan kegagalan yang teramati. Justru di celah itulah pekerjaan pengujian berdiri: menyiapkan kombinasi pemicu dengan sengaja, bukan menunggu kombinasi itu kebetulan terjadi di depan antrean.

Kasus uji dan bukti. Kasus uji memuat kondisi awal, data, langkah, dan hasil yang diharapkan, dan hasil yang diharapkan ditulis sebelum eksekusi. Bukti adalah rekaman yang membuat hasilmu bisa diperiksa ulang orang lain. Ukurannya satu kalimat: bisakah orang yang tidak hadir saat kejadian mengulanginya hanya dengan membaca laporanmu?

Tiga status kasus uji. LULUS, GAGAL, dan TERHALANG. Ketiganya menyatakan fakta tentang eksekusi, bukan penilaian tentang penyebab.

Tujuh titik penyaring. Tinjauan kebutuhan dan kriteria penerimaan; tinjauan rancangan dan kode; uji unit; uji integrasi; uji sistem; uji penerimaan pengguna; dan operasi. Semakin ke kanan sebuah cacat baru tertangkap, semakin banyak pekerjaan yang sudah menumpuk di atasnya, dan pada titik terakhir ongkos terbesarnya justru bukan ongkos teknis.

Empat penerima keluaranmu. Pengembang membutuhkan langkah reproduksi dan bukti; pengelola rilis membutuhkan status dan tingkat dampak; pemilik produk membutuhkan gambaran dampak terhadap pengguna untuk memutuskan rilis; petugas lapangan membutuhkan cara menghindari sementara. Penguji menyediakan informasi bagi keempatnya, tidak memutuskan rilis, dan tidak memperbaiki cacat.

Daftar periksa mandiri

Jawab tujuh butir berikut dengan jujur sebelum melanjutkan ke modul berikutnya. Kalau ada satu saja yang kamu jawab "belum", unit yang perlu kamu baca ulang sudah disebutkan di sebelahnya.

1. Saya bisa menuliskan kesalahan, cacat, dan kegagalan dari satu kasus yang sama sebagai tiga kalimat terpisah, tanpa menyalin contoh yang ada di modul ini. (Unit 2, Unit 3)
2. Saya bisa menjelaskan dengan kalimat saya sendiri kenapa sebuah cacat bisa ada tanpa pernah ada kegagalan yang teramati. (Unit 2)
3. Saya bisa menyebut tujuh titik penyaring secara berurutan, dan menempatkan satu cacat baru pada titik paling awal yang masuk akal untuk sifat cacat itu. (Unit 2, Unit 3 langkah 10)
4. Saya bisa menyebut empat penerima keluaran eksekusi uji dan apa yang berbeda dari kebutuhan masing-masing. (Unit 2)
5. Saya bisa menulis catatan bukti yang memuat versi aplikasi, waktu, lingkungan, data, langkah, hasil yang diharapkan, dan hasil yang muncul. (Unit 3 langkah 1 sampai 5)
6. Saya bisa menetapkan status kasus uji di antara tiga pilihan yang ada tanpa menyelipkan dugaan tentang penyebabnya ke dalam status itu. (Unit 3 langkah 6)
7. Saya bisa menahan diri dari menuliskan dugaan penyebab dan nama orang sebagai bagian dari laporan cacat. (Unit 4, salah paham nomor 2 dan 5)

Kalau kamu ingin satu latihan tambahan

Ambil satu aplikasi yang kamu pakai hampir setiap hari. Pilih satu fitur yang punya syarat berupa angka, batas saldo, batas jumlah, batas tanggal, batas jumlah karakter. Tuliskan satu kasus uji lengkap untuk nilai yang berada tepat di batas itu, termasuk hasil yang kamu harapkan. Jangan jalankan dulu; tulis dulu. Kebiasaan menulis harapan sebelum menekan tombol adalah kebiasaan tunggal yang paling membedakan penguji dari orang yang sekadar mencoba-coba.

Ke mana setelah ini

Modul berikutnya berangkat dari titik tempat modul ini berhenti: kamu sudah bisa menjalankan satu kasus uji dan mengenali apa yang kamu lihat. Yang belum kamu miliki adalah cara kerja yang rapi ketika kasus ujinya bukan satu, melainkan puluhan, dan ketika bukti yang kamu kumpulkan harus tetap bisa ditelusuri berminggu-minggu kemudian.