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

Satu transaksi, beberapa masalah

Bayangkan Anda sedang membantu menguji TOKOWARGA, aplikasi kasir untuk koperasi warga. Seorang anggota bernama Aulia hendak membayar belanja senilai Rp75.000 dengan saldo anggota sebesar Rp75.000. Aturan usaha menyatakan bahwa pembayaran boleh dilanjutkan apabila saldo sama dengan atau lebih besar daripada total belanja.

Kasir menekan tombol Bayar dengan Saldo. Aplikasi menampilkan pesan Saldo tidak mencukupi. Transaksi berhenti, antrean bertambah panjang, dan Aulia akhirnya membayar tunai. Dari sudut pandang pengguna, masalahnya sederhana: pembayaran yang semestinya berhasil telah ditolak.

Bagi penguji, kejadian ini perlu diuraikan lebih teliti. Pesan yang salah adalah sesuatu yang terlihat ketika aplikasi dijalankan. Namun, penyebabnya mungkin sudah masuk jauh sebelumnya: seseorang dapat salah menerjemahkan aturan, kondisi dalam program dapat ditulis keliru, atau data pengujian sebelumnya tidak pernah menyentuh keadaan ketika saldo tepat sama dengan total belanja.

Mengapa pengamatan saja belum cukup

Catatan seperti fitur pembayaran bermasalah terlalu kabur untuk ditindaklanjuti. Pengembang belum tahu keadaan yang memicu masalah. Pengelola produk belum tahu transaksi mana yang terdampak. Penguji lain juga belum dapat mengulang kejadian tersebut.

Catatan yang berguna harus menjawab beberapa pertanyaan konkret:

• Versi aplikasi apa yang dijalankan?
• Kapan dan di lingkungan apa pengujian dilakukan?
• Data anggota dan transaksi apa yang digunakan?
• Langkah apa yang dijalankan?
• Hasil apa yang seharusnya muncul?
• Hasil apa yang benar-benar muncul?
• Bukti apa yang menunjukkan hasil tersebut?

Rincian ini mengubah keluhan menjadi informasi yang dapat diperiksa.

Tiga lapisan dalam satu insiden

Insiden Aulia dapat ditulis sebagai tiga kalimat yang berbeda.

1. Kesalahan manusia: pembuat logika pembayaran keliru menerjemahkan aturan bahwa saldo yang sama dengan total masih mencukupi.
2. Cacat dalam produk: kondisi pemeriksaan di aplikasi hanya menerima saldo yang lebih besar daripada total belanja.
3. Kegagalan teramati: ketika saldo Rp75.000 dipakai untuk membayar belanja Rp75.000, aplikasi menolak transaksi dan menampilkan pesan saldo tidak mencukupi.

Ketiganya berkaitan, tetapi tidak dapat dipertukarkan. Kesalahan adalah tindakan atau keputusan manusia. Cacat adalah masalah yang tertanam dalam produk kerja, misalnya aturan, rancangan, kode, atau konfigurasi. Kegagalan adalah perilaku salah yang tampak ketika produk dijalankan dalam keadaan tertentu.

Dampak di dunia nyata merupakan hal berikutnya yang perlu dicatat, tetapi bukan pengganti salah satu dari tiga lapisan tersebut. Dalam kasus ini, dampaknya adalah antrean bertambah dan anggota harus mengganti cara pembayaran.

Mengapa waktu penemuan penting

Cacat yang ditemukan sebelum dipakai kasir biasanya melibatkan lebih sedikit pihak dan lebih sedikit data nyata. Ketika cacat baru ditemukan saat koperasi sedang ramai, tim perlu menangani transaksi gagal, pertanyaan pengguna, pemeriksaan data, perbaikan aplikasi, serta pengujian ulang. Besarnya pekerjaan tidak selalu sama pada setiap kasus, tetapi ruang masalah cenderung melebar setelah produk digunakan.

Karena itu, tugas penguji bukan sekadar mencari sesuatu yang salah. Penguji menjalankan keadaan yang bermakna, membandingkan hasil aktual dengan hasil yang diharapkan, menyimpan bukti, lalu menyampaikan temuannya kepada pihak yang dapat mengambil tindakan.

Posisi eksekusi dalam alur kerja

