Modul 1 — Tingkatan Pengujian Perangkat Lunak — Modul 1: Kenapa Pengujian Dibagi Berjenjang

Sabtu pagi yang tidak cocok

Bu Rina punya toko kelontong di tepi jalan kampung di Semarang. Enam bulan terakhir ia memakai TokoLancar, aplikasi kasir dan stok untuk usaha mikro: kasir memindai barang, aplikasi menghitung total, mencetak struk, dan mengurangi catatan stok secara otomatis. Bagi Bu Rina, nilai utama aplikasi itu bukan struknya, melainkan janji bahwa ia tidak perlu lagi menghitung isi rak satu per satu untuk tahu kapan harus memesan barang.

Sabtu pagi itu ada pembeli mencari mi instan. Kasir membuka layar stok TokoLancar: 488 bungkus. Seharusnya lebih dari cukup. Tetapi rak mi instan kosong. Setelah gudang kecil di belakang toko diperiksa dan dihitung satu per satu, sisa fisiknya 20 bungkus. Selisihnya 468 bungkus — dan selisih itu sudah menumpuk diam-diam selama tiga minggu.

Catatan: TokoLancar, Bu Rina, dan seluruh angka dalam kasus ini adalah kasus rekaan yang disusun untuk kelas ini. Kasus ini dibuat menyerupai pola cacat yang lazim, bukan laporan kejadian nyata.

Yang benar-benar merugikan bukan angkanya

Angka 488 di layar, kalau berdiri sendiri, cuma angka salah. Yang merugikan adalah keputusan yang diambil karena percaya pada angka itu. Selama tiga minggu Bu Rina tidak memesan mi instan ke agen, karena aplikasi bilang stoknya aman. Ia kehilangan penjualan pada jam-jam paling ramai, dan yang lebih mahal: dua pelanggan tetap mulai belanja di toko sebelah. Ketika akhirnya ia memesan, harga dari agen sedang naik.

Insiden ini kita beri nama Insiden STOK-01, dan kita akan memakainya sebagai kasus tetap sepanjang modul ini.

Pertanyaan pertama yang biasanya salah

Begitu insiden seperti ini muncul, pertanyaan yang paling cepat keluar biasanya: siapa yang lalai? Programmernya? Pengujinya? Bu Rina yang tidak pernah mengecek rak?

Pertanyaan itu terasa wajar, tetapi hampir tidak pernah menghasilkan perbaikan. Ia menghasilkan orang yang berhati-hati selama dua minggu, lalu cacat sejenis muncul lagi di fitur lain. Pertanyaan yang menghasilkan perbaikan berbunyi lain:

Di titik mana dalam proses kami cacat ini seharusnya sudah ketahuan, dan kenapa titik itu tidak melihatnya?

Itulah pertanyaan yang seluruh modul ini latih.

Kenapa satu jenis pengujian tidak pernah cukup

Ketika tim TokoLancar rapat, tiga jawaban muncul, dan ketiganya masuk akal:

• "Uji unitnya kurang." Padahal tim punya uji unit untuk modul stok, dan semuanya hijau — bahkan setelah insiden, tetap hijau.
• "Harusnya dicoba dulu sebagai aplikasi utuh sebelum rilis." Memang dicoba: penguji melakukan satu transaksi contoh dan struknya benar. Sayangnya barang yang dipakai untuk mencoba dijual per bungkus, bukan per dus.
• "Harusnya Bu Rina yang menyetujui sebelum dipakai." Bu Rina memang menyetujui — ia melihat fitur kasirnya bekerja, dan tidak terpikir memeriksa apa yang terjadi pada catatan stok tiga minggu kemudian.

Perhatikan polanya. Setiap jawaban benar untuk sebagian, dan tidak ada satu pun yang cukup sendirian. Masing-masing melihat perangkat lunak dari jarak yang berbeda: dari sangat dekat (satu fungsi), dari sedang (dua modul yang saling bicara), dari jauh (seluruh aplikasi), dan dari luar (kebutuhan pemilik toko). Cacat yang lolos dari satu jarak pandang justru mencolok dari jarak pandang yang lain.

Dari situlah gagasan jenjang pengujian lahir. Bukan empat kegiatan terpisah yang dikerjakan tim berbeda karena tradisi, melainkan satu jaring bertingkat: beberapa saringan dengan kerapatan berbeda yang dipasang berurutan, masing-masing dirancang menangkap jenis kotoran yang lolos dari saringan sebelumnya.

Yang akan kamu kerjakan di modul ini

Modul ini pendek dan punya sasaran sempit. Kita akan melakukan tiga hal, dan hanya tiga hal:

1. Memetakan empat jenjang — unit, integrasi, sistem, penerimaan — memakai tiga sumbu pembeda yang bisa langsung kamu pakai untuk menggolongkan pengujian apa pun.
2. Membedah Insiden STOK-01 sampai ke akar penyebabnya, dengan prosedur telusur empat langkah, sampai menghasilkan satu kasus uji baru yang tertulis lengkap.
3. Meluruskan lima salah paham yang paling sering membuat orang menaruh pengujian di jenjang yang keliru.

