Modul 1 — Kenapa Dokumentasi Pengujian Menentukan Nasib Sebuah Rilis

Pertanyaan yang sulit dijawab pukul sebelas malam

Pukul sebelas malam, sebuah pesan masuk ke grup kerja: "Perbaikannya sudah dites belum? Kalau aman, kita rilis malam ini juga."

Kamu memang sudah mengujinya. Sore tadi kamu membuka aplikasi, mencoba alur pembayaran berulang kali, mengganti-ganti nominal, mencoba dari dua ponsel yang ada di mejamu, dan tidak menemukan masalah. Maka kamu mengetik jawaban yang paling jujur menurutmu saat itu: "Sudah, aman."

Rilis berjalan. Enam jam kemudian layanan pelanggan mulai menerima keluhan, dan pertanyaan berikutnya datang bertubi-tubi: bagian mana saja yang tadi kamu coba? Pakai data apa? Versi yang mana? Apakah kasus yang sekarang bermasalah termasuk yang kamu uji, atau memang tidak sempat tersentuh?

Di titik itu kamu sadar: kamu tidak sedang kekurangan pengujian. Kamu kekurangan jejak.

Masalahnya bukan kamu tidak menguji

Ini yang membuat situasinya terasa tidak adil. Kamu bekerja. Kamu teliti. Kamu bahkan menemukan dua hal aneh dan sempat mengeceknya lagi sampai yakin bukan masalah. Tetapi seluruh hasil kerja itu berhenti di satu tempat: kepalamu.

Selama semuanya berjalan lancar, tidak ada yang menuntut lebih. Begitu ada yang meledak, semua orang tiba-tiba membutuhkan sesuatu yang tidak pernah kamu tulis. Dan ingatan, sebaik apa pun, punya sifat yang buruk sebagai alat bukti: ia menyusut, ia berubah, dan ia tidak bisa dibaca orang lain.

Tiga hal yang hilang ketika pengujian tidak meninggalkan jejak

Pertama, keputusan jadi macet. Setelah insiden, tim harus memutuskan: tarik rilis atau perbaiki maju? Perbaikan ini perlu diuji ulang seluruhnya atau sebagiannya saja? Keputusan semacam itu butuh bahan. Kalau bahannya tidak ada, yang tersisa hanyalah dugaan yang diucapkan dengan nada percaya diri.

Kedua, pekerjaan diulang dari nol. Minggu depan ada perbaikan lanjutan. Karena tidak ada catatan tentang apa yang sudah dicoba dan bagaimana caranya, orang berikutnya — bisa jadi kamu sendiri — mulai lagi dari halaman kosong. Waktu yang seharusnya dipakai menguji hal baru habis untuk menyusun ulang hal lama.

Ketiga, beban pembuktian jatuh ke satu orang. Ketika mitra atau pemeriksa dari luar tim meminta bukti bahwa fitur ini pernah diuji, satu-satunya sumber adalah orang yang mengerjakannya. Kalau ia sedang cuti, pindah kerja, atau sekadar lupa, tim kehilangan kemampuan menjawab. Ini bukan soal ketidakpercayaan pada individu; ini soal organisasi yang menaruh seluruh memorinya di satu kepala.

"Aman" adalah kesimpulan, bukan bukti

Kalimat "sudah dites, aman" sebenarnya melompati banyak hal. Ia menyampaikan kesimpulan tanpa menyertakan dasar kesimpulan itu. Orang yang menerimanya tidak bisa menilai apakah kesimpulan itu kuat atau rapuh, karena ia tidak tahu seberapa luas pengujiannya, di lingkungan apa, dengan data seperti apa, dan bagian mana yang sengaja atau terpaksa dilewati.

Dokumentasi pengujian, pada intinya, adalah usaha menyertakan dasar itu — secukupnya, dalam bentuk yang bisa dibaca orang lain, agar keputusan berikutnya bisa diambil dengan mata terbuka.

Dokumentasi bukan pekerjaan tambahan setelah pengujian

Banyak orang membayangkan urutannya begini: uji dulu sampai selesai, lalu kalau sempat, tulis laporannya. Dengan urutan itu, dokumentasi selalu menjadi korban pertama saat waktu menipis — dan waktu selalu menipis.

Modul ini berangkat dari cara pandang yang berbeda. Menentukan apa yang akan diuji, mencatat apa yang benar-benar dijalankan, dan menandai apa yang tidak sempat disentuh adalah bagian dari pengujian itu sendiri. Tanpa itu, yang kamu lakukan lebih dekat ke mencoba-coba daripada menguji: aktivitasnya mirip, tetapi hasilnya tidak bisa dipertanggungjawabkan, tidak bisa diulang, dan tidak bisa dipakai siapa pun kecuali dirimu, itu pun hanya untuk beberapa hari ke depan.

Yang akan kamu kerjakan di modul ini

Modul pembuka ini punya tiga sasaran yang saling menyambung:

