Modul 1 · Kenapa Pengujian Perangkat Lunak Dibagi Berjenjang

Insiden STOK-SINK-01

TokoLancar adalah aplikasi kasir dan stok yang digunakan sebuah toko kelontong. Pada suatu pagi, stok awal produk BERAS-5KG tercatat 60 karung. Pukul 09.10, Kasir A menjual 3 karung ketika koneksi jaringan terputus. Aplikasi menyimpan transaksi itu untuk dikirim setelah jaringan pulih. Pukul 09.12, Kasir B menjual 4 karung melalui perangkat lain yang tetap terhubung.

Saat jaringan Kasir A pulih, transaksi tertunda dikirim. Karena respons pertama dari layanan stok terlambat, aplikasi Kasir A mengirim ulang permintaan yang sama. Layanan stok memproses kedua kiriman sebagai dua transaksi berbeda. Penjualan yang benar berjumlah 7 karung, sehingga stok fisik tersisa 53 karung. Namun, aplikasi mengurangi 3 karung dua kali dan menampilkan stok 50 karung.

Kesalahan baru terlihat ketika petugas menutup toko. Laporan penjualan menunjukkan 7 karung terjual, sedangkan catatan stok seolah-olah menunjukkan 10 karung keluar. Selisih 3 karung memicu pemeriksaan rak, struk, dan riwayat transaksi. Toko tidak kehilangan barang, tetapi petugas menghabiskan waktu untuk mencari kehilangan yang sebenarnya tidak terjadi.

Mengapa pengujian fungsi tunggal tidak cukup

Fungsi pengurangan stok telah diuji secara terpisah. Jika diberi stok 60 dan jumlah penjualan 3, fungsi menghasilkan 57. Jika diberi stok 57 dan penjualan 4, fungsi menghasilkan 53. Kedua hasil itu benar. Masalahnya bukan terletak pada operasi pengurangan, melainkan pada hubungan antara pengiriman ulang transaksi dan layanan stok.

Insiden ini memperlihatkan bahwa keberhasilan bagian-bagian kecil tidak otomatis menjamin keberhasilan kerja bersama. Setiap bagian dapat menjalankan tugasnya sesuai masukan yang diterima, tetapi masukan itu sendiri mungkin dikirim dua kali, berubah bentuk, datang dengan urutan tidak terduga, atau tidak memperoleh penanganan yang aman.

Pengujian juga tidak berhenti ketika hubungan dua komponen sudah benar. Produk dapat gagal saat seluruh alur dijalankan dalam lingkungan yang menyerupai penggunaan sebenarnya. Konfigurasi perangkat, hak akses, pemulihan koneksi, basis data, dan proses latar belakang dapat menimbulkan perilaku yang tidak terlihat dalam pengujian komponen.

Di atas itu, sistem yang secara teknis berjalan masih dapat ditolak oleh pemilik usaha. Misalnya, aplikasi mungkin menghitung stok secara benar tetapi tidak menyediakan jejak koreksi yang dibutuhkan petugas. Pertanyaan pada tahap ini bukan hanya apakah perangkat lunak bekerja, melainkan apakah hasilnya layak dipakai untuk menjalankan kegiatan usaha.

Empat lapis perlindungan

Empat jenjang pengujian membentuk jaring bertingkat. Pengujian unit memeriksa bagian kode yang kecil. Pengujian integrasi memeriksa kerja sama antarkomponen. Pengujian sistem memeriksa perilaku produk sebagai suatu sistem. Pengujian penerimaan menilai kesesuaian hasil dengan kebutuhan dan kriteria pihak yang akan menerima atau memakai produk.

Keempatnya bukan empat kegiatan yang saling menggantikan. Sebuah cacat dapat lolos dari satu lapis dan tertangkap pada lapis berikutnya, tetapi penemuan yang lebih lambat biasanya melibatkan jalur diagnosis yang lebih luas. Ini merupakan kecenderungan, bukan hukum mutlak. Cacat konfigurasi tertentu justru hanya bermakna pada lingkungan sistem, sedangkan ketidaksesuaian kebutuhan baru dapat terlihat ketika pihak bisnis menilai hasilnya.