Yang tidak kita kerjakan di modul ini: menulis kode uji dalam bahasa pemrograman tertentu, memilih perkakas, dan mengukur cakupan uji. Itu urusan modul-modul berikutnya. Di sini kamu membangun peta dulu, supaya nanti kamu tahu sedang berdiri di mana.

Satu hal terakhir sebelum lanjut. Selisih 468 bungkus itu bukan cacat yang rumit secara teknis. Perbaikannya, seperti akan kamu lihat nanti, hanya beberapa baris. Yang mahal bukan memperbaikinya, melainkan tiga minggu sampai ada yang menyadarinya. Seluruh gagasan jenjang pengujian berputar di sekitar satu tujuan: memperpendek jarak antara saat cacat lahir dan saat cacat ketahuan.

Gagasan besar unit ini

Empat jenjang pengujian bukan empat kegiatan sejajar yang boleh dipilih salah satu. Keempatnya adalah satu jaring bertingkat, dan tiap jenjang dirancang menangkap jenis cacat yang secara struktural tidak mungkin dilihat oleh jenjang di bawahnya.

Bayangkan penyaringan air: ada saringan kasar untuk daun dan ranting, lalu saringan pasir, lalu saringan halus. Saringan halus tidak membuat saringan kasar jadi mubazir — kalau daun tidak disingkirkan lebih dulu, saringan halus akan mampet terus dan kamu tidak akan pernah tahu apakah airnya bersih. Hubungan antarjenjang pengujian persis seperti itu.

Tiga sumbu pembeda

Agar bisa menggolongkan pengujian apa pun dengan cepat, pakai tiga sumbu berikut. Ketiganya harus ditanyakan bersama-sama; satu sumbu saja sering menyesatkan.

1. Cakupan kode yang dijalankan. Berapa banyak kode nyata yang benar-benar berjalan saat uji dilakukan, dan bagian mana yang digantikan tiruan?
2. Pihak yang mengerjakan. Siapa yang menulis dan menjalankan ujinya, dan seberapa jauh ia dari orang yang menulis kodenya?
3. Jenis cacat yang paling mungkin tertangkap. Kalau uji di jenjang ini gagal, cacat macam apa yang biasanya sedang ia tunjuk?

Peta empat jenjang

Dua pasangan yang paling sering tertukar

Unit dan integrasi: bedanya bukan ukuran, tapi tiruan

Orang sering mengira uji unit itu "uji yang kecil" dan uji integrasi itu "uji yang besar". Ukuran bukan pembedanya. Pembedanya adalah apakah tetangga kode yang diuji digantikan tiruan atau tidak.

Ini penting sekali, dan menjadi kunci seluruh modul: tiruan dibuat oleh orang yang sama, dengan asumsi yang sama, seperti kode yang sedang diuji. Kalau asumsinya keliru, tiruan itu akan mengulang kekeliruan yang sama, dan uji unitnya lulus dengan gemilang justru karena salah. Cacat semacam itu tidak mungkin ditangkap di jenjang unit — bukan karena penulis ujinya kurang teliti, melainkan karena definisi jenjang unit menutup mata terhadapnya.

Sistem dan penerimaan: cakupannya sama, hakimnya berbeda

Di kedua jenjang ini, cakupan kodenya sama-sama seluruh aplikasi. Jadi kalau kamu memakai sumbu pertama saja, keduanya tampak identik. Pembedanya ada di sumbu kedua dan ketiga.

Uji sistem bertanya: "Apakah aplikasi berperilaku sesuai spesifikasi yang kita sepakati?" Hakimnya dokumen kebutuhan, penilainya penguji.

Uji penerimaan bertanya: "Apakah aplikasi ini menolong saya menjalankan toko saya?" Hakimnya kenyataan kerja sehari-hari, penilainya pemilik dan pengguna. Sebuah sistem bisa lulus mutlak di jenjang sistem dan gagal total di jenjang penerimaan — dan ketika itu terjadi, yang cacat biasanya bukan kodenya, melainkan spesifikasinya.

Prinsip jenjang terawal yang mampu

Dari peta di atas lahir satu prinsip kerja yang akan kita pakai terus:

Setiap cacat sebaiknya tertangkap di jenjang paling awal yang secara struktural mampu melihatnya.

Perhatikan dua kata pentingnya. "Paling awal" berarti kita tidak menunda. "Mampu melihatnya" berarti kita tidak memaksakan: menyuruh jenjang unit menangkap cacat kontrak antarmodul adalah pemborosan yang tidak akan pernah berhasil.

Kenapa yang paling awal? Ada dua alasan, dan keduanya praktis:

1. Biaya perbaikan naik seiring waktu. Cacat yang ketahuan saat kode masih hangat di kepala penulisnya diperbaiki dalam hitungan menit. Cacat yang sama, ketahuan tiga minggu kemudian dari keluhan pemilik toko, menyeret rapat, penelusuran ulang, perbaikan data lama, dan permintaan maaf.
2. Ketepatan diagnosis menurun seiring naiknya jenjang. Uji unit yang gagal menunjuk satu fungsi. Uji sistem yang gagal cuma bilang "ada yang rusak di suatu tempat di jalur ini". Keduanya berguna, tetapi yang pertama langsung memberi alamat, sedangkan yang kedua masih menyisakan pekerjaan mencari.