Eksekusi uji tidak berdiri sendiri. Sebelum pengujian dijalankan, tim telah menetapkan kebutuhan, menerjemahkannya menjadi rancangan, membangun aplikasi, menyiapkan lingkungan, dan menentukan kasus uji. Setelah eksekusi, hasilnya dipakai untuk memperbaiki produk, memutuskan kesiapan rilis, melakukan pengujian ulang, dan membantu pengguna apabila masalah sudah terlanjur muncul.

Alur sederhananya adalah:

kebutuhan → rancangan → pembangunan → pemeriksaan hasil kerja → eksekusi uji → perbaikan → pengujian ulang → keputusan rilis → pemantauan penggunaan

Eksekusi menghubungkan pernyataan tentang perilaku yang diinginkan dengan bukti mengenai perilaku yang benar-benar terjadi. Penguji menyiapkan keadaan awal, menjalankan langkah, mengamati hasil, lalu membandingkannya dengan hasil yang diharapkan. Tanpa pembandingan, kegiatan itu baru berupa penggunaan aplikasi, belum menjadi eksekusi uji yang dapat dinilai.

Titik penyaring cacat

Cacat dapat ditangkap pada beberapa titik. Dalam alur TOKOWARGA, terdapat tujuh titik penyaring yang relevan.

1. Penelaahan kebutuhan: memeriksa apakah aturan saldo ditulis jelas, termasuk keadaan ketika saldo sama dengan total.
2. Penelaahan rancangan: memeriksa apakah keputusan sistem mencakup seluruh hubungan antara saldo dan total.
3. Pemeriksaan hasil pembangunan: memeriksa apakah kondisi yang dibuat sesuai dengan rancangan.
4. Pemeriksaan otomatis tingkat komponen: menjalankan bagian logika pembayaran dengan masukan yang telah ditentukan.
5. Eksekusi antarmuka oleh penguji: menjalankan transaksi melalui tampilan yang dipakai kasir.
6. Uji penerimaan operasional: memastikan alur cocok dengan kegiatan nyata koperasi sebelum rilis.
7. Pemantauan penggunaan: menangkap masalah dari transaksi nyata, catatan sistem, atau laporan pengguna.

Titik terbaik bukan selalu titik terakhir yang berhasil menemukan masalah. Penguji perlu mencari titik paling awal yang memiliki informasi cukup untuk mengenali sifat cacat tersebut.

Pada insiden Aulia, aturan usaha sudah jelas: saldo yang sama masih mencukupi. Cacat berada pada kondisi keputusan yang tidak menerima keadaan sama. Karena sifatnya berupa hubungan sederhana antara dua nilai, pemeriksaan tingkat komponen dengan tiga keadaan—saldo di bawah, sama dengan, dan di atas total—seharusnya dapat menangkapnya sebelum pemeriksaan antarmuka. Penelaahan hasil pembangunan juga mungkin menemukannya apabila pemeriksa secara khusus membandingkan kondisi dengan aturan.

Biaya keterlambatan bukan hanya biaya kode

Ketika masalah ditemukan lebih lambat, pekerjaan tambahan dapat meliputi penelusuran transaksi, komunikasi kepada kasir, penanganan keluhan, pembaruan petunjuk sementara, perbaikan, pemasangan versi baru, dan pemeriksaan ulang. Tidak tepat menganggap setiap cacat pasti murah atau pasti mahal. Hal yang dapat dinilai adalah luasnya pihak, data, dan proses yang sudah terpengaruh.

Empat penerima keluaran eksekusi

Satu hasil uji dipakai oleh penerima yang berbeda.

• Pengembang memerlukan langkah pengulangan, data, lingkungan, hasil aktual, bukti, dan petunjuk bagian perilaku yang menyimpang.
• Pengelola produk memerlukan dampak terhadap pengguna, aturan yang dilanggar, cakupan transaksi terdampak, dan tingkat urgensi keputusan.
• Penguji lain memerlukan kasus uji, versi, keadaan awal, data, status, bukti, serta informasi apakah hasil sudah diuji ulang.
• Petugas dukungan memerlukan gejala yang terlihat pengguna, keadaan pemicu, cara mengenali transaksi terdampak, dan langkah sementara yang telah disetujui.

Catatan eksekusi yang baik memiliki fakta dasar yang sama, tetapi penyampaiannya menonjolkan kebutuhan penerima. Tujuannya bukan membuat empat kebenaran, melainkan membantu empat pihak bertindak berdasarkan bukti yang sama.

