Laporan QA Dua Lapis: Sesi Append-Only, Modul Living
Format laporan QA dua lapis: laporan sesi append-only log-as-you-go plus berkas modul living, dengan angka hanya dari artefak mesin.
Ringkasan
Jadi ceritanya, laporan pengujian sering nggak bisa dipercaya karena angkanya cuma diketik ulang dari ingatan, bukan dari bukti asli. Solusinya: catat sesi sambil jalan (append-only) plus berkas modul yang terus di-update, semua angka wajib dari artefak mesin. Hasilnya, 31 skenario keuji, temuan gampang dilacak balik, nggak ada lagi rekonstruksi di akhir hari.
Laporan pengujian yang ditulis ulang di akhir hari punya cacat yang sama berulang: angka dalam temuan tidak bisa dilacak balik. Bukti yang seharusnya berupa hasil kueri basis data atau respons jaringan berubah menjadi transkrip yang diketik ulang dari ingatan. Begitu lingkungan uji berganti dan data uji terhapus, mengulang skenario untuk memverifikasi satu temuan berarti menebak dari awal. Keputusan owner yang berlaku sekarang menutup celah itu dengan format tetap: laporan sesi append-only dan berkas modul living. Formatnya dikodifikasi di README pengujian, sehingga tiap sesi manual maupun eksploratif tunduk pada struktur yang sama tanpa negosiasi ulang di awal sesi.
Lapis pertama: laporan sesi log-as-you-go
Laporan sesi dibuat di awal sesi dan diisi saat setiap langkah dieksekusi, bukan direkonstruksi di akhir. Strukturnya wajib lengkap: metadata sesi memuat tanggal, branch dan commit HEAD, environment beserta status containernya, akun uji, dan metode. Matriks skenario memberi ID unik untuk tiap kasus, misalnya L-1 untuk login valid atau C-3 untuk kasus CRUD, lengkap dengan URL tepat, langkah reproduce bernomor yang cukup detail untuk dijalankan orang lain, expected versus actual, status, dan bukti. Satu baris matriks dari sesi nyata memuat nama berkas screenshot sebagai bukti, sehingga klaim status PASS selalu punya lampiran yang bisa dibuka, bukan perkataan tanpa lampiran. Koreksi tidak boleh mengedit baris lama; ia masuk sebagai baris baru bertanda.
Bagian temuan memakai ID berurut seperti R4-1 sampai R4-5, tiap temuan membawa severity, lokasi kode sampai nomor baris, bukti mesin, dampak, dan opsi keputusan. Ledger data uji mencatat setiap record atau media yang dibuat, diubah, dan dihapus, dengan bukti kueri basis data; cleanup harus terbukti, bukan diklaim. Bagian batasan menuliskan apa yang tidak diuji secara eksplisit, sehingga pembaca tahu tepat di mana laporan berhenti. Seluruh sesi terdaftar di berkas indeks pengujian, satu baris per sesi, menunjuk laporan dan folder screenshot-nya, jadi tidak ada sesi yang hilang di antara laporan.
Lapis kedua: berkas modul yang hidup
Berkas modul menjawab pertanyaan yang berbeda dari laporan sesi: bagaimana kondisi kontrak modul ini sekarang, dan perubahan desain apa yang terjadi sepanjang waktu. Laporan sesi bersifat temporer dan tak tersentuh setelah sesi selesai; berkas modul terus dibaca dan diperbarui jauh setelah itu. Slice yang mengubah halaman, form, menu, atau endpoint wajib menambah baris riwayat di berkas modul pada commit yang sama. Lapisan inilah yang membuat temuan lama masih bisa ditafsirkan bulan depan: status terakhir modul, temuan aktif, dan riwayat perubahannya berada di satu tempat, bukan tersebar di belasan laporan sesi.
Dua aturan kecil menyatukan semuanya. Screenshot memakai penamaan tanggal-jam WIB diikuti ID skenario, sehingga urutan pengambilan dan pemiliknya bisa dibaca dari nama berkas. Semua referensi bukti di laporan adalah tautan relative yang bisa diklik, dan satu aturan yang paling menentukan: angka hanya boleh berasal dari artefak mesin, hasil kueri basis data, lalu jaringan, atau berkas JSON, bukan dari transkrip manual. Aturan terakhir ini yang memutus kebiasaan lama menghitung ulang dari layar dan menyalin hasilnya sebagai angka laporan.
Bukti dari sesi pertama
Sesi pertama dengan format ini menguji modul admin informasi: 31 skenario, 27 PASS, 4 temuan ber-ID, dan hitungan UI dicocokkan ke 13 kueri basis data segar dengan kecocokan penuh. Sesi retest terpisah menyusuri empat kegagalan baseline sebelumnya dan semuanya tidak muncul lagi, dengan satu temuan baru berupa flake login yang terdokumentasi. Disiplin yang sama berlaku lintas domain: panduan pengujian keamanan OWASP menuntut bukti terstruktur untuk tiap klaim [1], dan format ini menerjemahkan tuntutan itu ke rutinitas harian. Biayanya disiplin menulis saat bekerja: screenshot dinamai di menit yang sama ia diambil, kueri pencacah dijalankan sebelum tab browser ditutup. Untungnya, justru itu yang membuat laporan bisa dipercaya setelah ingatan semua pihak mulai kabur, dan beban menulisnya justru turun karena tidak ada lagi fase rekonstruksi yang menyita waktu di akhir hari.
Sources: [1] OWASP Web Security Testing Guide