Dua alasan itu sekaligus menjelaskan kenapa jawaban "ya sudah, uji sistem saja semuanya" terdengar hemat tetapi sebenarnya mahal.

Jenjang uji berpasangan dengan tahap perancangan

Satu cara lain melihat keempat jenjang: masing-masing memeriksa satu tingkat keputusan yang pernah kamu ambil saat membangun sistem. Uji unit memeriksa keputusan tentang isi satu fungsi. Uji integrasi memeriksa keputusan tentang bagaimana modul-modul dipecah dan disepakati saling bicara. Uji sistem memeriksa keputusan tentang bagaimana fitur-fitur dirangkai jadi satu produk. Uji penerimaan memeriksa keputusan paling awal dan paling berisiko: apa sebenarnya yang dibutuhkan pengguna.

Karena itu, cacat di jenjang atas biasanya lebih mahal — ia menandakan keputusan yang lebih mendasar ternyata keliru.

Untuk pembaca yang ingin menelusuri pembakuan istilah jenjang pengujian di luar kelas ini, dua rujukan yang lazim dipakai industri dicantumkan di bagian sitasi unit ini. Di kelas ini kita memakai istilah dan penjelasan versi kita sendiri; rujukan itu disebut agar kamu tahu ke mana melanjutkan, bukan karena isinya kita kutip.

Data yang kita punya

Sekarang kita bedah Insiden STOK-01 sampai tuntas. Berikut data teknis yang dikumpulkan tim TokoLancar setelah insiden.

Barang: mi instan, kode katalog MI-40. Dijual dua cara: per bungkus dan per dus. 1 dus = 40 bungkus. Harga per bungkus Rp2.300, jadi harga satu dus Rp92.000.

Modul yang terlibat:

• Katalog — menyimpan daftar barang, harga, dan aturan konversi satuan.
• Kasir — menyusun transaksi, menghitung total, mencetak struk.
• Stok — mencatat sisa barang dalam satuan simpan, yaitu bungkus.

Alur saat kasir menjual 1 dus mi instan:

1. Kasir memanggil Katalog.ambilItem("MI-40", satuan: "dus", jumlah: 1).
2. Katalog mengembalikan { kode: "MI-40", jumlah: 1, harga: 92000 }. Konversi 1 dus = 40 bungkus dipakai hanya untuk menghitung harga, lalu dibuang.
3. Kasir meneruskan nilai jumlah apa adanya: Stok.kurangi("MI-40", 1).
4. Stok menafsirkan 1 sebagai 1 bungkus, dan mengurangi catatan sebanyak 1.

Akibatnya, dalam tiga minggu: stok awal 500 bungkus, terjual 12 dus. Fisik berkurang 12 × 40 = 480 bungkus, tersisa 20. Catatan aplikasi hanya berkurang 12, jadi tertulis 488. Selisih 468 bungkus — persis angka yang kita lihat di unit pengantar.

Yang bikin nyeri: kedua uji unit yang relevan lulus, dan tetap lulus sesudah insiden.

• Uji unit Katalog: "harga 1 dus MI-40 harus 92.000". Dihitung 40 × 2.300 = 92.000. Lulus, dan memang benar.
• Uji unit Stok: "kurangi 40 dari 500, sisanya harus 460". Lulus, dan memang benar.

Masing-masing modul benar menurut asumsinya sendiri. Cacatnya tidak berada di dalam salah satu modul; cacatnya berada di antara keduanya, pada satu kata bernama jumlah yang dipahami dua modul dengan arti berbeda.

Prosedur telusur jenjang: empat langkah

Sekarang kita jalankan prosedur bakunya. Ada empat langkah, dikerjakan berurutan.

Langkah 1 — Tulis ulang cacatnya sebagai "apa yang salah", bukan "siapa yang salah"

Rumusan buruk: "Programmer kasir lupa mengonversi satuan."

Rumusan baik: "Nilai pada medan jumlah yang dikirim Kasir ke Stok bersatuan dus, sedangkan Stok menafsirkannya sebagai bungkus. Tidak ada pihak yang memeriksa kesepakatan satuan itu."

Kenapa ini langkah pertama? Karena rumusan pertama menutup penelusuran ("sudah ketemu orangnya"), sedangkan rumusan kedua membukanya: begitu kamu menyebut dua pihak dan satu kesepakatan yang tak diperiksa, jenjangnya hampir menampakkan diri sendiri.

Langkah 2 — Tentukan cakupan kode terkecil yang harus berjalan bersama agar cacat itu muncul

Mari uji satu per satu:

• Jalankan Katalog sendirian: cacat tidak muncul. Harganya benar.
• Jalankan Stok sendirian: cacat tidak muncul. Pengurangannya benar.
• Jalankan Kasir sendirian dengan Stok digantikan tiruan: cacat tidak muncul. Tiruan itu ditulis oleh orang yang sama, yang juga mengira jumlah bersatuan dus, jadi tiruannya menerima 1 dengan senang hati.
• Jalankan Kasir dan Stok yang asli bersama-sama: cacat muncul.