Contoh terpandu

Kasus uji BAYAR-004 memeriksa pembayaran ketika saldo anggota tepat sama dengan total belanja. Aturan acuannya adalah pembayaran dapat dilanjutkan jika saldo tidak kurang dari total.

Keadaan uji yang dipakai:

• Versi: TOKOWARGA 1.4.2-uji
• Waktu: 20 September 2026, 09.15 WIB
• Lingkungan: peramban Chromium, komputer kasir simulasi, basis data latihan
• Anggota: Aulia, kode ANG-047
• Saldo awal: Rp75.000
• Keranjang: beras Rp50.000 dan minyak goreng Rp25.000
• Total: Rp75.000

Langkah 1: Pastikan keadaan awal

Penguji masuk sebagai kasir latihan, membuka data ANG-047, dan memastikan saldo yang tampil Rp75.000. Keranjang harus kosong. Pemeriksaan keadaan awal mencegah hasil tercampur dengan transaksi sebelumnya.

Langkah 2: Masukkan data transaksi

Penguji menambahkan beras senilai Rp50.000 dan minyak goreng senilai Rp25.000. Total yang tampil diperiksa kembali: Rp75.000. Bukti pertama diambil dan diberi nama BAYAR-004-sebelum.png. Gambar harus memperlihatkan identitas versi, saldo, dan total.

Langkah 3: Jalankan tindakan

Penguji memilih Bayar dengan Saldo, lalu mencatat hasil tanpa mengulangi tindakan terlebih dahulu. Aplikasi menampilkan Saldo tidak mencukupi dan transaksi tidak terbentuk.

Langkah 4: Bandingkan hasil

Hasil yang diharapkan adalah pembayaran disetujui, transaksi terbentuk, dan saldo akhir menjadi Rp0. Hasil aktual adalah pembayaran ditolak dan saldo tetap Rp75.000. Karena keduanya berbeda, status kasus uji adalah Gagal. Bukti kedua disimpan sebagai BAYAR-004-sesudah.png.

Langkah 5: Susun catatan eksekusi

Catatan ringkasnya memuat identitas kasus, versi, waktu, lingkungan, data, langkah, hasil harapan, hasil aktual, status, dan dua berkas bukti. Hindari kesimpulan yang belum diperiksa, misalnya menyatakan bagian kode tertentu pasti salah. Catatan eksekusi melaporkan apa yang dijalankan dan diamati.

Praktik mandiri dengan simulator

Gunakan Simulator Pembayaran TOKOWARGA yang tertanam pada halaman latihan unit ini. Simulator berjalan langsung di peramban dan tidak memakai data nyata. Sebelum mulai, aktifkan perekaman waktu pada lembar jawaban. Jangan mengubah nilai yang ditetapkan.

Jalankan kasus SIM-BAYAR-011 dengan data berikut:

• Anggota: Bima, kode ANG-113
• Saldo awal: Rp128.500
• Keranjang: kebutuhan dapur Rp83.500 dan perlengkapan kebersihan Rp45.000
• Total: Rp128.500

Lakukan sendiri urutan berikut: buka anggota, pastikan saldo awal, buat keranjang, periksa total, pilih pembayaran saldo, amati pesan dan perubahan saldo, lalu ambil bukti sebelum dan sesudah tindakan. Versi simulator serta lingkungan harus disalin dari tampilan peserta, bukan dari contoh terpandu.

Berkas yang harus diserahkan

Serahkan satu catatan eksekusi dan dua tangkapan layar. Catatan wajib memuat:

1. kode kasus uji;
2. versi aplikasi;
3. waktu eksekusi beserta zona waktu;
4. lingkungan eksekusi;
5. data anggota, saldo, item, dan total;
6. langkah yang benar-benar dijalankan;
7. hasil yang diharapkan;
8. hasil aktual;
9. status Lulus atau Gagal;
10. nama serta keterangan setiap bukti.

Kriteria penilaian

