Satu Daftar Temuan untuk Satu Keputusan Owner

Empat laporan sesi QA terbentang di layar, masing-masing membawa kode temuan berbeda: R4-1, R4-5, R5-2, R3-1. Semua lahir dari sesi yang sama cara kerjanya: browser yang dikendalikan lewat MCP dengan snapshot accessibility [3], jadi setiap temuan datang bersama screenshot, baris SQL, dan log network sebagai maskawin buktinya. Semua terlihat mendesak, semua berasal dari modul berbeda, dan saya harus menjawab satu pertanyaan: mana yang diperbaiki duluan?

Kuncinya ada di satu commit yang isinya cuma 64 baris markdown, FINDINGS.md. Commit itu mengubah empat laporan yang tersebar jadi satu tabel induk, dan angkanya berbicara: 18 temuan menunggu keputusan owner, 4 selesai atau terkonfirmasi sesuai desain, 4 kegagalan baseline E2E yang tidak terulang saat re-run, dan 1 masih berjalan. Daftar itu tidak menyembuhkan apa pun, tapi ia mengubah pertanyaan dari "apa yang rusak?" jadi "siapa yang memutuskan, dan kapan?".

Temuan Tanpa Keputusan Hanya Catatan

Tiket yang menumpuk punya ilusi produktivitas: setiap hari jumlahnya berkurang, arahnya tidak pernah jelas. Empat kegagalan baseline yang berstatus "tidak terulang" adalah contoh paling jujur. Enam kegagalan E2E dari fase awal dijalankan ulang satu per satu: modul layanan lulus 6/6, peta 5/5, portal 8/8, CRUD admin 5/5 sendirian. Tidak ada yang terulang. Tapi tidak ada juga yang diperbaiki, karena tidak ada yang rusak yang diketahui. "Tidak terulang" itu status, bukan perbaikan; menyamakannya dengan "selesai" adalah cara paling cepat menutup masalah yang belum paham. Flake memang penyakit yang aneh: setengahnya soal kontrak interaksi yang jarang dibaca, seperti perilaku dialog yang di-auto-dismiss saat tidak ada handler [1], dan setengahnya lagi soal lingkungan yang bergeser tanpa siapa pun mencatat.

Konsolidasi juga memaksa akar masalah bertemu. Validasi format telepon absen di dua modul sekaligus: R4-1 di informasi dan R4-7 di wisata, lapis berbeda (announcementadmin vs entityadmin), pertanyaan yang sama. Karena digabung, satu keputusan menutup dua modul, dengan kandidat solusi validator bersama di direktori shared. Media orphan bekerja sama: R4-5 awalnya dari announcement, tapi penghapusan permanen entity wisata meninggalkan jejak yang sama persis, row database dan file fisik yang tidak ikut terhapus. Dua modul, satu keputusan. Double-encoding detail halaman (R3-1 dan R3-2) bahkan sudah ketemu sendiri saat investigasi akar: slug dengan koma dan apostrof, parameter Next.js yang ter-encode dua kali, jadi logis diperlakukan sebagai satu irisan perbaikan, bukan dua.

Urutkan dengan Risiko, Bukan dengan Umur Tiket

Prioritas yang disarankan daftar itu sendiri terbaca seperti rantai dampak: R4-2 dengan severity tinggi di urutan pertama, skop "ALL" yang diperlakukan literal sehingga konten ber-bidang hilang dari list admin sekaligus halaman publik; disusul R4-4, API yang error membuat admin ter-logout diam-diam karena token dipurge tanpa membedakan 401 dengan 5xx; lalu dua temuan keamanan lama, kredensial dev di repo dan db-push yang menimpa users. sisanya baru urusan tampilan dan polish: toast salah bahasa, upload senyap, healthcheck yang memakai tool yang tidak ada di image.

Ada satu kategori yang tidak masuk hitungan sama sekali: temuan yang ternyata bukan temuan. Moderasi ulasan sempat dicurigai sebagai bug karena ulasan langsung tayang tanpa antre, sampai kode ditelusuri dan terbukti memang desainnya begitu — tayang instan, moderasi bergerak setelah kejadian, bukan sebelum. Daftar induk menyimpannya sebagai klarifikasi terpisah supaya sesi berikutnya tidak mengulang investigasi yang sama. Kesimpulan yang salah lebih mahal daripada temuan yang benar, karena ia memakan waktu orang dua kali.

Pertanyaan penyaring yang saya pakai sesudahnya sederhana: kalau perbaikan ini ditunda seminggu lagi, apakah ada data yang hilang atau pengguna yang tersesat? Kalau tidak, ia boleh menunggu giliran. Kalau ya, ia lompat antrean. Severity membantu, tapi pertanyaan itu yang mengubah angka di tabel jadi keputusan.

Yang juga menarik: beberapa temuan di daftar sudah tua. Kredensial dev di repo terbuka sejak handover, healthcheck yang memakai tool tak tersedia di image dev juga sama tuanya. Umur temuan tidak menaikkan prioritasnya sendirian — yang menaikkan adalah kombinasi peluang kena dampak dan murahnya perbaikan. Temuan tua yang perbaikannya satu baris justru kandidat bagus untuk diselesaikan lebih dulu, sebelum owner keburu lelah melihat daftar.

Cara pandang ini yang berubah setelah FINDINGS.md ada: pekerjaan saya bukan menutup tiket sebanyak mungkin, tapi memastikan setiap temuan punya pemilik, keputusan, dan urutan yang jelas. Kecepatan eksekusi tanpa arah cuma mempercepat ke keliru.

Sources

[1] Playwright docs: Dialogs
[3] Playwright MCP