Untuk STOK-SINK-01, pengujian unit terhadap operasi pengurangan memang berguna, tetapi tidak membuktikan keamanan pengiriman ulang. Pemeriksaan yang paling langsung seharusnya dilakukan ketika Kasir dan layanan stok dihubungkan: kirim transaksi yang sama dua kali dengan identitas yang sama, lalu pastikan stok hanya berkurang sekali. Pengujian sistem dengan skenario koneksi terputus dan pulih menjadi lapis tambahan. Pengujian penerimaan kemudian memastikan bahwa perilaku pemulihan dan jejak transaksinya memenuhi kebutuhan operasional toko.

Sepanjang modul ini, kita akan memakai insiden tersebut untuk belajar memilih jenjang berdasarkan tempat risiko muncul. Sasaran akhirnya bukan memberi setiap cacat sebuah label, melainkan merumuskan pengujian yang menjalankan bagian yang relevan dan menghasilkan bukti yang dapat dinilai.

Pembeda utama

Jenjang pengujian ditentukan oleh pertanyaan yang hendak dijawab dan bagian perangkat lunak yang perlu dijalankan untuk menjawabnya. Ukuran berkas atau banyaknya baris kode bukan penentu tunggal. Sebuah komponen kecil dapat memerlukan pengujian integrasi jika harus berkomunikasi dengan basis data. Sebaliknya, satu aturan rumit dapat diuji pada jenjang unit jika semua ketergantungannya dapat dikendalikan.

Tiga sudut membantu membedakan empat jenjang: cakupan kode yang dijalankan, pihak yang lazim melakukan penilaian, dan cacat yang paling mungkin ditemukan. Pembagian pihak bukan batas kepemilikan yang kaku. Pengembang, penguji, pemilik produk, petugas operasional, dan pengguna dapat bekerja bersama. Perbedaannya terletak pada sudut penilaian yang dibawa.

Pengujian unit

Pengujian unit mengendalikan masukan dan mengamati keluaran sebuah bagian kecil. Contohnya, fungsi hitungTotal menerima harga, jumlah, dan potongan, lalu menghasilkan total pembayaran. Kasus uji dapat memeriksa jumlah nol, potongan maksimum yang diizinkan, atau angka pada batas aturan.

Kekuatan jenjang ini adalah ketepatan lokasi. Ketika hasil salah, ruang pencarian penyebab relatif sempit. Namun, pengujian unit tidak membuktikan bahwa komponen lain mengirim data dengan nama, satuan, urutan, atau waktu yang benar. Pengganti ketergantungan dapat dipakai untuk mengendalikan pengujian, tetapi pemakaiannya bukan pembeda mutlak antara unit dan integrasi. Pembeda utamanya tetap objek serta tujuan pemeriksaan.

Pengujian integrasi

Pengujian integrasi menjalankan hubungan nyata yang relevan antara komponen. Hubungan itu dapat berupa panggilan antarmodul, akses basis data, antrean pesan, layanan jaringan, atau pertukaran berkas. Fokusnya adalah batas tempat satu komponen membuat asumsi tentang komponen lain.

Pada STOK-SINK-01, fungsi pengurangan menerima angka yang valid. Cacat muncul karena pengirim dapat mengulang permintaan, sedangkan penerima tidak mengenali identitas transaksi yang telah diproses. Kasus integrasi dapat mengirim transaksi beridentitas sama dua kali dan memeriksa bahwa hanya satu perubahan stok yang tersimpan.

Pengujian sistem

Pengujian sistem menjalankan produk yang telah dirangkai dalam lingkungan yang cukup mewakili penggunaan sasaran. Alur masuk pengguna, hak akses, penyimpanan, proses latar belakang, jaringan, dan keluaran dapat terlibat sekaligus. Tujuannya menilai perilaku sistem secara utuh, bukan membuktikan setiap fungsi secara terpisah.

Untuk TokoLancar, skenario sistem dapat memutus koneksi setelah kasir menekan tombol bayar, memulihkannya, lalu memeriksa struk, laporan penjualan, stok, dan riwayat sinkronisasi. Pengujian ini dapat menangkap akibat gabungan yang tidak tampak ketika hanya dua komponen diperiksa.

Pengujian penerimaan

Pengujian penerimaan menilai apakah kemampuan yang disediakan memenuhi dasar penerimaan yang telah disepakati. Dasarnya dapat berupa kebutuhan pengguna, aturan operasional, hasil bisnis, atau kewajiban yang relevan bagi penggunaan produk. Pihak yang menilai perlu memiliki wewenang atau pengetahuan untuk menyatakan hasil tersebut layak diterima.