1. Membedah satu kasus kegagalan rilis dan menunjukkan, satu per satu, keputusan mana yang tidak bisa diambil karena buktinya tidak pernah ditulis.
2. Memisahkan kebutuhan empat pembaca dokumentasi pengujian — penguji lain, pengembang, pemilik produk, dan pemeriksa dari luar tim — karena keempatnya mencari hal yang berbeda dari dokumen yang sama.
3. Menutup dengan latihan menulis satu paragraf: untuk apa dokumentasi pengujian ada di tempat kerjamu sendiri, bukan di tempat kerja ideal yang tidak pernah kamu temui.

Cara membaca modul ini

Siapkan satu rilis nyata dari pekerjaanmu — boleh yang lancar, boleh yang berantakan — dan pakai itu sebagai bahan bandingan di setiap unit. Modul ini tidak akan memberimu templat untuk diisi. Templat mudah didapat di mana saja, dan templat yang diisi tanpa paham tujuannya justru menghasilkan dokumen tebal yang tidak menolong siapa-siapa.

Dokumentasi pengujian ada untuk menopang keputusan

Satu gagasan besar menopang seluruh modul ini: dokumentasi pengujian bukan arsip, melainkan alat pengambilan keputusan. Kalau kamu menerima gagasan ini, hampir semua pertanyaan praktis tentang dokumentasi jadi lebih mudah dijawab — termasuk pertanyaan yang paling sering muncul, yaitu "sedetail apa saya harus menulis?"

Jawabannya tidak pernah "sedetail mungkin". Jawabannya: sedetail yang dibutuhkan oleh keputusan yang harus diambil, oleh orang yang harus mengambilnya.

Keputusan apa yang sebenarnya sedang ditopang

Di sekitar sebuah rilis, ada beberapa keputusan yang berulang di hampir semua tim:

• Rilis sekarang, tunda, atau rilis sebagian? Misalnya hanya untuk sepuluh persen pengguna dulu, atau hanya untuk satu wilayah.
• Cacat ini diperbaiki sekarang atau masuk antrean? Ini keputusan tentang risiko, bukan tentang selera.
• Setelah ada perubahan, bagian mana yang wajib diuji ulang? Menguji ulang semuanya jarang mungkin; menebak-nebak berbahaya.
• Kalau terjadi insiden, dari mana kita mulai mencari? Jawaban tercepat biasanya datang dari catatan tentang apa yang sudah dan belum diuji.

Setiap keputusan itu menuntut informasi tertentu. Kalau informasinya tidak tersedia dalam bentuk yang bisa dibaca, keputusan tetap akan diambil — hanya saja diambil berdasarkan tebakan dan suara yang paling percaya diri di ruangan.

Empat isi yang membuat catatan pengujian bisa dipakai

Catatan pengujian yang berguna, sependek apa pun, biasanya memuat empat hal berikut.

1. Cakupan — apa yang benar-benar dijalankan. Bukan "fitur pembayaran sudah diuji", tetapi alur mana, kondisi mana, dengan data seperti apa. Kalimat "sudah diuji" tanpa rincian tidak bisa dipakai untuk apa pun.

2. Batas — apa yang tidak diuji, dan kenapa. Ini bagian yang paling sering hilang dan paling mahal akibatnya. Alasannya boleh sangat manusiawi: waktu habis, lingkungan uji tidak tersedia, data mitra belum siap. Yang penting alasannya tertulis.

3. Hasil dan buktinya. Apa yang terjadi ketika dijalankan, bukan hanya lulus atau gagal. Untuk kasus yang gagal, sertakan langkah yang membuatnya muncul kembali. Bukti seperlunya — potongan log, tangkapan layar, kode kesalahan — bukan seluruh isi layar.

4. Sisa risiko dan rekomendasi. Setelah semua dijalankan, apa yang masih mungkin bermasalah, dan seberapa besar dampaknya bagi pengguna. Inilah bagian yang paling dibaca oleh orang yang menandatangani rilis.

Di atas keempatnya, ada penanda konteks yang sering dianggap remeh tetapi menentukan: versi atau nomor build yang diuji, lingkungan tempat pengujian dijalankan, data uji yang dipakai, tanggal, dan siapa yang menjalankan. Tanpa penanda ini, catatan yang paling rinci sekalipun kehilangan makna, karena tidak jelas ia berbicara tentang perangkat lunak yang mana.

Kenapa "yang tidak diuji" lebih menentukan daripada "yang lulus"

Daftar panjang berisi kasus yang semuanya lulus terasa menenangkan, tetapi nilainya untuk pengambilan keputusan terbatas. Ia hanya berkata: di wilayah yang kami periksa, tidak ditemukan masalah.

Yang menentukan justru pertanyaan sebaliknya: seberapa luas wilayah yang tidak diperiksa, dan seberapa berbahaya wilayah itu? Fitur pembayaran yang diuji untuk tiga mitra dari dua puluh mitra yang aktif punya arti sangat berbeda dari fitur pembayaran yang diuji untuk semua mitra — padahal keduanya bisa sama-sama dilaporkan sebagai "seluruh kasus lulus".

Menuliskan batas bukan pengakuan kelemahan. Ia justru memindahkan keputusan tentang risiko ke tangan orang yang memang berwenang mengambilnya.

Empat pembaca, empat kebutuhan yang berbeda

Dokumen yang sama dibaca oleh orang-orang yang mencari hal berbeda. Inilah sebabnya satu bentuk laporan tidak pernah cocok untuk semua.