Nilai praktik berasal dari empat bagian yang bobotnya sama: kelengkapan konteks eksekusi, ketepatan langkah dan data, ketepatan perbandingan hasil, serta keterlacakan bukti. Pekerjaan dinilai tuntas apabila semua field wajib terisi, status sesuai dengan perbandingan hasil, dan bukti memperlihatkan keadaan yang disebutkan. Tangkapan layar tanpa catatan tidak cukup. Catatan tanpa bukti juga belum menunjukkan bahwa kasus benar-benar dijalankan.

Salah paham 1: Kesalahan, cacat, dan kegagalan adalah tiga nama untuk hal yang sama

Ketiga istilah itu menunjuk lapisan yang berbeda. Kesalahan terjadi ketika seseorang mengambil tindakan atau keputusan yang tidak tepat. Cacat adalah akibat yang tertanam di dalam suatu produk kerja. Kegagalan adalah perilaku salah yang terlihat saat aplikasi dijalankan dalam keadaan tertentu.

Pada TOKOWARGA, keputusan keliru tentang arti saldo mencukupi merupakan kesalahan manusia. Kondisi yang hanya menerima saldo lebih besar merupakan cacat. Penolakan pembayaran Aulia merupakan kegagalan. Memisahkan ketiganya membantu tim memilih tindakan: memperjelas aturan, memperbaiki produk, atau menangani kejadian operasional.

Salah paham 2: Jika tidak ada kegagalan yang terlihat, berarti tidak ada cacat

Cacat dapat tetap tersembunyi ketika keadaan pemicunya belum dijalankan. Kondisi pembayaran yang salah tidak tampak selama saldo selalu jauh lebih besar atau lebih kecil daripada total. Kegagalan baru muncul ketika nilai yang dipakai menyentuh keadaan tertentu.

Karena itu, satu eksekusi yang lulus hanya memberi informasi tentang keadaan yang benar-benar dijalankan. Hasil tersebut tidak membuktikan bahwa seluruh fitur bebas masalah. Penguji perlu menyatakan ruang lingkup hasil dengan jujur.

Salah paham 3: Tangkapan layar saja sudah menjadi bukti lengkap

Gambar dapat menunjukkan pesan yang muncul, tetapi sering tidak menjelaskan langkah sebelumnya, data awal, waktu, lingkungan, atau hasil yang seharusnya. Sebaliknya, catatan tertulis tanpa artefak pendukung dapat menyulitkan pemeriksaan bahwa hasil benar-benar muncul.

Bukti yang kuat menghubungkan gambar atau catatan sistem dengan kasus uji tertentu. Nama berkas, waktu, versi, data, langkah, dan keterangan perlu saling cocok. Tujuannya bukan mengumpulkan sebanyak mungkin gambar, melainkan menjaga hubungan antara tindakan dan hasil.

Salah paham 4: Status Gagal berarti penguji sudah mengetahui penyebab teknis

Status Gagal hanya menyatakan bahwa hasil aktual berbeda dari hasil yang diharapkan. Penguji boleh memberikan dugaan apabila ada dasar, tetapi dugaan harus ditandai sebagai dugaan. Menulis bahwa kondisi program pasti salah tanpa memeriksa produk kerja dapat mengarahkan penyelidikan ke tempat yang keliru.

Catatan eksekusi sebaiknya menggunakan bahasa observasi: tombol dipilih, pesan tertentu muncul, transaksi tidak terbentuk, dan saldo tidak berubah. Penyelidikan penyebab dilakukan setelah gejala dapat diulang dan bukti tersedia.

Salah paham 5: Titik terbaik untuk menemukan cacat selalu pengujian antarmuka

Antarmuka penting karena mendekati cara pengguna bekerja, tetapi bukan selalu penyaring paling awal atau paling tepat. Masalah pada kejelasan aturan seharusnya dapat ditemukan ketika kebutuhan ditelaah. Masalah pada hubungan sederhana antara dua nilai dapat diperiksa pada bagian logika sebelum seluruh antarmuka tersedia. Masalah yang bergantung pada rangkaian layanan mungkin baru tampak ketika bagian-bagian tersebut dihubungkan.

Pemilihan penyaring perlu merujuk pada sifat cacat dan informasi yang tersedia pada setiap tahap. Untuk cacat TOKOWARGA yang menolak saldo sama dengan total, pemeriksaan logika dengan keadaan di bawah, sama, dan di atas total seharusnya menangkap masalah sebelum uji antarmuka. Alasannya bukan karena satu titik selalu lebih unggul, melainkan karena cacat terletak pada keputusan nilai yang dapat diperiksa secara terpisah.