Jadi cakupan terkecilnya: dua modul nyata yang saling memanggil, tanpa tiruan di antaranya. Ini tepat definisi jenjang integrasi.

Catat baik-baik butir ketiga. Uji unit di sini bukan sekadar gagal menangkap — ia secara struktural buta. Menambah uji unit sebanyak apa pun tidak akan mengubah hasilnya, karena tiruan selalu mengulang asumsi yang sedang keliru.

Langkah 3 — Periksa apakah di cakupan itu tersedia orang dan data yang bisa mengenalinya

Cakupan sudah pas belum tentu cukup; harus ada yang sanggup melihat kesalahannya.

• Orang: pengembang yang menulis Kasir maupun Stok tahu bahwa mi instan punya dua satuan. Pengetahuan itu ada di tim.
• Data: ujinya harus memakai barang yang dijual per dus. Kalau data ujinya cuma barang satuan seperti sabun batang, cacat ini tetap tak terlihat meski cakupannya sudah benar.

Di sinilah kegagalan tim yang sebenarnya. Mereka bukan tidak punya uji yang menjalankan Kasir dan Stok bersama — mereka punya. Tetapi seluruh data ujinya barang satuan. Cakupan benar, data salah.

Langkah 4 — Tetapkan jenjang terawal yang memenuhi Langkah 2 dan Langkah 3, lalu tulis satu kasus uji baru di jenjang itu

Jenjang terawal yang memenuhi keduanya: integrasi.

Kasus uji barunya, ditulis lengkap:

Nama: INT-STOK-07 — Penjualan satuan dus mengurangi stok dalam satuan bungkus

Jenjang: Integrasi (Kasir + Stok asli, tanpa tiruan, dengan basis data uji)

Diketahui: katalog memuat MI-40 dengan konversi 1 dus = 40 bungkus, dan catatan stok MI-40 bernilai 500 bungkus.

Ketika: kasir menyelesaikan satu transaksi berisi 1 dus MI-40.

Maka: Stok.kurangi menerima nilai jumlah 40, dan catatan stok MI-40 menjadi 460 bungkus.

Uji ini berjalan dalam hitungan detik, gagal dengan pesan yang menunjuk tepat ke medan jumlah, dan akan gagal lagi setiap kali seseorang menambah barang bersatuan ganda tanpa konversi.

Lalu jenjang lain bagaimana?

Perlu ditegaskan: integrasi bukan satu-satunya jenjang yang bisa menangkap STOK-01, melainkan yang paling awal.

• Sistem bisa menangkapnya — asalkan skenario ujinya berbunyi "jual satu dus, lalu buka laporan stok dan periksa angkanya". Skenario tim hanya sampai "struk tercetak benar", jadi lolos.
• Penerimaan juga bisa — Bu Rina pasti menyadarinya begitu ia mencocokkan rak dengan layar. Persoalannya, ia baru melakukan itu tiga minggu kemudian, dan itulah tiga minggu yang mahal.
• Unit, seperti sudah kita buktikan di Langkah 2, tidak bisa. Bukan karena kurang teliti, melainkan karena buta secara struktural.

Inilah wujud nyata prinsip jenjang terawal yang mampu: bukan memilih satu jenjang dan membuang sisanya, melainkan menaruh tiap pemeriksaan di tempat ia paling murah dan paling cepat menunjuk alamat.

Di bawah ini lima salah paham yang paling sering muncul ketika orang baru mulai berpikir dalam kerangka jenjang. Tiap salah paham disajikan dalam tiga bagian: yang sering dikira, kenapa itu keliru, dan rumusan yang benar.

1. "Kalau cakupan uji unit sudah tinggi, sistemnya aman"

Yang sering dikira. Cakupan uji unit adalah ukuran mutu yang menyeluruh. Kalau angkanya mendekati seratus persen, berarti hampir semua cacat sudah tersaring.

Kenapa keliru. Cakupan mengukur berapa banyak baris kode yang ikut dijalankan oleh uji, bukan berapa banyak kesepakatan antarmodul yang sudah diperiksa. Di Insiden STOK-01, baris Stok.kurangi("MI-40", 1) ikut dijalankan oleh uji unit Kasir dan tercatat sebagai "tercakup" — padahal justru baris itulah yang salah. Cakupan bisa mencapai angka tinggi sementara seluruh cacat kontrak lolos tanpa perlawanan.

Yang benar. Cakupan uji unit menjawab pertanyaan "apakah ada kode yang tidak pernah dijalankan sama sekali?" — pertanyaan yang berguna, tetapi sempit. Ia tidak dan tidak akan pernah menjawab "apakah dua modul sepakat soal arti sebuah medan?"

2. "Pengujian integrasi itu membuka aplikasinya lalu diklik-klik"

Yang sering dikira. Begitu ada dua modul yang terlibat, dan kita menjalankan aplikasinya lalu mencoba fiturnya, itu sudah pengujian integrasi.