Penguji lain ingin bisa mengulang pekerjaanmu. Ia butuh langkah yang cukup rinci, data uji, kondisi awal, dan lingkungan. Pertanyaannya: "kalau saya jalankan lagi, apakah saya akan sampai di titik yang sama?"

Pengembang ingin bisa mempersempit penyebab. Ia butuh langkah paling pendek yang memunculkan masalah, apa yang diharapkan versus apa yang terjadi, pesan kesalahan, dan versi yang dipakai. Pertanyaannya: "di mana ini rusak?"

Pemilik produk ingin bisa memutuskan. Ia butuh dampak ke pengguna, seberapa sering terjadi, sisa risiko, dan pilihan yang tersedia beserta konsekuensinya. Rincian teknis yang tidak mengubah pilihan justru mengaburkan. Pertanyaannya: "apa akibatnya bagi pengguna dan apa pilihan saya?"

Pemeriksa dari luar tim — auditor internal, tim mitra, tim keamanan, atau siapa pun yang tidak hadir saat pengujian berlangsung — ingin bisa menelusuri sendiri. Ia butuh catatan yang berdiri sendiri: tertanggal, terhubung ke versi tertentu, konsisten antara apa yang direncanakan, apa yang dijalankan, dan keputusan apa yang diambil. Pertanyaannya: "bisakah saya memastikan ini tanpa bertanya kepada penulisnya?"

Perhatikan bahwa keempat kebutuhan ini tidak saling bertentangan; mereka hanya berbeda kedalaman dan sudut pandang. Praktik yang lazim adalah menulis satu catatan rinci untuk penguji dan pengembang, lalu menyusun ringkasan pendek berisi cakupan, batas, sisa risiko, dan rekomendasi untuk pemilik produk — dengan tautan ke catatan rincinya, sehingga pemeriksa luar tetap bisa menelusuri.

Uji sederhana untuk catatanmu sendiri

Sebelum menutup sebuah catatan pengujian, ajukan satu pertanyaan: kalau setahun dari sekarang orang yang tidak pernah kamu temui membaca ini, apakah ia bisa menyimpulkan apa yang diuji, apa yang tidak, apa hasilnya, dan apa yang tersisa — tanpa menghubungi siapa pun?

Kalau jawabannya ya, panjang-pendeknya tidak lagi penting. Kalau jawabannya tidak, menambah halaman biasanya tidak menolong; yang kurang justru salah satu dari empat isi di atas.

Membedah rilis 3.7.0

Catatan tentang kasus ini. Kasus di bawah adalah rekaan yang disusun dari pola kejadian yang lazim ditemui pada tim perangkat lunak. Nama perusahaan, produk, angka, dan tanggalnya tidak merujuk pada perusahaan mana pun. Yang perlu kamu perhatikan bukan detail ceritanya, melainkan cara membedahnya — cara itu bisa langsung kamu pakai pada rilis di tempat kerjamu.

Latar

PT Andara Digital mengelola aplikasi pembayaran tagihan bernama Bayarin. Rilis 3.7.0 membawa satu fitur baru: bayar sebagian dengan saldo dompet, sisanya dengan kartu debit (pembayaran terbelah). Fitur ini berlaku untuk semua jenis tagihan yang tersedia di aplikasi: listrik, air, internet, dan cicilan.

Tim pengujian punya waktu dua hari sebelum jadwal rilis. Seorang penguji menjalankan 23 kasus uji manual dan tidak menemukan kegagalan. Hasilnya disampaikan di grup kerja dalam bentuk satu pesan dan satu tangkapan layar berisi transaksi yang berhasil. Rilis disetujui.

Yang terjadi

Sehari setelah rilis, layanan pelanggan menerima 61 laporan dengan pola yang sama: saldo dompet pengguna terpotong, tetapi status tagihan tetap belum lunas. Semua laporan berasal dari pengguna yang membayar tagihan air pada satu penyedia daerah. Untuk jenis tagihan lain, tidak ada laporan serupa.

Dalam empat jam pertama, tim harus mengambil beberapa keputusan. Mari kita telusuri satu per satu.

Keputusan 1: Tarik rilis, atau matikan fitur untuk satu penyedia saja?

Yang dibutuhkan: apakah pembayaran terbelah pernah diuji untuk penyedia tagihan air daerah tersebut, atau penyedia itu memang tidak termasuk dalam 23 kasus uji.

Yang tersedia: pesan grup berbunyi "semua kasus lulus" tanpa daftar kasusnya.

Akibatnya: tim tidak bisa membedakan dua kemungkinan yang menuntut tindakan berbeda. Kalau penyedia itu pernah diuji dan lulus, artinya ada perbedaan antara lingkungan uji dan lingkungan sesungguhnya — masalahnya luas dan menarik seluruh rilis adalah pilihan yang masuk akal. Kalau penyedia itu tidak pernah tersentuh, masalahnya sempit dan cukup mematikan fitur untuk penyedia tersebut. Tanpa daftar cakupan, tim memilih opsi paling aman: menarik seluruh rilis, termasuk membatalkan perbaikan lain yang sebenarnya tidak bermasalah.

Keputusan 2: Sejak kapan dan berapa pengguna yang terdampak?