Kelima koreksi ini membentuk kebiasaan penting: gunakan istilah secara tepat, batasi kesimpulan pada bukti, dan cari tempat paling awal yang masuk akal untuk menyaring cacat.

Kasus bacaan: potongan harga anggota

TOKOWARGA juga memiliki fitur potongan harga untuk anggota yang telah terdaftar dalam program belanja bersama. Aturannya menyatakan bahwa potongan diterapkan pada barang kebutuhan pokok yang memenuhi syarat. Barang lain tetap dihitung dengan harga normal.

Dalam satu pembaruan, tim menambahkan kategori baru bernama Pangan Olahan. Dokumen kebutuhan sudah menyatakan bahwa kategori baru tersebut termasuk barang yang berhak menerima potongan. Rancangan layar menampilkan tanda kelayakan potongan. Daftar kategori pada layanan perhitungan, bagaimanapun, belum diperbarui ketika fitur dibangun.

Saat pengujian internal, data yang dipakai hanya berisi barang dari kategori lama. Seluruh kasus yang dijalankan lulus. Pembaruan kemudian digunakan oleh koperasi latihan. Kasir membuat transaksi untuk anggota program belanja bersama dengan satu produk Pangan Olahan senilai Rp42.000. Ringkasan keranjang menampilkan tanda bahwa barang memenuhi syarat, tetapi total tetap Rp42.000 dan tidak memuat potongan.

Catatan awal dari kasir berbunyi diskon anggota rusak. Kalimat itu menyampaikan adanya gangguan, tetapi belum cukup untuk pengulangan. Petugas pengujian lalu mengumpulkan versi aplikasi, waktu kejadian, kode anggota, kategori barang, harga, langkah, hasil yang diharapkan, hasil aktual, dan gambar ringkasan keranjang. Pemeriksaan berikutnya memastikan bahwa kategori lama masih memperoleh potongan, sedangkan Pangan Olahan tidak.

Menguraikan lapisan masalah

Kesalahan manusia pada kasus ini terjadi ketika pembuat perubahan tidak memasukkan kategori baru ke daftar kategori yang dipakai layanan perhitungan. Cacatnya adalah daftar kelayakan dalam produk tidak memuat Pangan Olahan. Kegagalannya terlihat ketika transaksi anggota berisi barang dari kategori tersebut: tanda kelayakan muncul, tetapi potongan tidak diterapkan pada total.

Dampaknya adalah anggota dapat membayar lebih tinggi daripada nilai yang seharusnya. Dampak tersebut perlu dicatat karena membantu pengelola produk menentukan urgensi dan cakupan penanganan. Namun, dampak tidak menggantikan uraian tentang kegagalan yang dapat diamati.

Menentukan penyaring yang lebih awal

Sifat cacat ini adalah ketidaksamaan daftar kategori antara kebutuhan dan layanan perhitungan. Penelaahan kebutuhan bukan titik utama karena kebutuhan telah menyebut kategori baru secara jelas. Pemeriksaan hasil pembangunan dapat menangkap ketidaksamaan apabila daftar implementasi dibandingkan dengan daftar yang disetujui. Pemeriksaan tingkat komponen juga dapat menangkapnya dengan menjalankan satu contoh untuk setiap kategori yang berhak.

Pengujian antarmuka akhirnya menemukan gejala, tetapi terlambat dibandingkan dua titik tersebut. Alasan pemilihannya harus merujuk pada sifat cacat: data acuan yang tidak lengkap dapat diperiksa sebelum seluruh alur kasir digunakan.

Mengarahkan informasi kepada penerima

Pengembang memerlukan kategori yang gagal, masukan transaksi, hasil perhitungan, versi, dan bukti agar dapat mengulang masalah. Pengelola produk memerlukan informasi bahwa anggota berpotensi membayar terlalu tinggi serta daftar kategori yang mungkin terdampak. Penguji lain memerlukan data uji per kategori, status setiap eksekusi, dan versi perbaikan yang harus diuji ulang. Petugas dukungan memerlukan gejala yang dapat dikenali, cara mengidentifikasi transaksi terkait, dan arahan sementara yang telah disetujui.

Tugas analisis bacaan