Cakupan pengujian penerimaan tidak harus identik dengan pengujian sistem. Keduanya dapat bertumpang tindih karena sama-sama mungkin memakai aplikasi yang telah dirangkai. Namun, penerimaan dapat memilih hanya alur penting, bukti operasional, atau hasil tertentu. Sebaliknya, pengujian sistem dapat menjelajahi banyak perilaku teknis yang tidak diperiksa langsung oleh penerima. Perbedaan pentingnya terletak pada tujuan, dasar pengujian, pihak penilai, dan kriteria keberhasilan.

Hubungan antarlapis

Satu kebutuhan dapat melahirkan kasus pada beberapa jenjang. Aturan bahwa stok tidak boleh berkurang dua kali dapat diperiksa sebagai aturan lokal pada unit, sebagai perlindungan terhadap kiriman ulang pada integrasi, sebagai pemulihan jaringan pada sistem, dan sebagai ketepatan rekonsiliasi pada penerimaan. Kasus-kasus itu tidak sama karena masing-masing menjalankan cakupan dan mengumpulkan bukti yang berbeda.

Karena itu, pertanyaan yang berguna bukan jenjang mana yang paling hebat. Pertanyaan yang tepat adalah bukti apa yang diperlukan, bagian mana yang harus benar-benar dijalankan, dan siapa yang berwenang menilai keberhasilannya.

Prosedur telusur jenjang empat langkah

Insiden produksi sering datang sebagai keluhan, bukan diagnosis. Kalimat seperti stoknya aneh atau transaksi hilang belum cukup untuk memilih pengujian. Agar keputusan dapat diperiksa, gunakan empat langkah: catat hasil yang teramati, petakan jalur eksekusi, tentukan titik gagal paling awal, lalu rumuskan kasus uji beserta bukti lulusnya.

Kita akan menerapkannya pada STOK-SINK-01. Tujuannya adalah menetapkan jenjang yang seharusnya menangkap cacat lebih awal dan menghasilkan satu kasus uji baru.

Langkah 1 — Catat hasil yang teramati

Mulailah dari fakta yang dapat dibandingkan, bukan dugaan penyebab. Data insiden adalah:

• Stok awal BERAS-5KG: 60 karung.
• Penjualan sah Kasir A: 3 karung.
• Penjualan sah Kasir B: 4 karung.
• Stok fisik akhir: 53 karung.
• Stok dalam aplikasi: 50 karung.
• Permintaan Kasir A memiliki identitas transaksi yang sama pada kedua pengiriman.

Hasil yang diharapkan adalah 60 - 3 - 4 = 53. Selisih aplikasi terhadap stok fisik adalah 3 karung. Rumusan masalahnya: satu penjualan sah sebanyak 3 karung menghasilkan dua pengurangan stok.

Langkah 2 — Petakan jalur eksekusi

Telusuri komponen yang dilewati sampai hasil terbentuk. Pada insiden ini, jalurnya adalah perangkat Kasir A, penyimpan transaksi tertunda, pengirim sinkronisasi, layanan stok, lalu basis data stok. Laporan penjualan membaca catatan transaksi yang hanya tersimpan sekali, sedangkan jumlah stok membaca perubahan yang telah diterapkan dua kali.

Peta ini mempersempit pencarian. Fungsi pengurangan tidak menghasilkan angka keliru untuk satu panggilan. Perbedaan muncul ketika pengirim mengulang pesan dan penerima memperlakukannya sebagai pekerjaan baru. Batas antara pengirim sinkronisasi dan layanan stok menjadi lokasi risiko utama.

Langkah 3 — Tentukan titik gagal paling awal dan jenjangnya

Titik gagal paling awal yang dapat diuji adalah aturan pada hubungan dua komponen: permintaan dengan identitas transaksi yang sama tidak boleh menerapkan perubahan stok lebih dari sekali. Untuk membuktikannya, pengujian harus menjalankan pengirim atau permintaan yang setara, layanan stok, dan penyimpanan hasil. Karena bukti bergantung pada interaksi antarkomponen, jenjang utama yang dipilih adalah integrasi.