Yang dibutuhkan: nomor build yang diuji dan yang dirilis, serta waktu pengujian.

Yang tersedia: tangkapan layar tanpa nomor versi, dikirim pukul sekian tanpa keterangan build.

Akibatnya: tim tidak bisa memastikan bahwa yang diuji adalah paket yang sama dengan yang dirilis. Muncul dugaan bahwa pengujian dilakukan pada build sebelum satu perubahan kecil digabungkan. Dugaan itu tidak bisa dikonfirmasi maupun disangkal, dan berjam-jam habis untuk berdebat soal itu alih-alih memperbaiki.

Keputusan 3: Apakah gejala ini pernah muncul saat pengujian?

Yang dibutuhkan: hasil per kasus uji, termasuk kejadian yang sempat aneh lalu tidak terulang.

Yang tersedia: kesimpulan tunggal "aman".

Akibatnya: penguji mengingat samar-samar bahwa ada satu transaksi yang statusnya lambat berubah, tetapi berhasil pada percobaan kedua. Karena tidak dicatat, tidak ada yang tahu tagihan mana, penyedia mana, dan jam berapa. Petunjuk yang mungkin paling berharga hilang, dan tim mulai mencari dari nol di log produksi.

Keputusan 4: Setelah diperbaiki, seberapa luas pengujian ulangnya?

Yang dibutuhkan: daftar 23 kasus uji itu, supaya bisa dijalankan ulang secara terarah.

Yang tersedia: tidak ada.

Akibatnya: penguji harus menyusun ulang kasus uji dari ingatan. Hasilnya bukan hanya lebih lambat, tetapi juga tidak sebanding: tidak ada yang bisa memastikan bahwa pengujian ulang mencakup semua yang dulu dicakup. Rilis perbaikan pun berangkat dengan keyakinan yang sama rapuhnya dengan rilis pertama.

Keputusan 5: Apa yang dijawab ke mitra penyedia tagihan?

Yang dibutuhkan: catatan yang berdiri sendiri — versi, lingkungan, cakupan, hasil — yang bisa dikirim tanpa perlu dijelaskan lisan.

Yang tersedia: riwayat obrolan grup yang bercampur dengan percakapan lain.

Akibatnya: tim tidak punya apa pun yang layak dikirim ke pihak luar. Yang bisa disampaikan hanya pernyataan bahwa fitur "sudah melalui pengujian", yang justru memperburuk kepercayaan ketika mitra bertanya lebih lanjut.

Ringkasan bedah

Perhatikan polanya: hampir semua yang macet berpangkal pada dua hal — cakupan dan batas. Bukan pada ketiadaan templat, bukan pada kurangnya tangkapan layar.

Apa yang akan berubah dengan catatan lima belas baris

Bayangkan penguji yang sama, dengan waktu yang sama, menulis catatan sependek ini sebelum rilis:

Build yang diuji : Bayarin 3.7.0-rc2
Lingkungan       : staging, data mitra tiruan
Tanggal          : 10-11 (dua hari)
Pelaksana        : (nama penguji)

Diuji  : pembayaran terbelah untuk listrik, internet, cicilan.
         23 kasus: saldo cukup, saldo kurang, kartu ditolak,
         koneksi putus di tengah proses.
TIDAK diuji : tagihan air (data mitra tiruan belum tersedia
         di staging sampai hari terakhir).
Catatan : 1 transaksi listrik statusnya berubah lambat
         (~40 detik), berhasil pada percobaan ulang.
         Belum ditelusuri.
Sisa risiko : tagihan air belum tersentuh sama sekali;
         perubahan status yang lambat belum dijelaskan.
Rekomendasi : rilis boleh jalan, fitur terbelah dimatikan
         untuk tagihan air sampai bisa diuji.

Catatan ini tidak menambah satu pun kasus uji. Ia tidak membuat perangkat lunaknya lebih baik. Yang ia ubah hanya satu: keputusan-keputusan di atas menjadi mungkin diambil. Insiden mungkin tetap terjadi — tetapi terjadi sebagai risiko yang sudah diketahui dan dipilih, bukan sebagai kejutan yang tidak bisa dijelaskan kepada siapa pun.

Latihanmu

Ambil satu rilis dari pekerjaanmu, lalu isi tabel bedah tadi dengan empat kolom yang sama. Kalau kolom "yang tersedia" banyak kosongnya, itu bukan kegagalan pribadi — itu peta pekerjaan untuk modul-modul berikutnya.

Enam salah paham yang membuat dokumentasi jadi sia-sia

Salah paham di bawah ini bukan hasil kemalasan. Semuanya masuk akal kalau dilihat dari pengalaman sehari-hari, dan justru itu yang membuatnya bertahan lama. Untuk tiap salah paham, kita lihat kenapa ia terdengar benar, di mana letak kelirunya, dan apa koreksinya.

Salah paham 1: "Dokumentasi itu pekerjaan administratif, kerjakan kalau sempat."

Kenapa terdengar masuk akal. Dalam sehari kerja, menulis laporan memang terasa berbeda dari menguji. Menguji menghasilkan temuan; menulis terasa hanya memindahkan yang sudah diketahui.