Tuliskan jawaban dalam empat bagian. Pertama, nyatakan kesalahan, cacat, dan kegagalan sebagai tiga kalimat terpisah. Kedua, pilih satu titik penyaring paling awal yang layak dan berikan alasan berdasarkan sifat cacat. Ketiga, sebutkan bukti tambahan yang diperlukan bila versi aplikasi belum terlihat pada gambar. Keempat, rumuskan satu kebutuhan informasi khusus bagi masing-masing dari empat penerima. Jawaban dinilai dari ketepatan pemisahan konsep, hubungan alasan dengan fakta kasus, dan kemampuan mengubah fakta yang sama menjadi informasi yang dapat digunakan.

Refleksi atas praktik simulator

Buka kembali catatan SIM-BAYAR-011 yang Anda serahkan. Refleksi ini tidak meminta Anda mengubah hasil agar tampak rapi. Tujuannya adalah memeriksa apakah hubungan antara tindakan, pengamatan, dan kesimpulan sudah dapat ditelusuri.

Mulailah dari status. Jika Anda menulis Gagal, tunjukkan dua kalimat yang menjadi dasarnya: satu kalimat hasil yang diharapkan dan satu kalimat hasil aktual. Keduanya harus membicarakan hal yang sebanding. Contohnya, persetujuan transaksi dibandingkan dengan penolakan transaksi, atau saldo akhir yang diharapkan dibandingkan dengan saldo akhir yang muncul. Membandingkan pesan layar dengan aturan usaha tanpa menjelaskan akibat transaksinya akan meninggalkan celah.

Selanjutnya, periksa bukti. Apakah gambar sebelum tindakan memperlihatkan saldo dan total? Apakah gambar setelah tindakan memperlihatkan pesan serta keadaan transaksi? Apakah versi aplikasi tercatat dari tampilan simulator? Jika suatu fakta tidak terlihat pada gambar, catatan harus menjelaskan sumber fakta tersebut. Bukti bukan hiasan laporan; bukti menjadi penghubung antara pernyataan dan sesuatu yang dapat diperiksa.

Latihan tiga kalimat

Tuliskan kembali insiden pembayaran Bima dalam tepat tiga kalimat dengan pola berikut:

• Kalimat pertama menyatakan kesalahan manusia yang mungkin menghasilkan aturan keputusan yang keliru.
• Kalimat kedua menyatakan cacat yang berada di dalam produk.
• Kalimat ketiga menyatakan kegagalan yang Anda amati saat simulator dijalankan.

Gunakan penanda mungkin pada kalimat pertama apabila simulator tidak memberikan bukti langsung tentang tindakan pembuatnya. Kedisiplinan ini penting. Kegagalan dapat diamati melalui eksekusi, sedangkan kesalahan manusia sering memerlukan pemeriksaan riwayat perubahan, komunikasi, atau produk kerja sebelumnya.

Menilai titik penyaring

Pilih satu titik yang seharusnya dapat menangkap cacat sebelum eksekusi antarmuka. Jelaskan jawaban dengan dua unsur: sifat cacat dan kemampuan titik tersebut. Untuk masalah hubungan antara saldo dan total, alasan yang kuat menjelaskan bahwa cacat berada pada keputusan nilai dan bahwa bagian logika dapat dijalankan dengan keadaan di bawah, sama, serta di atas total. Alasan seperti agar ditemukan lebih cepat belum cukup karena tidak menunjukkan mengapa titik itu mampu menemukan masalah.

Kemudian pikirkan akibat apabila cacat baru ditemukan setelah transaksi nyata berlangsung. Jangan menebak nilai kerugian. Daftarkan jenis pekerjaan yang mungkin muncul, misalnya penelusuran transaksi, komunikasi kepada kasir, koreksi data, pembaruan aplikasi, dan pengujian ulang. Ini menunjukkan mengapa waktu penemuan memengaruhi luas penanganan tanpa membuat angka yang tidak didukung.

Empat penerima, empat keputusan

Gunakan hasil SIM-BAYAR-011 untuk merumuskan satu kalimat bagi setiap penerima:

• Kepada pengembang, berikan informasi yang memungkinkan pengulangan.
• Kepada pengelola produk, jelaskan aturan yang dilanggar dan dampak pengguna.
• Kepada penguji lain, jelaskan keadaan yang harus diuji ulang.
• Kepada petugas dukungan, jelaskan gejala yang dapat dikenali pengguna.

