Modul 1 — Modul 1 — Mengapa Uji Otomatis Ada, dan Kapan Ia Justru Merugikan

Empat hari yang tidak ada yang menyadari

Bayangkan kamu bekerja di tim perangkat lunak sebuah distributor bahan pangan. Sebut saja PT Anugerah Pangan — perusahaan ini rekaan, dibuat khusus untuk kelas ini, tetapi kejadiannya jenis yang berulang di mana-mana. Perusahaan itu punya aplikasi internal bernama Pesanan Grosir: pelanggan warung dan rumah makan memesan barang per karton, sistem menghitung potongan harga, lalu menerbitkan tagihan.

Aturan potongannya sederhana dan sudah dipakai bertahun-tahun:

Pelanggan berstatus mitra binaan mendapat tambahan 2% di atas potongan itu.

Pada 12 Agustus, tim merilis perubahan agar status mitra binaan bisa dipakai di seluruh kanal pemesanan. Perubahannya dianggap kecil. Kode fungsi potongan dirapikan sekalian. Rilis lolos peninjauan kode, lolos pemeriksaan manual penguji, dan naik ke produksi tanpa ada yang mengangkat alis.

Empat hari kemudian, 16 Agustus, seorang staf keuangan menelepon. Ia sedang merekonsiliasi tagihan dan menemukan pola aneh: pesanan tepat 20 karton ditagih tanpa potongan sama sekali, dan pesanan tepat 50 karton ditagih dengan potongan 5%, bukan 8%. Pesanan 21 karton baik-baik saja. Pesanan 51 karton baik-baik saja. Hanya yang persis di angka batas yang salah.

Setelah ditelusuri, 187 pesanan terdampak, dengan total selisih tagihan Rp 23.750.000. Sebagian pelanggan sudah membayar. Sebagian sudah komplain ke tim penjualan dan tidak dijawab karena tim penjualan mengira sistem tidak mungkin salah. Insiden itu diberi nomor INS-2311.

Pertanyaan yang sebenarnya

Refleks pertama banyak orang setelah membaca cerita seperti ini adalah: "berarti tim itu kurang tes." Refleks itu terlalu cepat, dan menuntun ke keputusan yang mahal.

Pertanyaan yang lebih berguna ada tiga, dan modul ini memutar seluruh isinya di sekitar tiga pertanyaan itu:

1. Uji seperti apa, tepatnya, yang akan menangkap cacat INS-2311 sebelum rilis? Bukan "uji yang lebih banyak" — uji yang mana, di lapisan mana, dengan data apa.
2. Apakah uji semacam itu layak dipelihara? Setiap uji otomatis adalah kode tambahan yang harus ikut diperbaiki setiap kali sistem berubah. Sebagian uji membayar kembali biaya itu berlipat-lipat. Sebagian lagi tidak pernah balik modal.
3. Bagaimana kamu memutuskan hal itu di tempat kerjamu sendiri, untuk fitur yang kamu pegang sekarang, tanpa harus menunggu insiden lebih dulu?

Kenapa modul ini bukan modul "otomatiskan semuanya"

Banyak materi pengujian ditulis seolah otomasi adalah kewajiban moral: tim yang baik mengotomatiskan, tim yang malas tidak. Cara pandang itu menghasilkan tim yang punya ratusan uji, dua pertiganya sering merah tanpa sebab jelas, dan akhirnya tidak ada yang membaca hasilnya lagi. Suite semacam itu lebih buruk daripada tidak punya suite sama sekali, karena ia memakan waktu sekaligus memberi rasa aman palsu.

Otomasi adalah keputusan ekonomi: kamu menukar biaya sekarang (menulis dan merawat kode uji) dengan pengurangan risiko di masa depan (cacat yang tertangkap lebih cepat, lebih murah). Kadang tukar-menukar itu jelas menguntungkan. Kadang jelas merugikan. Sebagian besar waktu, ia ada di antaranya, dan itulah kenapa kamu perlu kriteria, bukan slogan.

Peta modul ini

Unit 2 membedah biaya dan manfaat sebuah uji otomatis, lalu memberimu lima pertanyaan kelayakan dan empat pola pekerjaan yang biasanya merugi bila diotomatiskan. Unit 3 menjelaskan lima langkah mengubah satu insiden produksi menjadi uji regresi yang benar-benar mengunci cacatnya. Unit 4 menerapkan kelima langkah itu pada INS-2311 sampai selesai, lengkap dengan kode uji dan angkanya. Unit 5 mengoreksi lima salah paham yang paling sering. Unit 6 kuis, unit 7 rangkuman dan daftar periksa sebelum kamu lanjut.