Di mana kelirunya. Perbedaan itu benar hanya kalau satu-satunya pengguna hasil pengujian adalah dirimu sendiri, hari itu juga. Begitu ada orang lain yang harus mengambil keputusan berdasarkan pengujianmu — dan selalu ada — hasil pengujian yang tidak tertulis sama saja dengan tidak ada. Kalau dokumentasi dijadwalkan "kalau sempat", ia otomatis menjadi bagian pertama yang dibuang, karena waktu selalu habis.

Koreksinya. Perlakukan pencatatan cakupan dan batas sebagai bagian dari eksekusi, bukan tahap sesudahnya. Menulis satu baris saat kasus uji selesai jauh lebih murah daripada menyusun ulang semuanya dua minggu kemudian dari ingatan.

Salah paham 2: "Kalau semua lulus, tidak ada yang perlu ditulis."

Kenapa terdengar masuk akal. Laporan sering diasosiasikan dengan masalah. Tidak ada masalah, tidak ada yang dilaporkan.

Di mana kelirunya. Nilai terbesar sebuah catatan pengujian justru muncul ketika semuanya lulus, karena di situlah keputusan rilis diambil. Pernyataan "semua lulus" tanpa daftar cakupan tidak memberi tahu apa pun tentang seberapa luas pemeriksaannya. Dua tim bisa sama-sama melaporkan "semua lulus" padahal yang satu memeriksa sepuluh kali lebih banyak daripada yang lain.

Koreksinya. Yang wajib ditulis bukan kegagalan, melainkan cakupan dan batas. Hasil lulus atau gagal hanyalah salah satu isinya.

Salah paham 3: "Riwayat obrolan grup dan komentar tiket sudah cukup jadi dokumentasi."

Kenapa terdengar masuk akal. Semua percakapan memang tersimpan, bisa dicari, dan tercatat waktunya. Rasanya seperti arsip lengkap.

Di mana kelirunya. Obrolan adalah rekaman proses berpikir, bukan rekaman kesimpulan. Isinya bercampur dengan topik lain, tersebar di banyak utas, dan sering memuat pernyataan yang belakangan dibatalkan tanpa penanda jelas. Orang yang membacanya tidak bisa tahu mana kesimpulan akhir dan mana dugaan yang sempat lewat. Untuk pembaca dari luar tim, ini praktis tidak bisa ditelusuri.

Koreksinya. Obrolan boleh jadi bahan mentah, tetapi harus mengendap menjadi satu catatan yang berdiri sendiri: satu tempat, satu versi, satu kesimpulan.

Salah paham 4: "Dokumentasi yang baik berarti yang panjang dan lengkap."

Kenapa terdengar masuk akal. Dokumen tebal terlihat seperti kerja keras, dan templat yang beredar memang sering menuntut banyak kolom.

Di mana kelirunya. Panjang tidak berbanding lurus dengan kegunaan. Dokumen empat puluh halaman yang tidak menyebutkan apa yang tidak diuji lebih tidak berguna daripada catatan lima belas baris yang menyebutkannya. Lebih buruk lagi, dokumen panjang punya biaya tersembunyi: orang berhenti membacanya, dan tim berhenti memperbaruinya. Dokumen yang tidak diperbarui bukan hanya sia-sia, tetapi menyesatkan — ia berbicara tentang versi yang sudah tidak ada.

Koreksinya. Ukur kegunaan dengan pertanyaan, bukan dengan jumlah halaman: bisakah pembaca menyimpulkan cakupan, batas, hasil, dan sisa risiko tanpa bertanya kepada penulisnya?

Salah paham 5: "Kalau pengujiannya sudah otomatis, dokumentasinya tidak perlu."

Kenapa terdengar masuk akal. Kode otomasi memang menjelaskan dirinya sendiri: apa yang dijalankan tertulis di sana, dan laporan hasilnya keluar otomatis.

Di mana kelirunya. Kode otomasi menjelaskan apa yang berjalan sekarang, bukan apa yang dijalankan saat itu pada versi tertentu, dengan hasil apa, dan keputusan apa yang diambil setelahnya. Kode yang sama bisa berubah dua kali sebelum rilis berikutnya. Selain itu, otomasi hampir tidak pernah mencakup segalanya; justru bagian yang tidak diotomatiskan itulah yang paling perlu ditulis. Dan bagi pemilik produk atau pemeriksa dari luar tim, membaca kode bukan cara yang layak untuk mengetahui sisa risiko.

Koreksinya. Otomasi mengurangi kebutuhan mencatat langkah, tetapi tidak mengurangi kebutuhan mencatat cakupan, batas, hasil pada versi tertentu, dan sisa risiko.

Salah paham 6: "Satu laporan yang bagus akan cocok untuk semua pembaca."

Kenapa terdengar masuk akal. Menulis satu dokumen jelas lebih hemat daripada menulis empat, dan mengulang isi terasa mubazir.

Di mana kelirunya. Empat pembaca mencari hal yang berbeda dari peristiwa yang sama. Laporan yang sempurna bagi pengembang — langkah paling pendek untuk memunculkan masalah, potongan log, pesan kesalahan — sering tidak menjawab pertanyaan pemilik produk sama sekali, karena ia perlu tahu dampaknya ke pengguna dan pilihan apa yang tersedia. Menyodorkan dokumen teknis lalu menyimpulkan bahwa pembacanya kurang paham teknis adalah salah alamat: yang keliru adalah pilihan bentuknya, bukan pembacanya.