Setelah menulis, periksa apakah keempat kalimat tetap konsisten mengenai versi, data, dan hasil. Penekanan boleh berbeda, tetapi faktanya tidak boleh berubah.

Pemeriksaan reflektif

Jawaban yang kuat dapat menunjukkan batas pengetahuan. Pisahkan apa yang Anda jalankan, apa yang Anda lihat, apa yang Anda simpulkan dari perbandingan, dan apa yang masih berupa dugaan. Kebiasaan tersebut membuat laporan lebih dapat dipercaya dan mencegah tim mengambil tindakan berdasarkan kepastian yang sebenarnya belum tersedia.

Petunjuk pengerjaan

Kuis ini terdiri atas empat kasus baru. Setiap kasus meminta Anda mengambil keputusan berdasarkan prinsip yang telah digunakan pada insiden TOKOWARGA, tetapi nama fitur, data, dan keadaan pemicunya berbeda. Tidak ada pertanyaan yang dapat dijawab hanya dengan mengingat kalimat dari contoh terpandu.

Bacalah seluruh informasi dalam satu kasus sebelum memilih jawaban. Pisahkan fakta mengenai tindakan manusia, keadaan produk, perilaku yang terlihat saat aplikasi dijalankan, dan dampak operasional. Tidak semua kasus menyediakan bukti tentang keempat lapisan tersebut. Jika riwayat tindakan manusia tidak diberikan, jangan memperlakukannya sebagai fakta yang sudah pasti.

Pada kasus eksekusi, perhatikan keadaan awal, tindakan, hasil yang diharapkan, dan hasil aktual. Status kasus ditentukan melalui perbandingan kedua hasil, bukan melalui jumlah langkah yang berhasil dijalankan. Sebuah alur dapat berjalan sampai langkah terakhir dan tetap berstatus Gagal apabila hasil akhirnya menyimpang dari yang diharapkan. Sebaliknya, pesan yang tampak tidak biasa belum cukup dinilai sebagai kegagalan apabila tidak ada dasar yang menjelaskan perilaku yang seharusnya.

Pada kasus bukti, nilai apakah orang lain dapat menghubungkan artefak dengan eksekusi tertentu. Periksa keberadaan versi, waktu, lingkungan, data, langkah, hasil harapan, hasil aktual, status, dan identitas bukti. Sebagian opsi mungkin sama-sama menambahkan informasi berguna. Pilih tindakan yang menutup kekurangan paling penting dalam kasus yang diberikan.

Pada kasus penyaring, jangan memilih tahap hanya karena tahap itu terjadi lebih awal. Hubungkan sifat cacat dengan jenis pemeriksaan yang mungkin dilakukan pada tahap tersebut. Aturan yang tidak jelas, daftar acuan yang tidak lengkap, keputusan nilai yang keliru, dan masalah hubungan antarlayanan dapat membutuhkan penyaring yang berbeda.

Pada kasus penerima informasi, tentukan keputusan apa yang hendak dibuat oleh penerima. Pengembang terutama perlu mengulang dan menyelidiki. Pengelola produk perlu menilai dampak dan kesiapan. Penguji lain perlu menjaga keterlacakan dan melakukan uji ulang. Petugas dukungan perlu mengenali gejala serta memberikan arahan yang telah disetujui. Informasi dasar harus tetap konsisten meskipun penekanannya berubah.

Kerjakan tanpa membuka pembahasan. Setelah memilih seluruh jawaban, bandingkan alasan Anda dengan pembahasan setiap opsi. Perhatikan bukan hanya alasan jawaban benar, tetapi juga kesalahan berpikir yang diwakili oleh pengecoh. Catat satu keputusan yang semula Anda pilih keliru dan jelaskan perubahan alasan Anda dalam dua atau tiga kalimat. Refleksi singkat tersebut membantu menunjukkan apakah Anda memperbaiki cara menilai bukti, bukan sekadar mengganti huruf jawaban.

Ringkasan modul

Pengujian dijalankan untuk memperoleh bukti mengenai perilaku produk dalam keadaan tertentu. Pada insiden utama TOKOWARGA, saldo anggota dan total belanja sama-sama Rp75.000, tetapi pembayaran ditolak. Kasus itu menunjukkan bahwa satu kejadian perlu diuraikan menjadi lapisan yang berbeda.