Satu hal yang perlu kamu siapkan sejak sekarang: pilih satu fitur nyata yang kamu pegang atau kamu kenal baik di tempat kerjamu. Kamu akan memakainya di akhir modul.

Sebuah uji otomatis tidak pernah gratis

Orang cenderung menghitung biaya uji otomatis hanya sampai "waktu menulisnya". Padahal biaya itu punya empat komponen, dan yang paling sering diremehkan justru bukan yang pertama.

Biaya pertama: menulis. Dibayar sekali. Ini yang paling terlihat dan paling mudah diperkirakan.

Biaya kedua: menjalankan. Kecil per satuan, tetapi dibayar setiap kali. Suite yang butuh dua puluh menit mengubah kebiasaan tim: orang menumpuk perubahan agar tidak menunggu berkali-kali, dan menumpuk perubahan membuat penyebab kegagalan lebih sulit dilacak. Biaya ini bukan cuma tagihan server, melainkan waktu tunggu manusia.

Biaya ketiga: merawat. Dibayar setiap kali sistem berubah. Inilah komponen yang membunuh suite besar. Uji yang terikat pada tata letak halaman harus diperbaiki setiap kali desain berganti. Uji yang terikat pada struktur basis data harus diperbaiki setiap kali skema bergeser. Uji yang terikat pada aturan bisnis hanya perlu diperbaiki bila aturan bisnisnya memang berubah — dan itu jauh lebih jarang.

Biaya keempat: salah alarm. Uji yang merah padahal produk baik-baik saja. Satu-dua kali masih ditoleransi. Setelah kesekian kali, orang mulai menjalankan ulang sampai hijau, lalu berhenti membaca hasilnya sama sekali. Pada titik itu kamu masih membayar biaya satu sampai tiga, tetapi manfaatnya sudah nol. Suite yang tidak dipercaya adalah utang murni.

Manfaatnya cuma satu, tapi besar

Uji otomatis tidak membuat perangkat lunakmu benar. Ia memperpendek jarak antara saat kesalahan dibuat dan saat kesalahan diketahui.

Itu saja manfaatnya, dan justru di situ nilainya. Kesalahan yang ketahuan tiga menit setelah ditulis diperbaiki oleh orang yang masih ingat konteksnya, tanpa rapat, tanpa surat permintaan maaf ke pelanggan. Kesalahan yang sama, ketahuan empat hari kemudian lewat telepon dari bagian keuangan, menyeret penelusuran data, koreksi tagihan, dan kepercayaan yang harus dibangun ulang.

Jadi nilai sebuah uji kira-kira ditentukan oleh tiga hal yang saling dikalikan: seberapa besar peluang ia benar-benar menangkap cacat, seberapa mahal cacat itu bila lolos, dan seberapa sering uji itu dijalankan. Kalau salah satu faktornya mendekati nol, hasilnya mendekati nol — betapapun rapinya uji itu ditulis. Ini kerangka berpikir untuk menimbang, bukan rumus yang bisa kamu isi angka lalu percayai hasilnya.

Titik impas sebuah uji tercapai ketika kerugian yang ia cegah melampaui jumlah keempat biaya tadi. Uji atas aturan yang stabil dan mahal bila salah biasanya balik modal dalam hitungan minggu. Uji atas tampilan yang masih dirombak tiap sprint sering tidak pernah balik modal, karena biaya rawatnya dibayar terus sementara aturan yang dijaganya belum menetap.

Lima pertanyaan kelayakan otomasi

Untuk setiap pekerjaan pengujian, tanyakan lima hal berikut. Jawablah per pekerjaan, bukan per tim atau per proyek.

1. Frekuensi. Berapa kali pekerjaan ini akan diulang dalam setahun? Sekali, atau setiap kali ada rilis?
2. Stabilitas aturan. Seberapa sering aturan yang diuji berubah? Perhatikan: yang penting umur aturannya, bukan umur tampilannya di layar. Halaman promo bisa dibongkar tiap bulan sementara rumus potongannya bertahan bertahun-tahun.
3. Nilai risiko. Kalau cacat ini lolos, siapa yang rugi dan berapa besar? Salah hitung uang, salah hak akses, dan kehilangan data ada di kelas paling mahal.
4. Keterujian. Bisakah mesin memutuskan lulus atau gagal tanpa manusia menafsirkan hasilnya? Kalau kriteria lulusnya "tampilannya enak dilihat", mesin tidak bisa membantumu.
5. Biaya rawat. Setiap kali sistem berubah, berapa besar kemungkinan uji ini ikut harus diubah padahal perilaku produk tidak berubah?