Pengujian unit tetap dapat membantu. Misalnya, aturan lokal untuk memeriksa identitas yang sudah diproses dapat diuji secara terisolasi. Namun, unit saja tidak membuktikan bahwa identitas benar-benar dikirim, dibaca, dan disimpan melalui batas komponen. Pengujian sistem juga bernilai sebagai perlindungan tambahan karena dapat menjalankan putus-pulih jaringan. Akan tetapi, pengujian sistem bukan titik pertama yang paling terarah untuk cacat ini.

Pengujian penerimaan dapat memeriksa bahwa rekonsiliasi akhir sesuai kebutuhan toko. Cakupannya tidak perlu sama dengan pengujian sistem. Penerima mungkin hanya menjalankan alur penjualan tertunda yang dianggap kritis dan menilai kesesuaian stok, laporan, serta jejak transaksi.

Langkah 4 — Rumuskan kasus uji dan bukti lulus

Kasus baru diberi kode INT-SINK-02.

Tujuan: membuktikan bahwa pengiriman ulang transaksi yang sama tidak mengurangi stok lebih dari sekali.

Prasyarat: stok BERAS-5KG adalah 80 karung; belum ada transaksi dengan identitas TRX-A17; pengirim sinkronisasi dan layanan stok terhubung ke basis data pengujian.

Tindakan: kirim penjualan 5 karung dengan identitas TRX-A17; tahan respons pertama hingga pengirim melewati batas tunggu; biarkan pengirim mengirim ulang transaksi beridentitas sama; kemudian lepaskan respons.

Bukti lulus: stok akhir 75 karung; hanya satu perubahan stok terkait TRX-A17; catatan penjualan tidak bertambah ganda; pengiriman kedua dicatat sebagai pengulangan yang tidak diterapkan kembali.

Kasus ini tidak sekadar menyebut jenjang. Ia menentukan keadaan awal, pemicu, komponen yang harus berjalan, serta hasil yang dapat diperiksa. Jika stok menjadi 70, bukti menunjukkan bahwa perlindungan terhadap pengiriman ulang gagal.

Mengapa keputusan ini dapat dipertanggungjawabkan

Pemilihan integrasi didasarkan pada kebutuhan bukti, bukan kebiasaan tim. Tanpa menjalankan batas pengiriman dan penerimaan, kita hanya mengetahui bahwa aturan lokal tampak benar. Dengan menjalankan batas tersebut, kasus uji memeriksa asumsi bersama tentang identitas transaksi, pengulangan permintaan, dan penyimpanan perubahan.

Prosedur empat langkah juga mencegah dua lompatan yang sering terjadi: langsung memilih pengujian sistem karena cacat ditemukan di produksi, atau langsung memilih unit karena kode akhirnya diperbaiki dalam satu fungsi. Tempat cacat ditemukan dan tempat kode diubah tidak selalu menentukan jenjang pengujian yang paling informatif.

Salah paham 1: Semua fungsi lulus berarti sistem aman

Pengujian unit memberi bukti kuat tentang perilaku bagian kecil dalam kondisi yang dikendalikan. Bukti itu tidak otomatis mencakup bentuk data dari komponen lain, kegagalan jaringan, konfigurasi lingkungan, atau urutan kejadian. STOK-SINK-01 memperlihatkan bahwa operasi pengurangan dapat benar setiap kali dipanggil, sementara jumlah pemanggilannya salah.

Koreksinya adalah membaca hasil pengujian sesuai batas buktinya. Jika risiko berada pada pertukaran data, jalankan pengujian integrasi. Jika risiko bergantung pada alur produk dan lingkungan, tambahkan pengujian sistem. Kelulusan pada satu jenjang tidak menjadi sertifikat bagi seluruh jenjang di atasnya.

Salah paham 2: Pengujian integrasi berarti banyak kode dijalankan

Banyaknya kode bukan pembeda yang andal. Sebuah pengujian dapat menjalankan sejumlah besar fungsi dalam satu modul tanpa memeriksa satu pun batas antarkomponen. Sebaliknya, pengujian yang relatif kecil dapat menjadi pengujian integrasi karena benar-benar menjalankan pertukaran antara aplikasi dan basis data.