Koreksinya. Tulis satu catatan rinci sebagai sumber utama, lalu turunkan ringkasan pendek berisi cakupan, batas, sisa risiko, dan rekomendasi untuk pembaca yang mengambil keputusan. Keduanya saling menunjuk, sehingga pemeriksa dari luar tetap bisa menelusuri dari ringkasan ke rincian.

Benang merahnya

Kelima salah paham pertama membuat catatan kehilangan isi yang menentukan; yang keenam membuat isi yang benar salah alamat. Keduanya berujung sama: dokumen ada, tetapi keputusan tetap tidak bisa diambil.

Untuk apa dokumentasi pengujian ada di tempat kerjamu

Sampai di sini kamu sudah melihat kasus orang lain. Unit ini membalik arahnya: sekarang bahannya adalah tempat kerjamu sendiri, dengan segala keterbatasannya yang nyata — waktu yang sempit, tim yang kecil, atasan yang tidak membaca dokumen panjang, atau justru sebaliknya, prosedur yang menuntut banyak kolom tetapi tidak menuntut isi.

Hasil akhir unit ini satu paragraf. Pendek, tetapi tidak mudah, karena paragraf ini harus spesifik untuk situasimu dan bisa diperiksa benar-salahnya.

Langkah 1: Petakan keputusan yang nyata di timmu

Tuliskan dua sampai tiga keputusan yang benar-benar diambil di tempat kerjamu, bukan yang seharusnya diambil menurut buku. Contoh bentuknya:

• "Setiap Kamis sore, pemilik produk memutuskan fitur mana yang ikut rilis Jumat."
• "Kalau ada laporan pengguna masuk, ketua tim memutuskan apakah perlu perbaikan darurat malam itu juga."
• "Sebelum tagihan bulanan ke klien, tim harus menunjukkan bahwa modul yang dijanjikan sudah diuji."

Untuk tiap keputusan, tulis satu kalimat: informasi apa yang selama ini paling sering tidak tersedia saat keputusan itu diambil?

Langkah 2: Kenali pembaca yang benar-benar ada

Empat peran yang kita bahas — penguji lain, pengembang, pemilik produk, pemeriksa dari luar tim — tidak selalu berupa empat orang berbeda. Di tim kecil, satu orang bisa memegang tiga peran sekaligus; di tempat lain, peran pemeriksa luar baru muncul setahun sekali saat ada audit atau saat klien meminta bukti.

Tuliskan untuk timmu:

Kalau ada baris yang kosong, tulis "belum ada" — itu jawaban yang sah dan penting. Peran yang belum ada hari ini sering muncul mendadak, dan catatan yang dibuat sekarang menentukan apakah kamu siap saat itu terjadi.

Langkah 3: Tulis paragrafnya

Satu paragraf, sekitar lima sampai delapan kalimat, yang menjawab: untuk apa dokumentasi pengujian ada di tempat kerjaku? Paragraf ini harus memuat, dalam bahasamu sendiri:

1. Keputusan konkret yang ditopang, berikut siapa yang mengambilnya.
2. Pembaca yang paling sering dilayani, dan kapan.
3. Satu hal yang selama ini paling sering hilang saat dibutuhkan.
4. Batas yang jujur: apa yang tidak akan kamu kejar, mengingat waktu dan tenaga yang ada.

Contoh yang lemah

"Dokumentasi pengujian penting untuk menjaga kualitas produk dan memastikan semua fitur berfungsi dengan baik. Dengan dokumentasi yang lengkap dan terstruktur, tim dapat bekerja lebih efektif dan efisien serta meningkatkan kepercayaan pengguna."

Paragraf ini tidak salah, tetapi tidak berguna. Ia bisa ditempelkan di tim mana pun tanpa mengubah satu kata, tidak menyebut keputusan apa pun, tidak menyebut pembaca, dan tidak bisa diperiksa benar-salahnya. Kalau paragrafmu masih bisa dipindahkan utuh ke perusahaan lain, ia belum selesai.

Contoh yang lebih kuat

"Di tim kami yang berisi empat orang, keputusan rilis diambil ketua tim setiap Jumat siang, biasanya dalam waktu kurang dari sepuluh menit. Yang paling sering tidak ia miliki adalah gambaran bagian mana yang belum sempat diuji, karena laporan kami selalu berupa daftar yang lulus. Karena itu dokumentasi pengujian di tim kami ada terutama untuk satu hal: membuat batas pengujian terlihat sebelum rilis, bukan setelah ada keluhan. Pembaca utamanya ketua tim, dan pembaca keduanya adalah kami sendiri saat harus menguji ulang perbaikan minggu berikutnya. Klien korporat kami mulai meminta bukti pengujian per modul sejak kontrak diperbarui, jadi catatan itu harus bisa dibaca tanpa penjelasan lisan dari saya. Dengan waktu yang ada, saya tidak akan mengejar dokumen rencana pengujian yang formal; yang saya kejar adalah catatan singkat per rilis berisi cakupan, batas, hasil, dan sisa risiko."