Jawaban "ya" pada nomor 1–4 dan "kecil" pada nomor 5 adalah kandidat otomasi yang kuat. Kombinasi lain perlu dipikirkan.

Empat pola pekerjaan yang biasanya merugi bila diotomatiskan

1. Pemeriksaan sekali pakai. Verifikasi migrasi data yang hanya dijalankan satu malam. Menulis skrip cepat boleh; menjadikannya bagian suite permanen tidak ada gunanya.
2. Penilaian yang butuh mata manusia. Apakah susunan formulir membingungkan, apakah kalimat galat sopan, apakah warna kontrasnya nyaman. Mesin bisa memeriksa hal yang bisa dirumuskan, bukan hal yang harus dirasakan.
3. Fitur yang aturannya masih berubah tiap minggu. Selama tim masih bereksperimen dengan aturannya, uji yang dituliskan hari ini adalah uji yang dibuang minggu depan.
4. Alur yang bergantung pada sistem luar tak terkendali dan tidak menyediakan lingkungan uji. Uji semacam ini gagal karena hal-hal di luar kodemu, dan itu pabrik salah alarm.

Perhatikan bahwa keempat pola ini tidak berkata "jangan menguji". Mereka berkata: pengujiannya tetap dilakukan, hanya saja oleh manusia, sekali, atau dengan cara lain.

Dari "sudah diperbaiki" ke "tidak akan terulang"

Setelah insiden ditambal, godaan terbesar adalah menutup tiketnya dan pindah ke pekerjaan berikutnya. Padahal insiden adalah bahan mentah paling berharga yang bisa dimiliki tim penguji: ia memberitahumu, dengan bukti, di mana asumsimu meleset. Uji regresi adalah cara mengubah pelajaran itu menjadi sesuatu yang bekerja terus tanpa harus diingat orang.

Berikut lima langkah untuk melakukannya. Unit 4 akan menjalankan kelima langkah ini dari awal sampai akhir pada INS-2311.

Langkah 1 — Tetapkan fakta insiden

Sebelum menulis satu baris uji pun, tuliskan empat hal secara harfiah: apa yang terjadi, apa yang seharusnya terjadi, sejak kapan, dan siapa yang terdampak. Tulis dalam kalimat yang bisa diperiksa benar-salahnya, bukan kesan umum.

"Perhitungan potongan bermasalah" bukan fakta, itu kesan. "Pesanan 20 karton non-mitra ditagih dengan potongan 0%, seharusnya 5%" adalah fakta. Perbedaannya menentukan segalanya: dari kalimat kedua kamu bisa langsung menurunkan uji, dari kalimat pertama tidak.

Langkah ini juga tempat kamu memisahkan gejala dari cacat. Gejalanya adalah tagihan yang salah. Cacatnya ada di satu perbandingan di dalam fungsi harga. Uji regresi harus mengunci cacatnya; kalau kamu hanya menguji gejalanya lewat tagihan akhir, uji itu akan ikut merah setiap kali format tagihan berubah.

Langkah 2 — Persempit jadi pemicu terkecil

Cari masukan paling kecil yang masih menghasilkan kegagalan. Buang semuanya yang tidak perlu: pelanggan tertentu, tanggal tertentu, isi keranjang yang panjang, status pembayaran. Terus buang sampai satu potongan lagi membuat kegagalannya hilang.

Hasilnya biasanya mengejutkan sederhana — dan justru itu gunanya. Pemicu terkecil memberitahumu di lapisan mana cacat itu sebenarnya hidup. Kalau cacat tetap muncul dengan memanggil satu fungsi dan tiga angka, maka cacat itu hidup di fungsi, bukan di antarmuka, bukan di basis data.

Langkah 3 — Pilih lapisan tempat uji dipasang

Kamu punya beberapa lapisan, dari yang murah dan sempit sampai yang mahal dan luas:

• Uji unit memanggil satu fungsi atau kelas secara langsung. Milidetik, sangat spesifik, murah dirawat. Tidak membuktikan bagian-bagiannya tersambung benar.
• Uji integrasi menguji beberapa komponen bersama, misalnya lapisan layanan sampai basis data. Lebih lambat, menangkap kesalahan penyambungan.
• Uji kontrak memeriksa bahwa bentuk data yang dipertukarkan dengan pihak lain masih sesuai kesepakatan.
• Uji ujung-ke-ujung menjalankan sistem seperti pengguna sungguhan. Paling meyakinkan, paling lambat, paling mahal dirawat, dan paling sering memberi salah alarm.