Koreksinya adalah mencari hubungan yang sedang diperiksa. Apakah kasus tersebut membuktikan kesesuaian format, urutan, identitas, transaksi, atau penanganan kegagalan antara dua bagian? Jika ya, pusat perhatiannya adalah integrasi. Cakupan kode membantu menjelaskan pengujian, tetapi tujuan dan batas interaksi menentukan kategorinya.

Salah paham 3: Penggunaan komponen tiruan selalu berarti pengujian unit

Komponen tiruan dapat membantu mengendalikan keadaan, tetapi keberadaannya tidak menetapkan jenjang secara otomatis. Pengujian unit sering memakai pengganti ketergantungan agar bagian kecil dapat diperiksa. Namun, sebuah pengujian integrasi juga dapat mengganti layanan eksternal yang tidak berada dalam kendali tim sambil tetap menjalankan hubungan nyata antarkomponen internal.

Koreksinya adalah menanyakan komponen mana yang sungguh dijalankan dan bukti apa yang dikumpulkan. Jika tidak ada batas nyata yang dijalankan, klaim tentang keberhasilan integrasi harus dibatasi. Jika beberapa komponen nyata berkomunikasi dan pengujian menilai kontraknya, penggantian satu pihak luar tidak serta-merta mengubah seluruh pengujian menjadi unit.

Salah paham 4: Pengujian sistem dan penerimaan selalu sama

Keduanya dapat memakai aplikasi yang sudah dirangkai dan menjalankan alur yang mirip. Namun, cakupannya tidak harus sama. Pengujian sistem menilai perilaku produk dalam lingkungan representatif. Pengujian penerimaan memilih bukti berdasarkan kebutuhan dan kriteria pihak penerima. Penerimaan dapat berfokus pada beberapa kemampuan kritis, hasil operasional, atau bukti tertentu tanpa menjalankan seluruh sistem.

Koreksinya adalah membandingkan tujuan, dasar pengujian, pihak penilai, dan kriteria keberhasilan. Sebuah alur tutup kas dapat diuji oleh tim teknis untuk memeriksa kerja seluruh komponen. Alur serupa dapat dijalankan oleh pemilik kebutuhan untuk memutuskan apakah laporan akhir memenuhi cara kerja toko. Kemiripan langkah tidak menjadikan pertanyaan penilaiannya identik.

Salah paham 5: Jenjang ditentukan oleh tempat cacat ditemukan

Cacat yang ditemukan saat penerimaan tidak selalu merupakan cacat penerimaan. Bisa saja penyebabnya adalah pemetaan data antarlayanan yang seharusnya ditemukan pada integrasi. Demikian pula, cacat produksi tidak otomatis membutuhkan kasus sistem sebagai pertahanan pertama. Tempat penemuan hanya memberi konteks tentang lapisan yang gagal menahannya.

Koreksinya adalah menelusuri titik gagal paling awal yang dapat diuji. Jika aturan lokal salah, unit menjadi pilihan awal. Jika dua bagian tidak sepakat tentang data, integrasi lebih terarah. Jika kegagalan baru muncul dari konfigurasi dan alur lengkap, sistem lebih sesuai. Jika persoalannya adalah ketidaksesuaian dengan kebutuhan penerima, pengujian penerimaan memberikan keputusan yang dibutuhkan.

Kelima koreksi tersebut memiliki satu benang merah: jangan memilih jenjang berdasarkan label alat, jumlah kode, atau lokasi penemuan semata. Pilih berdasarkan risiko, cakupan yang perlu dijalankan, dan bukti yang ingin diperoleh.

Kerjakan setiap soal dengan menandai risiko utama, bagian yang harus benar-benar dijalankan, dan bukti yang diperlukan. Pilih satu jawaban yang paling langsung menguji sumber risiko dalam kasus. Setelah memilih, jelaskan alasanmu sebelum membaca pembahasan. Jangan menentukan jawaban hanya dari pihak yang pertama kali menemukan masalah atau dari banyaknya kode yang tampak terlibat.

Dari label menuju alasan

Menentukan jenjang bukan latihan menempelkan nama pada cacat. Keputusan yang baik harus menjelaskan hubungan antara risiko, cakupan eksekusi, dan bukti. Karena itu, refleksi ini meminta kamu menilai kembali cara berpikirmu, bukan sekadar menghitung jawaban kuis yang benar.