Kesalahan manusia adalah tindakan atau keputusan yang tidak tepat. Cacat adalah masalah yang tertanam dalam kebutuhan, rancangan, kode, konfigurasi, atau produk kerja lain. Kegagalan adalah perilaku salah yang terlihat ketika aplikasi dijalankan. Dampak adalah akibat kegagalan terhadap pengguna atau kegiatan operasional. Keempatnya saling berkaitan, tetapi tidak dapat saling menggantikan.

Eksekusi uji dimulai dari keadaan awal yang terkendali. Penguji menjalankan langkah yang ditentukan, mengamati hasil aktual, dan membandingkannya dengan hasil yang diharapkan. Status Lulus atau Gagal berasal dari perbandingan tersebut. Dugaan penyebab tidak boleh ditulis sebagai fakta apabila belum diperiksa.

Catatan eksekusi yang lengkap memuat versi aplikasi, waktu beserta zona waktu, lingkungan, data, langkah, hasil yang diharapkan, hasil aktual, status, dan bukti. Keterlacakan muncul ketika semua unsur itu merujuk pada kasus yang sama. Gambar tanpa konteks dan catatan tanpa artefak pendukung sama-sama dapat menyulitkan pemeriksaan.

Cacat dapat disaring ketika kebutuhan ditelaah, rancangan diperiksa, hasil pembangunan diperiksa, bagian logika dijalankan, antarmuka diuji, alur operasional diterima, atau penggunaan dipantau. Titik yang layak dipilih berdasarkan sifat cacat serta informasi yang tersedia. Masalah hubungan sederhana antara saldo dan total dapat ditangkap melalui pemeriksaan logika sebelum seluruh antarmuka digunakan. Masalah daftar acuan dapat ditangkap dengan membandingkan daftar implementasi terhadap kebutuhan yang telah disetujui.

Penemuan yang lebih lambat dapat memperluas pihak, data, dan proses yang perlu ditangani. Hal ini tidak berarti setiap perbaikan memiliki ongkos atau waktu yang sama. Penilaian harus merujuk pada fakta kasus, seperti transaksi yang terdampak, kebutuhan pemulihan, komunikasi kepada pengguna, pemasangan perbaikan, dan pengujian ulang.

Keluaran eksekusi digunakan oleh empat penerima. Pengembang membutuhkan informasi untuk mengulang dan menyelidiki. Pengelola produk membutuhkan aturan yang dilanggar, dampak, cakupan, dan urgensi. Penguji lain membutuhkan jejak eksekusi dan sasaran uji ulang. Petugas dukungan membutuhkan gejala yang dapat dikenali serta arahan sementara yang telah disetujui.

Daftar periksa mandiri

Sebelum melanjutkan ke modul berikutnya, pastikan Anda dapat menjawab Ya pada setiap butir berikut:

• Saya dapat menulis kesalahan, cacat, dan kegagalan sebagai tiga kalimat terpisah.
• Saya tidak menyamakan kegagalan aplikasi dengan dampaknya bagi pengguna.
• Saya telah menjalankan SIM-BAYAR-011 pada simulator, bukan hanya membaca contoh.
• Catatan saya memuat versi, waktu, lingkungan, data, langkah, dua hasil, status, dan bukti.
• Status yang saya pilih sesuai dengan perbandingan hasil harapan dan hasil aktual.
• Bukti sebelum dan sesudah tindakan dapat dihubungkan dengan kode kasus.
• Saya dapat membedakan fakta pengamatan dari dugaan penyebab.
• Saya dapat memilih titik penyaring dengan alasan yang merujuk pada sifat cacat.
• Saya dapat menjelaskan posisi eksekusi di antara pembangunan dan tindakan lanjutan.
• Saya dapat merumuskan kebutuhan informasi bagi empat penerima keluaran.

Jika satu jawaban masih Belum, kembali ke bagian yang terkait dan perbaiki pekerjaan Anda. Khusus untuk praktik simulator, lengkapi penyerahan sampai catatan serta dua bukti memenuhi kriteria. Modul ini selesai ketika Anda bukan hanya dapat menjelaskan eksekusi uji, tetapi juga telah menghasilkan catatan eksekusi yang dapat diperiksa oleh orang lain.