Aturan praktisnya: pasang uji di lapisan terendah yang masih bisa menangkap cacat itu, lalu tambahkan satu uji tipis di lapisan lebih tinggi kalau risiko penyambungannya nyata. Susunan berlapis semacam ini — banyak uji cepat di bawah, sedikit uji lambat di atas — biasa digambarkan sebagai piramida uji; gambaran itu dipopulerkan Mike Cohn.

Ada satu jebakan yang perlu kamu ketahui sekarang. Untuk memisahkan diri dari sistem luar, kita sering memakai tiruan (mock): objek palsu yang berpura-pura menjadi layanan pihak ketiga. Tiruan memberi kecepatan dengan satu harga besar: ia membekukan asumsimu tentang pihak luar itu. Kalau penyedia mengubah format responsnya, semua ujimu tetap hijau sementara produksimu rusak. Risiko itu hanya bisa dijaga oleh uji yang secara berkala menghadapkan kodemu pada respons penyedia yang sebenarnya — misalnya uji terjadwal terhadap lingkungan uji milik penyedia — bukan oleh menambah uji bertiruan yang lain.

Langkah 4 — Tulis uji yang gagal dulu

Tulis ujinya, jalankan pada kode sebelum perbaikan, dan pastikan ia merah. Ini bukan formalitas.

Uji yang belum pernah kamu lihat gagal adalah uji yang belum terbukti bisa gagal. Sangat mudah menulis uji yang selalu hijau karena salah memanggil fungsi, salah menyiapkan data, atau memeriksa hal yang tidak ada hubungannya. Melihatnya merah dulu, lalu hijau setelah perbaikan, adalah satu-satunya bukti murah bahwa uji itu benar-benar mengawasi cacat yang kamu maksud.

Urutannya: tulis uji → lihat merah → terapkan perbaikan → lihat hijau → kembalikan sementara perbaikannya untuk memastikan merah lagi bila kamu ingin sangat yakin.

Langkah 5 — Perluas ke kelas cacat, bukan ke satu kejadian

Insiden memberimu satu titik. Cacat hampir tidak pernah sendirian; ia anggota sebuah kelas. Kalau yang salah adalah perlakuan di satu nilai batas, maka semua nilai batas lain dalam aturan yang sama patut dicurigai.

Jadi setelah ujimu hijau untuk kasus yang dilaporkan, perluas dengan pola berikut: untuk setiap ambang dalam aturan, uji nilai tepat di ambang, satu di bawahnya, dan satu di atasnya. Tambahkan juga kombinasi dengan status khusus yang berlaku, karena insiden sering muncul dari persilangan dua aturan yang masing-masing benar sendirian.

Berhentilah ketika penambahan kasus baru tidak lagi menambah kemungkinan menemukan sesuatu — misalnya menguji 5.000 karton setelah 51 karton sudah diuji. Uji tambahan yang tidak menambah peluang menangkap cacat hanya menambah tiga dari empat biaya di unit 2.

Bahan yang kita punya

Kita kerjakan kelima langkah dari unit 3 pada insiden INS-2311 di aplikasi Pesanan Grosir milik PT Anugerah Pangan. Semua data di bawah ini rekaan untuk latihan, tetapi bentuk kasusnya khas.

Harga satuan yang dipakai dalam contoh ini: Rp 240.000 per karton.

Langkah 1 — Tetapkan fakta insiden

Mari periksa angkanya untuk satu pesanan agar cacatnya terasa nyata. Pesanan 50 karton non-mitra: subtotal 50 × Rp 240.000 = Rp 12.000.000. Seharusnya potongan 8% = Rp 960.000, tagihan Rp 11.040.000. Yang terjadi: potongan 5% = Rp 600.000, tagihan Rp 11.400.000. Selisih Rp 360.000 untuk satu pesanan saja.

Untuk pesanan 20 karton non-mitra: subtotal Rp 4.800.000, seharusnya potongan 5% = Rp 240.000 sehingga tagihan Rp 4.560.000; yang terjadi tagihan penuh Rp 4.800.000. Selisih Rp 240.000.

Gejala di sini adalah tagihan yang salah. Cacatnya ada di kode penentu tingkat potongan. Uji regresi kita akan mengunci cacatnya.

Langkah 2 — Persempit jadi pemicu terkecil

Laporan awal datang lengkap dengan nomor pesanan, nama pelanggan, tanggal, dan isi keranjang berisi sebelas jenis barang. Kita buang satu per satu:

• Ganti pelanggan asli dengan pelanggan mana pun → tetap gagal.
• Ganti tanggal → tetap gagal.
• Ringkas keranjang jadi satu jenis barang → tetap gagal.
• Kurangi jumlah dari 50 jadi 49 → hijau. Naikkan ke 51 → hijau. Tepat 50 → gagal.

Pemicu terkecilnya: jumlah karton bernilai tepat sama dengan ambang. Tidak butuh basis data, tidak butuh antarmuka, tidak butuh sesi login. Setelah dilihat kodenya, penyebabnya satu karakter: perbandingan >= berubah menjadi > saat fungsi dirapikan, sehingga nilai tepat di ambang jatuh ke tingkat di bawahnya.

Langkah 3 — Pilih lapisan tempat uji dipasang

Karena pemicu terkecil hanya butuh sebuah fungsi dan beberapa angka, lapisan yang tepat adalah uji unit pada fungsi penghitung tagihan. Uji ujung-ke-ujung lewat antarmuka pemesanan juga akan menangkapnya, tetapi butuh menyiapkan pelanggan, sesi, dan katalog; lebih lambat, lebih mahal dirawat, dan akan ikut merah setiap kali tampilan berubah.

Satu uji integrasi tipis tetap kita tambahkan: memastikan pembuat pesanan memanggil fungsi tagihan yang benar dengan status mitra yang benar. Cacat semacam "fungsi sudah benar tetapi tidak pernah dipanggil" tidak akan tertangkap oleh uji unit.

Langkah 4 — Tulis uji yang gagal dulu

Satu uji lebih dulu, dijalankan pada kode sebelum perbaikan:

from harga import hitung_tagihan

HARGA_KARTON = 240_000

def test_lima_puluh_karton_dapat_delapan_persen():
    assert hitung_tagihan(jumlah=50, harga_satuan=HARGA_KARTON, mitra=False) == 11_040_000

Jalankan. Hasilnya harus merah, dengan nilai sebenarnya 11.400.000 — persis selisih Rp 360.000 yang kita hitung di langkah 1. Kecocokan angka ini penting: ia membuktikan uji kita mengenai cacat yang sama dengan yang dilaporkan keuangan, bukan cacat lain.

Baru setelah itu perbaikan diterapkan (> dikembalikan menjadi >=), uji dijalankan lagi, dan hasilnya hijau.

Langkah 5 — Perluas ke kelas cacat

Aturan potongan punya dua ambang: 20 dan 50. Untuk tiap ambang kita uji nilai tepat di ambang, satu di bawahnya, dan satu di atasnya. Kita tambahkan pula satu kasus silang dengan status mitra binaan, karena insiden ini lahir justru dari perubahan yang berkaitan dengan status tersebut. Totalnya tujuh baris kasus:

import pytest
from harga import hitung_tagihan

HARGA_KARTON = 240_000

@pytest.mark.parametrize("jumlah, mitra, potongan_persen", [
    (19, False, 0),    # tepat di bawah ambang pertama
    (20, False, 5),    # tepat di ambang pertama — lolos pada INS-2311
    (21, False, 5),    # tepat di atas ambang pertama
    (49, False, 5),    # tepat di bawah ambang kedua
    (50, False, 8),    # tepat di ambang kedua — lolos pada INS-2311
    (51, False, 8),    # tepat di atas ambang kedua
    (50, True, 10),    # silang: mitra binaan tepat di ambang kedua
])
def test_potongan_pada_nilai_batas(jumlah, mitra, potongan_persen):
    subtotal = jumlah * HARGA_KARTON
    diharapkan = subtotal - (subtotal * potongan_persen) // 100
    assert hitung_tagihan(jumlah=jumlah, harga_satuan=HARGA_KARTON, mitra=mitra) == diharapkan

Baris terakhir memeriksa mitra binaan pada 50 karton: potongan 8% + 2% = 10%, sehingga tagihan Rp 10.800.000 dari subtotal Rp 12.000.000. Sebelum perbaikan, kode memberi 5% + 2% = 7%, yaitu Rp 11.160.000 — lagi-lagi selisih Rp 360.000.

Gagasan menguji nilai tepat di batas beserta tetangganya sudah lama menjadi bahan baku pengujian; pembahasan klasiknya bisa kamu temukan pada buku Myers yang dirujuk di bawah.

Di mana kita berhenti? Kita tidak menambahkan kasus 5.000 karton, karena 51 karton sudah mewakili seluruh wilayah di atas ambang kedua dan tidak ada aturan lain di sana. Menambahkannya hanya menambah biaya jalan dan biaya rawat tanpa menambah peluang menangkap cacat.