Kenapa keliru. Menjalankan aplikasi utuh lewat antarmuka pengguna adalah pengujian sistem, bukan integrasi. Bedanya bukan soal formalitas istilah, melainkan soal apa yang kamu dapat ketika uji itu gagal. Uji integrasi menyalakan dua modul tertentu dan memeriksa data yang lewat di antara keduanya; kalau gagal, ia menunjuk medan mana yang bermasalah. Klik-klik di antarmuka cuma memberi tahu bahwa layarnya menampilkan angka aneh — kamu masih harus mencari sendiri di lapisan mana kesalahannya lahir.

Yang benar. Uji integrasi punya sasaran sempit dan sengaja: sekelompok kecil komponen nyata, dijalankan bersama tanpa tiruan di antara mereka, dengan pemeriksaan pada data yang menyeberang.

3. "Pengujian penerimaan itu cuma pengujian sistem yang terakhir"

Yang sering dikira. Karena cakupan kodenya sama-sama seluruh aplikasi, uji penerimaan hanyalah putaran terakhir uji sistem, kali ini ditonton pemiliknya.

Kenapa keliru. Yang membedakan bukan cakupan, melainkan hakim dan tolok ukurnya. Uji sistem mengukur aplikasi terhadap dokumen kebutuhan. Uji penerimaan mengukur aplikasi terhadap kenyataan kerja sehari-hari. Kalau spesifikasinya sendiri yang salah paham terhadap cara toko bekerja, uji sistem akan lulus mulus setiap kali diulang — karena ia mengukur terhadap dokumen yang sama-sama keliru. Hanya orang yang menjalankan toko itu yang bisa berkata, "benar begini yang kalian tulis, tapi bukan begini toko saya jalan."

Yang benar. Uji sistem menanyakan "apakah kami membangunnya dengan benar?" Uji penerimaan menanyakan "apakah kami membangun benda yang benar?" Dua pertanyaan berbeda, dan tidak ada yang bisa menggantikan yang lain.

4. "Jenjang yang lebih tinggi lebih meyakinkan, jadi cukup uji sistem saja"

Yang sering dikira. Uji sistem menjalankan semuanya sekaligus. Kalau lulus di situ, otomatis lulus juga di bawahnya — jadi lebih efisien menghapus jenjang bawah.

Kenapa keliru. Dua hal runtuh sekaligus, persis dua alasan yang kita bahas di unit kuliah. Pertama, umpan baliknya lambat: ratusan uji sistem butuh menit sampai puluhan menit, sementara ratusan uji unit selesai dalam detik, sehingga cacat baru ketahuan jauh setelah penulisnya berpindah ke pekerjaan lain. Kedua, diagnosisnya kabur: uji sistem yang merah cuma bilang "transaksi berdiskon menghasilkan total salah", tanpa menunjuk apakah salahnya di rumus diskon, di pembulatan, atau di penulisan ke basis data.

Ada pula alasan praktis ketiga: uji sistem mudah rapuh. Satu perubahan tata letak tombol bisa memerahkan puluhan uji yang sebenarnya tidak menyangkut logika apa pun, dan tim yang lelah mulai mengabaikan warna merah.

Yang benar. Jenjang atas menjawab pertanyaan yang tak terjangkau jenjang bawah, bukan mengulang pekerjaannya. Wajar kalau jumlah uji sistem jauh lebih sedikit daripada jumlah uji unit — masing-masing dipakai untuk hal yang berbeda.

5. "Cacat lolos ke produksi berarti pengujinya lalai"

Yang sering dikira. Setiap insiden produksi menandakan ada orang yang tidak teliti. Perbaikannya: tegur, ingatkan, minta lebih hati-hati.

Kenapa keliru. Sebagian besar cacat yang lolos bukan lolos karena ada yang mengantuk, melainkan karena tidak ada satu pun jenjang yang sedang menghadap ke arah cacat itu. Di Insiden STOK-01, semua orang bekerja benar: uji unit ditulis, dijalankan, dan hijau; penguji mencoba aplikasinya dan struknya benar; pemilik toko menyetujui fitur yang ia lihat. Yang tidak ada adalah satu uji integrasi dengan data barang bersatuan ganda. Menegur orang tidak menambah uji itu; menegur orang hanya membuat mereka takut melaporkan insiden berikutnya lebih awal.

Yang benar. Insiden adalah keterangan tentang rancangan jaring, bukan tentang watak orang. Pertanyaan penutup penelusuran seharusnya berbunyi: "jenjang mana yang seharusnya menangkapnya, dan uji apa yang kita tambahkan hari ini supaya kelas cacat ini tidak lolos lagi?"

Benang merah kelima salah paham

Perhatikan bahwa kelimanya adalah wajah berbeda dari satu kekeliruan yang sama: menyangka jenjang pengujian dibedakan oleh ukuran atau oleh tingkat kesungguhan. Padahal yang membedakannya adalah tiga sumbu yang sudah kamu pelajari — cakupan kode yang dijalankan, pihak yang mengerjakan, dan jenis cacat yang paling mungkin tertangkap. Setiap kali kamu ragu menggolongkan sebuah pengujian, kembalilah ke tiga sumbu itu dan jawab ketiganya, bukan cuma yang pertama.

Apa yang diuji di sini