Ambil satu masalah perangkat lunak yang pernah kamu lihat. Masalah itu dapat berasal dari aplikasi kasir, pemesanan makanan, administrasi, pembayaran, atau layanan lain yang akrab bagimu. Hindari memulai dengan dugaan teknis. Tuliskan dahulu apa yang benar-benar diamati: tindakan pengguna, data awal, hasil aktual, dan hasil yang semestinya.

Sebagai contoh struktur, kamu dapat menulis: seorang petugas mengubah alamat pengiriman sebelum pembayaran; halaman pesanan menampilkan alamat baru; label kiriman masih memakai alamat lama. Pernyataan ini belum menyimpulkan komponen mana yang salah. Ia hanya mengikat analisis pada bukti.

Lakukan telusur empat langkah

Pertama, rumuskan hasil teramati dalam satu atau dua kalimat yang dapat diperiksa. Pisahkan angka, status, waktu, atau keluaran yang diketahui dari dugaan penyebab. Jika ada data yang belum diketahui, tandai sebagai pertanyaan, bukan fakta.

Kedua, buat jalur eksekusi sederhana. Sebutkan bagian yang menerima tindakan, bagian yang memproses data, tempat penyimpanan, dan keluaran akhir. Jalur tidak harus memakai nama teknis yang sempurna. Tujuannya adalah menemukan batas tempat data atau kendali berpindah.

Ketiga, tentukan titik gagal paling awal yang dapat diuji. Tanyakan apakah hasil salah sudah dapat dibentuk oleh satu aturan lokal, baru muncul ketika komponen berkomunikasi, memerlukan produk yang telah dirangkai, atau bergantung pada penilaian kebutuhan oleh penerima. Tuliskan satu jenjang utama dan satu alasan. Jika lapisan tambahan bermanfaat, sebutkan sebagai pertahanan berikutnya tanpa mengganti jawaban utama.

Keempat, rumuskan satu kasus uji. Cantumkan keadaan awal, tindakan, dan bukti lulus. Sebutkan komponen yang benar-benar harus dijalankan. Rumusan seperti pastikan fitur berjalan dengan baik belum cukup karena tidak menyatakan hasil yang dapat diamati.

Uji kekuatan alasanmu

Periksa pilihan jenjang dengan tiga pertanyaan. Apakah pengujian menjalankan tempat risiko yang kamu duga? Apakah hasil lulus atau gagal dapat diamati tanpa tafsir kabur? Apakah pihak yang menilai memiliki sudut pandang yang sesuai dengan tujuan pengujian?

Jika jawaban pertama tidak, cakupanmu mungkin terlalu sempit. Jika pengujian menjalankan jauh lebih banyak bagian daripada yang diperlukan, cakupannya mungkin terlalu lebar untuk menjadi pertahanan awal. Jika jawaban kedua tidak, perjelas bukti lulus. Jika jawaban ketiga tidak, kamu mungkin mencampurkan pembuktian teknis dengan keputusan penerimaan.

Sekarang bandingkan dua kemungkinan. Misalnya, masalah label pengiriman dapat berasal dari fungsi pembentuk label yang selalu mengambil alamat lama. Itu dapat diuji pada unit. Namun, jika layanan Pesanan telah menyimpan alamat baru sedangkan layanan Pengiriman menerima salinan lama, risiko utamanya berada pada integrasi. Jika kesalahan hanya muncul setelah seluruh urutan ubah alamat, bayar, dan cetak dijalankan dengan konfigurasi tertentu, sistem menjadi pilihan utama. Jika dokumen benar secara teknis tetapi tidak sesuai tata kerja petugas, penerimaan dibutuhkan.

Refleksi dianggap selesai ketika kamu dapat menyatakan bukan hanya jenjang pilihanmu, tetapi juga bukti yang akan membuatmu mengubah keputusan. Kemampuan merevisi diagnosis berdasarkan bukti merupakan bagian penting dari analisis insiden.

Ringkasan modul

Pengujian perangkat lunak dibagi berjenjang karena satu jenis bukti tidak dapat menjawab semua risiko. Bagian kode dapat benar secara terisolasi tetapi gagal saat bertukar data. Komponen yang telah terhubung dapat bekerja dalam pengujian teknis tetapi gagal ketika seluruh alur, konfigurasi, dan lingkungan digunakan. Produk yang berjalan sesuai rancangan teknis pun masih dapat tidak memenuhi kebutuhan pihak yang menerimanya.