Uji timbang cepat dengan lima pertanyaan kelayakan

Frekuensi: dijalankan setiap kali kode harga berubah — tinggi. Stabilitas aturan: tingkat potongan grosir bertahan bertahun-tahun — tinggi. Nilai risiko: langsung menyangkut uang pelanggan — tinggi. Keterujian: hasilnya angka rupiah, mesin bisa memutuskan sendiri — jelas. Biaya rawat: uji hanya bergantung pada tanda tangan satu fungsi, bukan pada tampilan — rendah.

Kelima jawaban mengarah ke satu kesimpulan: uji ini termasuk yang paling menguntungkan yang bisa dimiliki tim tersebut. Perhatikan bahwa kesimpulan itu berasal dari sifat pekerjaannya, bukan dari fakta bahwa insidennya sudah terjadi.

Salah paham 1: "Cakupan kode 100% berarti bebas cacat"

Cakupan kode mengukur baris mana yang tersentuh saat uji berjalan, bukan apakah perilakunya benar. Keduanya sering dikira sama.

INS-2311 adalah contoh yang bersih. Anggap fungsi harga sudah diuji dengan pesanan 10, 30, dan 100 karton. Ketiga cabang tingkat potongan tersentuh, cakupannya penuh, dan tetap saja cacat batas lolos — karena tidak satu pun kasus itu bernilai tepat 20 atau tepat 50.

Cakupan berguna untuk satu hal: menemukan bagian yang sama sekali belum tersentuh. Sebagai target yang dikejar, ia mudah dipenuhi dengan uji yang menjalankan kode tanpa memeriksa apa pun yang berarti. Perlakukan cakupan sebagai lampu peringatan, bukan sebagai nilai rapor.

Salah paham 2: "Semua pengujian manual pada akhirnya harus diotomatiskan"

Kalimat ini terdengar seperti cita-cita profesional, padahal ia mengabaikan biaya rawat dari unit 2 dan keempat pola yang biasanya merugi.

Pemeriksaan verifikasi migrasi data yang hanya dijalankan satu malam tidak akan pernah balik modal sebagai uji permanen. Penilaian apakah kalimat pesan galat terasa menyalahkan pengguna tidak bisa diserahkan ke mesin, karena mesin tidak punya kriteria lulusnya. Fitur yang aturannya masih diubah tiap minggu akan membuatmu membuang uji yang baru ditulis.

Yang benar: setiap pekerjaan pengujian dinilai sendiri dengan lima pertanyaan kelayakan. Sebagian besar tim yang sehat punya campuran permanen antara uji otomatis dan pemeriksaan manual, dan itu bukan tanda ketertinggalan.

Salah paham 3: "Uji ujung-ke-ujung paling meyakinkan, jadi paling baik"

Bagian pertamanya benar. Uji ujung-ke-ujung memang paling mendekati pengalaman pengguna sungguhan. Kesimpulannya yang keliru.

Uji ujung-ke-ujung melintasi banyak lapisan sekaligus, sehingga ia paling sering ikut merah karena hal-hal yang bukan cacat: elemen halaman yang berganti nama, jaringan yang lambat, data uji yang tersisa dari eksekusi sebelumnya. Ia juga paling lambat memberi tahu kamu di mana kesalahannya, karena kegagalannya hanya berkata "alur ini gagal", bukan "fungsi ini menghitung salah".

Akibat praktisnya berbahaya: tim mulai menjalankan ulang uji yang merah sampai kebetulan hijau. Sejak saat itu suite tidak lagi berfungsi sebagai alarm. Pakailah uji ujung-ke-ujung dalam jumlah kecil untuk alur yang paling bernilai, dan pindahkan pemeriksaan aturan bisnis ke lapisan yang lebih rendah.

Salah paham 4: "Uji otomatis akan menemukan cacat baru"

Uji otomatis pada dasarnya menjaga yang sudah kamu ketahui. Ia berkata: perilaku yang pernah kita sepakati benar masih benar setelah perubahan hari ini. Ia tidak berkeliling mencari hal yang belum pernah terpikirkan.

Cacat baru ditemukan oleh manusia yang bertanya "bagaimana kalau…" — pengujian eksploratif, tinjauan aturan bisnis bersama pengguna, atau membaca kode dengan curiga. Bila pertanyaan itu menghasilkan temuan, barulah temuannya diubah menjadi uji otomatis supaya tidak perlu ditemukan dua kali.

Konsekuensinya untuk perencanaan: tim yang mengganti seluruh waktu eksplorasi dengan pekerjaan menulis skrip akan melihat jumlah cacat yang ditemukan sebelum rilis justru menurun, sementara jumlah insiden tidak ikut turun.