Kuis ini tidak menanyakan definisi. Semua soalnya berupa kasus baru yang belum pernah muncul di unit mana pun sebelumnya, dan tidak satu pun bisa dijawab dengan mencocokkan kata dari bacaan. Yang diuji adalah apakah kamu sanggup mengambil keputusan penggolongan ketika kasusnya berbeda dari contoh yang sudah dibedah bersama.

Semua kasus masih berlatar TokoLancar dan Toko Bu Rina, supaya kamu tidak perlu membangun konteks baru di kepala. Tetapi cacatnya baru, dan diagnosisnya belum pernah diberikan kepadamu.

Bentuk dan aturan

• Empat soal, semuanya pilihan ganda dengan empat pilihan (A–D).
• Satu jawaban benar per soal.
• Waktu yang disarankan: sekitar 12 menit, jadi rata-rata tiga menit per soal. Kalau lewat, tetap lanjutkan; batas ini bukan penilaian.
• Tidak ada pengurangan nilai untuk jawaban salah. Jangan mengosongkan soal.

Cara mengerjakan yang disarankan

Jangan langsung membaca pilihan jawabannya. Pilihan ganda punya kebiasaan buruk: ia menyeret kamu memilih yang "kedengarannya paling pintar" sebelum kamu berpikir sendiri. Kerjakan begini:

1. Baca kasusnya saja, tutup pilihan jawabannya. Rumuskan dulu di kepala atau di kertas: apa yang salah di sini — bukan siapa yang salah. Ini Langkah 1 dari prosedur telusur jenjang.
2. Tanyakan cakupan terkecil. Kode sebanyak apa yang harus benar-benar berjalan bersama-sama agar cacat ini menampakkan diri? Satu fungsi? Dua modul nyata? Seluruh aplikasi? Ini Langkah 2.
3. Tanyakan siapa yang sanggup mengenalinya, dan dengan data apa. Kadang cakupannya sudah benar tetapi tidak ada orang atau data yang bisa melihat kesalahannya. Ini Langkah 3.
4. Baru buka pilihan jawabannya, dan cari yang paling cocok dengan hasil pikiranmu sendiri.

Untuk soal yang menanyakan tindakan (bukan penggolongan), tambahkan satu pertanyaan lagi: apakah tindakan ini akan menangkap kelas cacat yang sama di masa depan, atau hanya menambal kejadian kali ini?

Hal yang perlu kamu waspadai

Tiga jebakan berpikir berikut sengaja diwakili oleh pilihan-pilihan yang salah. Kenali sekarang supaya kamu tidak terperosok:

• Menyamakan tempat gejala terlihat dengan jenjang yang bisa menangkapnya. Hampir semua cacat akhirnya kelihatan di layar pengguna. Itu tidak berarti semuanya adalah urusan uji sistem.
• Menyamakan asal aturan dengan pihak yang mengujinya. Aturan bisnis selalu datang dari pemilik usaha. Itu tidak berarti setiap pelanggaran aturan bisnis hanya bisa ditangkap di jenjang penerimaan.
• Menyamakan banyaknya modul yang terlibat dengan jenis cacatnya. Sebuah fitur bisa melibatkan lima modul, sementara cacatnya duduk rapi di dalam satu fungsi.

Sesudah selesai

Bacalah pembahasan setiap soal, termasuk soal yang kamu jawab benar. Pembahasan tidak hanya menerangkan mengapa kuncinya benar, tetapi juga kesalahan berpikir mana yang diwakili tiap pilihan lain. Bagian itulah yang paling berguna: kamu akan mengenali kesalahan-kesalahan tersebut di rapat pascainsiden di tempat kerjamu, diucapkan dengan penuh keyakinan oleh orang yang tidak sadar sedang keliru.

Kalau ada dua soal atau lebih yang meleset, jangan langsung mengulang kuis. Kembalilah dulu ke unit kuliah untuk tabel tiga sumbu, lalu ke unit contoh untuk empat langkah telusurnya, baru coba lagi. Mengulang kuis tanpa membaca ulang hanya melatih ingatanmu terhadap pilihan jawaban, bukan pemahamanmu terhadap jenjang.

Kenapa ada unit refleksi

Peta empat jenjang gampang dihafal dan gampang menguap. Ia baru menempel kalau kamu pernah memakainya untuk melihat pekerjaanmu sendiri, dengan nama modul yang kamu kenal dan insiden yang pernah bikin harimu berantakan. Unit ini tidak menambah materi baru. Ia menyuruhmu memakai yang sudah ada.

Sediakan sekitar sepuluh menit dan sesuatu untuk menulis. Menulis, bukan sekadar memikirkan — kalimat yang tidak sanggup kamu tuliskan biasanya belum benar-benar kamu pahami.

Bahan: satu insiden nyata

Pilih satu insiden yang pernah kamu alami atau saksikan: ada yang rusak setelah dirilis, dan ada yang terganggu karenanya. Tidak perlu insiden besar. Laporan yang salah angkanya, tombol yang diam saja saat ditekan, notifikasi yang terkirim ke orang keliru — semuanya cukup.

Kalau kamu belum pernah terlibat dalam insiden produksi, pakai skenario cadangan berikut, dan perlakukan seolah-olah kamu anggota timnya:

Skenario cadangan. Sebuah aplikasi presensi karyawan mencatat jam pulang setiap orang satu jam lebih awal daripada kenyataan. Penyebabnya: peladen aplikasi berjalan pada zona waktu yang berbeda dari zona waktu kantor, dan modul yang menyimpan waktu presensi tidak mengubahnya ke zona waktu setempat sebelum menulis ke basis data. Uji unit modul penyimpanan waktu lulus semua, karena ujinya memakai zona waktu peladen yang sama. Kesalahan ini baru ketahuan pada akhir bulan, saat bagian keuangan menghitung uang lembur dan menemukan jam lembur karyawan terpotong.

Empat pertanyaan

Jawab empat pertanyaan berikut secara berurutan. Tiap jawaban cukup dua sampai empat kalimat.

Pertanyaan 1 — Rumuskan cacatnya tanpa menyebut siapa pun.
Tulis satu kalimat yang menerangkan apa yang salah, tanpa satu pun nama orang atau peran. Kalau kalimatmu terasa lebih sulit ditulis daripada yang kamu duga, itu pertanda bagus: berarti kamu memang biasa berpikir dalam kerangka "siapa", dan sedang melatih kerangka yang lain.

Pertanyaan 2 — Tentukan cakupan terkecilnya.
Berapa banyak kode yang harus benar-benar berjalan bersama-sama agar cacat itu menampakkan diri? Satu fungsi saja? Dua komponen nyata yang saling memanggil? Seluruh aplikasi di lingkungan yang mirip produksi? Sebutkan juga bagian mana yang, kalau digantikan tiruan, membuat cacat itu menghilang dari pandangan.

Pertanyaan 3 — Periksa orang dan datanya.
Andaikan tim sudah punya uji pada cakupan yang kamu sebut di Pertanyaan 2, apakah uji itu pasti menangkapnya? Belum tentu — ingat Insiden STOK-01, yang cakupannya sudah benar tetapi seluruh data ujinya barang satuan. Data seperti apa yang harus ada agar cacatmu terlihat, dan siapa di tim yang punya pengetahuan untuk tahu bahwa data itu penting?

Pertanyaan 4 — Tulis satu kasus uji baru.
Tetapkan jenjang paling awal yang memenuhi dua pertanyaan sebelumnya, lalu tulis satu kasus uji dalam bentuk Diketahui — Ketika — Maka, seperti INT-STOK-07 di unit contoh. Beri nama, sebutkan jenjangnya, dan pastikan bagian "Maka" berisi angka atau keadaan yang bisa diperiksa mesin, bukan penilaian seperti "tampil dengan benar".

Dua pertanyaan lanjutan untuk diskusi

Kalau kamu belajar bersama orang lain, dua hal ini biasanya memancing pembicaraan paling berguna:

• Di tim kamu, jenjang mana yang paling gemuk dan mana yang hampir kosong? Banyak tim punya ratusan uji unit dan nol uji integrasi, lalu heran kenapa cacat kontrak antarmodul terus lolos. Ada juga yang sebaliknya: semuanya diuji lewat antarmuka, sehingga setiap kegagalan butuh setengah hari untuk dicari alamatnya.
• Siapa yang berperan sebagai pengguna sungguhan pada uji penerimaan di tempat kamu? Kalau jawabannya "tidak ada, kami yang mewakili mereka", kamu baru saja menemukan sumber kelas cacat yang tidak akan pernah tertangkap oleh jenjang mana pun di bawahnya.

Tanda bahwa refleksimu berhasil

Refleksi ini berhasil bukan ketika kamu bisa menyebut nama keempat jenjang, melainkan ketika reaksi pertamamu terhadap insiden berikutnya berubah. Sebelumnya, reaksi wajar adalah mencari penyebab dan memperbaikinya secepat mungkin. Sesudah modul ini, ada satu pertanyaan tambahan yang muncul sendiri sebelum kamu menutup tiket:

Jenjang mana yang seharusnya menangkap ini, dan uji apa yang saya tambahkan hari ini supaya kelas cacat ini tidak lolos lagi?

Satu insiden yang menghasilkan satu uji baru di jenjang yang tepat jauh lebih berharga daripada sepuluh insiden yang menghasilkan sepuluh perbaikan cepat dan nol pengaman baru.

Yang sudah kamu bangun di modul ini

Modul ini berangkat dari satu insiden: catatan stok TokoLancar menunjukkan 488 bungkus mi instan sementara di gudang hanya tersisa 20, selisih 468 bungkus yang menumpuk selama tiga minggu. Dari situ kita membangun tiga hal.

1. Tiga sumbu untuk membedakan jenjang

Setiap kali kamu ragu menggolongkan sebuah pengujian, jawab tiga pertanyaan ini bersama-sama, bukan salah satunya saja:

• Cakupan kode yang dijalankan — berapa banyak kode nyata yang berjalan, dan apa yang digantikan tiruan?
• Pihak yang mengerjakan — siapa yang menjalankan ujinya, dan seberapa jauh ia dari penulis kodenya?
• Jenis cacat yang paling mungkin tertangkap — kalau uji ini merah, cacat macam apa yang biasanya sedang ia tunjuk?