Paragraf ini menyebut siapa, kapan, apa yang hilang, dan apa yang sengaja dilepaskan. Ia bisa diperdebatkan oleh rekan setimmu — dan itu justru tandanya ia bermakna.

Daftar periksa paragrafmu

• [ ] Ada minimal satu keputusan konkret, bukan "menjaga kualitas".
• [ ] Ada nama peran pembaca, bukan "semua pihak terkait".
• [ ] Ada satu informasi yang selama ini hilang, disebut spesifik.
• [ ] Ada batas yang jujur tentang apa yang tidak dikejar.
• [ ] Tidak bisa dipindahkan utuh ke perusahaan lain tanpa terasa janggal.

Kalau kamu belum bekerja di tim penguji

Pakai konteks terdekat yang kamu punya: tugas kelompok, proyek pribadi yang dipakai orang lain, atau pekerjaan sebelumnya di bidang lain yang punya alur persetujuan. Yang dilatih di sini bukan pengalaman kerjanya, melainkan kemampuan mengaitkan catatan dengan keputusan. Kaitan itu berlaku di mana saja.

Kuis: mengambil keputusan dengan catatan yang ada

Apa yang diuji di sini

Kuis ini tidak menanyakan definisi dan tidak meminta kamu mengingat kembali kasus 3.7.0. Keempat soal memakai situasi baru yang belum pernah muncul di unit mana pun. Yang diukur adalah apakah kamu bisa memakai cara berpikir dari modul ini pada bahan yang asing.

Petunjuk pengerjaan

1. Ada empat soal pilihan ganda, masing-masing satu jawaban paling tepat.
2. Tidak ada batas waktu. Perkiraan wajar sekitar sepuluh menit.
3. Baca kasusnya sampai habis sebelum melihat pilihan jawaban. Kebiasaan membaca opsi lebih dulu membuatmu memilih yang paling familiar, bukan yang paling tepat.
4. Untuk tiap soal, sebelum memilih, jawab dulu dua pertanyaan ini untuk dirimu sendiri:
   - Keputusan apa yang sedang dipertaruhkan di situasi ini, dan siapa yang harus mengambilnya?
   - Informasi apa yang dibutuhkan orang itu supaya keputusannya bisa diambil?
   Kalau kamu bisa menjawab keduanya, pilihan yang tepat biasanya sudah terbentuk sebelum kamu membaca opsinya.
5. Setelah memilih, tulis satu kalimat alasanmu di kertas atau catatan sebelum membuka pembahasan. Ini penting: tanpa alasan tertulis, kamu tidak bisa membedakan jawaban yang benar karena paham dari jawaban yang benar karena beruntung.

Cara membaca pembahasannya

Setiap pembahasan menjelaskan kenapa satu pilihan tepat dan kesalahan berpikir apa yang diwakili oleh tiga pilihan lainnya. Bagian kedua itu yang lebih berharga. Ketiga pengecoh di setiap soal diambil dari cara berpikir yang benar-benar sering muncul di tim perangkat lunak — kemungkinan besar salah satunya pernah kamu pakai sendiri.

Kalau alasan yang kamu tulis ternyata berbeda dari pembahasan meskipun jawabanmu benar, perlakukan itu sebagai soal yang salah. Yang dilatih di modul ini cara menalarnya, bukan hurufnya.

Standar kelulusan mandiri

Tidak ada nilai minimum yang mengikat. Ukuran yang lebih berguna: kamu bisa menjelaskan tiap jawaban kepada rekan kerja tanpa membuka materi ini lagi. Kalau ada satu soal yang belum sampai ke titik itu, kembali ke unit yang membahasnya sebelum lanjut ke modul berikutnya — soal yang menyangkut cakupan dan batas dibahas di unit kuliah dan studi kasus, sedangkan soal yang menyangkut perbedaan pembaca dibahas di unit kuliah dan unit miskonsepsi.

Setelah selesai

Ambil satu soal yang paling dekat dengan situasi di tempat kerjamu, lalu tanyakan: kalau kejadian itu benar-benar terjadi minggu depan di timku, apakah catatan yang ada sekarang cukup untuk mengambil keputusannya? Jawabanmu atas pertanyaan itu akan berguna saat kamu masuk ke modul berikutnya.

Rangkuman dan daftar periksa

Yang sudah kita bangun

Modul ini berangkat dari satu kejadian yang sederhana: pertanyaan "sudah dites belum?" pada waktu yang mendesak, dijawab dengan kesimpulan tanpa dasar. Dari situ kita menurunkan seluruh isi modul.

Satu gagasan besar. Dokumentasi pengujian adalah alat pengambilan keputusan, bukan arsip dan bukan pekerjaan administratif. Semua pertanyaan praktis tentang dokumentasi — sedetail apa, sepanjang apa, dalam bentuk apa — dijawab dengan bertanya balik: keputusan apa yang sedang ditopang, dan siapa yang mengambilnya.