Salah paham 5: "Uji yang sering merah berarti uji yang ketat"

Ada dua sebab uji sering merah, dan artinya bertolak belakang.

Uji tajam merah karena produk memang salah. Setiap kali ia merah, ada yang perlu diperbaiki di kode produksi. Uji semacam ini berharga meskipun merepotkan.

Uji rapuh merah karena hal yang tidak ada hubungannya dengan kebenaran produk: urutan data yang berubah, waktu tunggu yang kurang, tanggal yang bergeser, atau pemilih elemen yang berganti. Setiap kali ia merah, yang diperbaiki adalah ujinya sendiri.

Cara membedakannya sederhana dan murah: untuk setiap kegagalan dalam sebulan terakhir, catat apa yang akhirnya diubah — kode produksi atau kode uji. Kalau hampir selalu kode uji yang diubah, kamu sedang membayar biaya rawat dan biaya salah alarm tanpa mendapat manfaat apa pun. Uji seperti itu perlu dipindah ke lapisan lebih rendah, ditulis ulang agar tidak bergantung pada hal yang mudah berubah, atau dihapus.

Cara mengerjakan

Kuis ini berisi empat soal pilihan ganda. Tidak satu pun menanyakan definisi atau meminta kamu mengingat angka dari unit sebelumnya. Semua soal memakai kasus yang belum pernah muncul di modul ini: tim lain, sistem lain, cacat yang berbeda bentuknya. Yang diuji adalah apakah kamu bisa memakai kerangka berpikir dari unit 2 sampai 4 pada situasi baru.

Sediakan waktu sekitar dua puluh menit tanpa gangguan. Jangan membuka unit sebelumnya sambil menjawab. Kalau kamu merasa perlu membuka, itu justru penanda berguna: catat unit mana yang kamu cari, karena itulah bagian yang perlu kamu baca ulang setelah selesai.

Cara memilih jawaban

Setiap soal menempatkanmu sebagai orang yang harus mengambil keputusan, bukan sebagai orang yang menilai benar-salah secara umum. Karena itu, lebih dari satu pilihan biasanya terdengar masuk akal. Yang dicari adalah pilihan yang paling baik menurut pertimbangan biaya dan manfaat dalam situasi yang digambarkan soal — bukan pilihan yang paling lengkap, paling teliti, atau paling banyak menambah uji.

Saran urutan berpikir untuk tiap soal:

1. Tentukan dulu apa cacat atau risikonya, dalam kalimat yang bisa diperiksa benar-salahnya. Kalau kamu belum bisa menuliskannya, kamu belum siap memilih.
2. Tanyakan lapisan terendah mana yang masih bisa menangkap risiko itu.
3. Perkirakan biaya rawatnya: setiap kali sistem berubah, seberapa besar kemungkinan pilihan itu ikut harus diubah padahal produk tidak berubah?
4. Baru bandingkan keempat opsi.

Setelah menjawab

Setiap soal punya pembahasan yang menjelaskan bukan hanya mengapa kunci itu benar, tetapi juga kesalahan berpikir apa yang diwakili masing-masing pengecoh. Bacalah seluruh pembahasan, termasuk untuk soal yang kamu jawab benar. Beberapa pengecoh di kuis ini adalah keputusan yang benar-benar sering diambil tim di lapangan dan tampak wajar di rapat; mengenali bentuknya lebih berguna daripada sekadar mendapat nilai penuh.

Kalau jawabanmu benar tetapi alasanmu berbeda dari pembahasan, perlakukan itu sebagai jawaban yang perlu ditinjau ulang. Menebak dengan benar dan menalar dengan benar terlihat sama di lembar nilai, tetapi hanya yang kedua yang bertahan saat kamu menghadapi kasus di pekerjaanmu sendiri.

Ambang

Tidak ada nilai kelulusan formal untuk kuis ini. Patokan praktisnya: bila kamu salah pada dua soal atau lebih, baca ulang unit 2 dan unit 3 sebelum masuk ke unit rangkuman, karena unit 7 akan meminta kamu mengambil keputusan serupa untuk fitur yang kamu pilih sendiri di tempat kerjamu.

Yang sudah kita bangun

Modul ini berangkat dari satu insiden dan berakhir pada satu kebiasaan berpikir.