Hasilnya, ringkas: unit menjalankan satu satuan kecil dengan tetangga digantikan tiruan, dikerjakan pengembangnya sendiri, dan menangkap salah rumus atau salah batas nilai. Integrasi menjalankan dua komponen nyata atau lebih tanpa tiruan di antaranya, dikerjakan pengembang atau penguji, dan menangkap ketidakcocokan kontrak seperti satuan ukur dan format data. Sistem menjalankan seluruh aplikasi lewat antarmuka pengguna, dikerjakan penguji, dan menangkap alur ujung-ke-ujung yang putus serta perilaku lintas fitur. Penerimaan menjalankan seluruh aplikasi juga, tetapi dinilai pemilik dan pengguna dengan skenario kerja nyata, dan menangkap kebutuhan yang sejak awal salah dipahami.

Dua pasangan yang paling sering tertukar: unit dan integrasi dibedakan oleh ada atau tidaknya tiruan, bukan oleh ukuran; sistem dan penerimaan punya cakupan kode yang sama dan dibedakan oleh hakim serta tolok ukurnya.

2. Prinsip jenjang terawal yang mampu

Setiap cacat sebaiknya tertangkap di jenjang paling awal yang secara struktural mampu melihatnya. Ada dua alasan: biaya perbaikan naik seiring berjalannya waktu, dan ketepatan diagnosis menurun seiring naiknya jenjang. Kata "mampu" sama pentingnya dengan kata "terawal" — menuntut jenjang unit menangkap cacat kontrak antarmodul adalah pemborosan yang tidak akan pernah berhasil, karena tiruan selalu mengulang asumsi yang sedang keliru.

3. Prosedur telusur jenjang empat langkah

1. Tulis ulang cacatnya sebagai "apa yang salah", bukan "siapa yang salah".
2. Tentukan cakupan kode terkecil yang harus berjalan bersama agar cacat itu muncul.
3. Periksa apakah di cakupan itu tersedia orang dan data yang bisa mengenalinya.
4. Tetapkan jenjang terawal yang memenuhi Langkah 2 dan Langkah 3, lalu tulis satu kasus uji baru di jenjang itu.

Dijalankan pada Insiden STOK-01, prosedur ini menghasilkan jawaban integrasi, beserta satu kasus uji tertulis, INT-STOK-07, yang memeriksa bahwa penjualan 1 dus MI-40 mengurangi catatan stok dari 500 menjadi 460 bungkus.

Daftar periksa mandiri sebelum lanjut ke modul berikutnya

Centang enam butir berikut dengan jujur. Butir yang belum bisa kamu centang menunjuk bagian mana yang perlu kamu baca ulang.

1. Saya bisa menyebut ketiga sumbu pembeda dari ingatan, dan menerangkan kenapa memakai sumbu cakupan kode saja membuat jenjang sistem dan penerimaan tampak sama. (Kalau belum: unit kuliah, bagian tiga sumbu dan bagian dua pasangan yang tertukar.)
2. Saya bisa menerangkan kenapa uji unit tidak mungkin menangkap Insiden STOK-01, dengan alasan tentang tiruan — bukan dengan alasan bahwa penulis ujinya kurang teliti. (Kalau belum: unit contoh, Langkah 2.)
3. Saya bisa menyebut satu contoh cacat yang lolos dari jenjang sistem tetapi tertangkap di jenjang penerimaan, dan menjelaskan kenapa kodenya justru tidak salah dalam kasus itu. (Kalau belum: unit miskonsepsi, salah paham nomor 3.)
4. Saya bisa menerangkan kenapa angka cakupan uji unit yang tinggi tidak menjamin apa pun tentang kesepakatan antarmodul. (Kalau belum: unit miskonsepsi, salah paham nomor 1.)
5. Saya sudah menjalankan keempat langkah telusur pada satu insiden saya sendiri — atau pada skenario cadangan aplikasi presensi — dan menghasilkan satu kasus uji tertulis dalam bentuk Diketahui — Ketika — Maka. (Kalau belum: unit refleksi, Pertanyaan 1 sampai 4.)
6. Saya menjawab benar sedikitnya tiga dari empat soal kuis, dan sudah membaca pembahasan seluruh soal termasuk yang saya jawab benar. (Kalau belum: kerjakan ulang setelah membaca ulang unit kuliah dan unit contoh, bukan sebelumnya.)

Yang menanti di modul berikutnya

Modul ini memberimu peta. Modul-modul selanjutnya turun ke masing-masing jenjang satu per satu: bagaimana memilih kasus uji unit yang benar-benar berguna, bagaimana menyusun uji integrasi tanpa membuatnya lambat, bagaimana merancang skenario uji sistem yang mewakili pemakaian nyata, dan bagaimana menyiapkan uji penerimaan bersama pemilik usaha yang tidak punya latar teknis.

Bawa satu hal ini ke sana: jenjang bukan tangga yang harus dinaiki sampai puncak, melainkan jaring yang harus dirancang lubangnya. Yang menentukan mutu bukan berapa banyak uji yang kamu punya, melainkan apakah tiap kelas cacat punya setidaknya satu jenjang yang sedang menghadap ke arahnya.