Empat isi yang membuat catatan bisa dipakai. Cakupan (apa yang benar-benar dijalankan), batas (apa yang tidak diuji dan kenapa), hasil beserta buktinya seperlunya, serta sisa risiko dan rekomendasi. Di atasnya ada penanda konteks yang menentukan makna seluruh catatan: nomor build atau versi, lingkungan, data uji, tanggal, dan pelaksana.

Batas lebih menentukan daripada daftar yang lulus. Pernyataan "semua lulus" hanya berkata bahwa di wilayah yang diperiksa tidak ditemukan masalah. Yang dibutuhkan pengambil keputusan adalah gambaran wilayah yang belum diperiksa. Menuliskan batas bukan pengakuan kelemahan; ia memindahkan keputusan risiko ke tangan orang yang memang berwenang menanggungnya.

Bukti dari studi kasus. Pada rilis rekaan 3.7.0, lima keputusan berbeda macet karena hal yang sama. Yang hilang bukan alat, bukan templat, bukan tangkapan layar, melainkan cakupan, batas, dan penanda konteks. Catatan lima belas baris tidak akan mencegah cacatnya, tetapi akan membuat kelima keputusan itu mungkin diambil.

Empat pembaca, empat pertanyaan. Penguji lain bertanya "bisakah saya mengulangnya?" dan butuh langkah, data, serta lingkungan. Pengembang bertanya "di mana ini rusak?" dan butuh langkah terpendek yang memunculkan masalah, harapan versus kenyataan, dan versi. Pemilik produk bertanya "apa akibatnya bagi pengguna dan apa pilihan saya?" dan butuh dampak, frekuensi, sisa risiko, serta konsekuensi tiap pilihan. Pemeriksa dari luar tim bertanya "bisakah saya memastikan ini tanpa bertanya kepada penulisnya?" dan butuh catatan yang berdiri sendiri dan terikat pada versi tertentu.

Enam salah paham yang perlu dijaga. Dokumentasi sebagai pekerjaan sisa; tidak menulis apa-apa saat semua lulus; obrolan grup dianggap arsip; panjang disamakan dengan berguna; otomasi dianggap menggantikan catatan; dan satu laporan dipaksa melayani semua pembaca.

Daftar periksa mandiri sebelum lanjut

Gunakan daftar ini pada dirimu sendiri, bukan pada tim yang ideal. Kalau ada butir yang belum tercentang, kembali ke unit yang disebutkan.

Pemahaman

• [ ] Saya bisa menjelaskan dalam satu kalimat kenapa dokumentasi pengujian disebut alat pengambilan keputusan. (Unit 2)
• [ ] Saya bisa menyebutkan empat isi catatan pengujian tanpa membuka materi. (Unit 2)
• [ ] Saya bisa menjelaskan kenapa "semua kasus lulus" bukan informasi yang cukup untuk memutuskan rilis. (Unit 2, 3)

Penerapan

• [ ] Saya sudah mengambil satu rilis nyata dari pekerjaan saya dan mengisi tabel bedah: keputusan, informasi yang dibutuhkan, yang tersedia, yang hilang. (Unit 3)
• [ ] Untuk minimal satu keputusan di tabel itu, saya bisa menunjuk dengan tepat informasi mana yang absen. (Unit 3)

Pembedaan pembaca

• [ ] Saya sudah mengisi tabel empat peran dengan nama orang atau pihak yang nyata di tempat kerja saya, termasuk menandai peran yang belum ada. (Unit 5)
• [ ] Saya bisa menyebutkan satu informasi yang penting bagi pengembang tetapi tidak menolong pemilik produk, dan sebaliknya. (Unit 2, 4)

Rumusan pribadi

• [ ] Paragraf saya menyebut minimal satu keputusan konkret berikut pengambilnya. (Unit 5)
• [ ] Paragraf saya menyebut satu informasi yang selama ini paling sering hilang. (Unit 5)
• [ ] Paragraf saya memuat batas yang jujur tentang apa yang tidak akan saya kejar. (Unit 5)
• [ ] Paragraf saya tidak bisa dipindahkan utuh ke perusahaan lain tanpa terasa janggal. (Unit 5)

Kuis

• [ ] Saya bisa menjelaskan alasan tiap jawaban kepada rekan kerja tanpa membuka materi ini. (Unit 6)
• [ ] Untuk soal yang saya jawab keliru, saya sudah tahu kesalahan berpikir mana yang saya pakai. (Unit 6)

Yang menunggu di modul berikutnya

Modul ini sengaja tidak memberimu templat. Alasannya sekarang mudah dilihat: templat yang diisi tanpa memahami keputusan yang ditopangnya menghasilkan dokumen tebal yang tidak menolong siapa pun, dan justru menumbuhkan rasa aman yang keliru.

Setelah kamu bisa menyebut keputusan dan pembacanya, barulah bentuk dokumen menjadi pertanyaan yang layak dijawab. Modul berikutnya masuk ke sana: menentukan cakupan dan batas secara sengaja sejak sebelum pengujian dimulai, lalu menuangkannya dalam bentuk yang bisa dipakai berulang tanpa membengkak.

Satu hal yang bisa kamu bawa mulai besok, tanpa menunggu modul mana pun: pada rilis berikutnya, tuliskan satu baris tentang apa yang tidak kamu uji dan kenapa. Satu baris itu biasanya yang paling banyak mengubah keadaan.