Otomasi adalah keputusan ekonomi. Sebuah uji otomatis punya empat biaya: menulis (sekali), menjalankan (tiap kali, termasuk waktu tunggu manusia), merawat (tiap kali sistem berubah), dan salah alarm (dibayar dengan kepercayaan tim pada suitenya sendiri). Manfaatnya cuma satu, tetapi besar: memperpendek jarak antara saat kesalahan dibuat dan saat kesalahan diketahui. Nilai sebuah uji ditentukan oleh peluangnya menangkap cacat, kerugian bila cacat itu lolos, dan frekuensinya dijalankan — bila salah satu faktor mendekati nol, nilainya pun mendekati nol.

Kelayakan dinilai per pekerjaan dengan lima pertanyaan: frekuensi pengulangan, stabilitas aturan (bukan stabilitas tampilan), nilai risiko bila cacat lolos, keterujian oleh mesin tanpa tafsir manusia, dan biaya rawat tiap kali sistem berubah. Ada empat pola yang biasanya merugi bila diotomatiskan: pemeriksaan sekali pakai, penilaian yang butuh mata manusia, fitur yang aturannya masih berubah tiap minggu, dan alur yang bergantung pada sistem luar tanpa lingkungan uji. Keempatnya tetap diuji — hanya tidak dengan cara ini.

Insiden diubah menjadi uji regresi lewat lima langkah: tetapkan fakta insiden, persempit jadi pemicu terkecil, pilih lapisan tempat uji dipasang, tulis uji yang gagal dulu, lalu perluas ke kelas cacat. Pada INS-2311 kelima langkah itu membawa kita dari laporan bagian keuangan sampai ke tujuh baris kasus uji berparameter di lapisan unit — bukan ke suite ujung-ke-ujung yang mahal.

Lima salah paham yang paling mahal sudah dikoreksi: cakupan 100% bukan jaminan bebas cacat; tidak semua pemeriksaan manual perlu diotomatiskan; uji ujung-ke-ujung yang paling meyakinkan bukan berarti paling baik; uji otomatis menjaga yang sudah diketahui alih-alih menemukan yang baru; dan uji yang sering merah bisa berarti rapuh, bukan ketat.

Daftar periksa mandiri

Jawab enam butir berikut untuk fitur yang kamu pilih di unit 1. Tuliskan jawabannya, jangan hanya dipikirkan — modul berikutnya berangkat dari catatan ini.

1. Insiden. Aku bisa menuliskan satu kegagalan nyata atau yang sangat mungkin terjadi pada fitur ini, dalam kalimat yang bisa diperiksa benar-salahnya: apa yang terjadi, apa yang seharusnya, siapa yang rugi.
2. Pemicu terkecil. Aku tahu masukan paling sederhana yang akan membuat kegagalan itu muncul, dan aku sudah membuang semua data yang ternyata tidak berpengaruh.
3. Lapisan. Aku bisa menyebut lapisan terendah yang masih bisa menangkap kegagalan itu, dan bisa menjelaskan mengapa lapisan di atasnya tidak perlu.
4. Bukti merah. Aku tahu bagaimana caranya melihat uji ini gagal lebih dulu — misalnya dengan sementara mengembalikan kode ke keadaan cacat — sebelum aku memercayai warna hijaunya.
5. Kelas cacat. Aku sudah mendaftar seluruh ambang atau aturan sejenis pada fitur ini, dan menentukan nilai tepat di ambang beserta tetangganya yang perlu diuji.
6. Kelayakan. Aku sudah menjawab kelima pertanyaan kelayakan untuk pekerjaan ini, dan keputusanku — otomatiskan atau tidak — punya alasan yang bisa aku sampaikan ke rekan tim tanpa menyebut kata "praktik terbaik".

Kalau ada butir yang belum bisa kamu jawab, tandai nomornya. Butir 1 sampai 3 yang kosong biasanya berarti kamu perlu membaca ulang unit 3. Butir 6 yang kosong mengarah ke unit 2.

Bawa ini ke modul berikutnya

Satu hal yang layak kamu bawa keluar dari modul ini, bahkan bila kamu melupakan sisanya: uji yang baik bukan uji yang paling menyeluruh, melainkan uji yang paling murah dirawat di antara yang masih bisa menangkap kegagalan yang kamu takutkan.

Siapkan catatan daftar periksamu. Modul berikutnya akan memakai fitur yang sama dan turun ke tingkat yang lebih teknis: bagaimana menyusun uji agar tetap terbaca setelah setahun, bagaimana menyiapkan data uji tanpa membuat uji saling bergantung, dan bagaimana menjaga waktu jalan suite tetap pendek saat jumlah ujinya bertambah.

Selesai mengerjakan seluruh modul dan kuisnya, kamu berhak atas sertifikat penyelesaian untuk kelas ini.