Pengujian unit menjalankan bagian kecil dengan masukan dan keluaran yang terkendali. Jenjang ini paling mungkin menangkap kesalahan lokal seperti cabang kondisi, perhitungan, validasi, dan kondisi batas. Pengembang lazim mengerjakannya karena umpan baliknya dekat dengan kode, meskipun anggota tim lain dapat berkontribusi.

Pengujian integrasi menjalankan hubungan antarkomponen. Jenjang ini menargetkan asumsi pada batas komunikasi, termasuk format, satuan, identitas, urutan, transaksi, pemetaan, dan penanganan kegagalan. Pada STOK-SINK-01, risiko utama berada pada pengiriman ulang transaksi dari sinkronisasi ke layanan stok. Karena bukti yang dibutuhkan bergantung pada kedua sisi hubungan, integrasi menjadi jenjang utama untuk pertahanan awal.

Pengujian sistem menjalankan produk atau bagian besar yang telah dirangkai dalam lingkungan representatif. Jenjang ini memeriksa alur ujung ke ujung, konfigurasi, hak akses, pemulihan, proses latar belakang, dan akibat gabungan. Untuk insiden TokoLancar, pemutusan lalu pemulihan jaringan pada proses penjualan menyediakan lapisan tambahan yang realistis.

Pengujian penerimaan menilai hasil berdasarkan kebutuhan dan kriteria pihak penerima. Cakupannya dapat bertumpang tindih dengan pengujian sistem, tetapi tidak harus sama. Penerimaan dapat memilih alur atau bukti tertentu yang penting bagi operasi. Pembeda utamanya adalah tujuan, dasar penilaian, pihak yang menilai, dan kriteria keberhasilan.

Insiden STOK-SINK-01 menghasilkan pelajaran penting. Stok awal 60 karung dan penjualan sah 7 karung seharusnya menghasilkan stok 53 karung. Aplikasi menampilkan 50 karena transaksi 3 karung diterapkan dua kali. Fungsi pengurangan lokal tetap benar. Cacat berada pada interaksi yang tidak aman terhadap pengiriman ulang.

Prosedur telusur jenjang terdiri atas empat langkah. Pertama, catat hasil yang teramati tanpa melompat ke dugaan. Kedua, petakan jalur eksekusi dan batas perpindahan data. Ketiga, tentukan titik gagal paling awal yang dapat diuji serta pilih jenjang utama. Keempat, rumuskan kasus uji dengan keadaan awal, tindakan, komponen yang dijalankan, dan bukti lulus.

Penerapan prosedur tersebut menghasilkan INT-SINK-02. Kasus dimulai dengan stok 80 karung, mengirim penjualan 5 karung dua kali menggunakan identitas TRX-A17, dan mengharapkan stok akhir 75 karung. Bukti tambahannya adalah hanya satu perubahan stok tersimpan dan pengiriman kedua dikenali sebagai pengulangan.

Daftar periksa mandiri

Sebelum melanjutkan ke modul berikutnya, pastikan kamu dapat menjawab setiap butir berikut dengan alasan:

• Saya dapat membedakan empat jenjang berdasarkan cakupan yang dijalankan.
• Saya dapat menyebut pihak penilai yang sesuai tanpa menjadikannya batas kaku.
• Saya dapat menghubungkan setiap jenjang dengan jenis cacat yang mungkin ditemukan.
• Saya dapat menjelaskan mengapa unit yang lulus tidak menjamin integrasi.
• Saya dapat menjelaskan bahwa cakupan sistem dan penerimaan tidak harus sama.
• Saya dapat menghitung hasil yang benar pada STOK-SINK-01.
• Saya dapat menetapkan integrasi sebagai pertahanan utama untuk insiden tersebut.
• Saya dapat menyebut sistem dan penerimaan sebagai lapisan tambahan yang berbeda tujuan.
• Saya dapat menjalankan prosedur telusur empat langkah pada kasus baru.
• Saya dapat menulis kasus uji dengan keadaan awal, tindakan, dan bukti lulus.

Jika satu butir belum dapat dijelaskan, kembali ke unit yang membahas alasan tersebut. Sasaran modul ini bukan menghafal urutan jenjang, melainkan memilih pengujian yang menghasilkan bukti tepat untuk risiko yang sedang dihadapi.