Baseline QA Sebelum Perbaikan: Merah Bukan Berarti Kode Rusak

Baseline QA pertama saya jalankan dari rencana kerja di docs/superpowers/plans/2026-10-09-qa-backfill-fase0-routing-admin.md, dan langkah pertamanya langsung berbalik: layar terminal penuh indikator merah, semua test integrasi gagal serentak. Refleks pertama saya jelas — kode terbaru pasti ada yang rusak. Saya buka diff commit terbaru dan mencari kesalahan sintaks atau logika yang baru berubah. Tidak ada.

Yang pincang ada di dua tempat yang tidak bisa dilihat dari kode. Database pengujian menyimpan revisi schema_migrations yang lebih baru daripada kode yang sedang di-checkout: volume database dari sesi pengujian sebelumnya masih hidup, sementara kode yang dijalankan sudah mundur ke revisi lama. Migrator membaca migrasi dan menerapkannya secara berurutan, tidak menebak apa yang diinginkan orang, dan kalau situasinya ambigu dia memang gagal [3]. Sinyal kedua datang dari healthcheck Docker Compose yang tetap menunjukkan unhealthy meski aplikasinya menjawab HTTP 200: skrip healthcheck memanggil biner wget yang tidak tersedia di image development.

Saat itu saya tidak langsung mempercayai hasil merahnya. Baseline berfungsi mencatat realitas sistem apa adanya, dan mencatat berarti mengukur sesuatu yang tidak saya ubah-ubah di tengah jalan. Yang saya perbaiki hanya lingkungan; temuan yang menyentuh kode atau skrip test saya masukkan ke daftar keputusan supaya tidak hilang di antara perbaikan cepat.

Drift lingkungan bukan bug kode

Perintah teardown standar di Docker Compose hanya menghapus kontainer dan jaringan, sementara volume bernama tetap dipertahankan secara default [1]. Volume memang dirancang sebagai penyimpanan data persisten dari mesin kontainer: kalau belum ada, compose membuatnya, dan kalau dihapus manual di luar compose, sesi berikutnya membuatnya lagi [2]. Volume sisa sesi itulah yang membawa skema lama ke dalam pengujian.

Perintah pertama hanya membersihkan lingkungan: docker compose down -v. Flag -v menghapus volume bernama yang dideklarasikan di berkas Compose beserta volume anonim kontainer [1], jadi skema lama ikut terbawa keluar.

Baru setelah itu test integrasi saya jalankan persis seperti langkah F0-1 di rencana kerja:

cd api && go test -count=1 -p 1 -cover -tags=integration ./internal/...

Hasilnya bersih: 28 paket lolos, 0 gagal, dengan coverage per paket tercetak di keluaran. Kalau dibutuhkan file profil coverage, Go menyediakannya lewat go test -coverprofile dan utilitas bawaan cover yang membacanya [4].

Drift seperti ini tidak lahir dari satu perintah yang salah, melainkan dari keputusan yang masuk akal pada waktu yang berbeda: menyimpan volume supaya pengujian tidak membangun ulang database tiap sesi, lalu menjalankan kode yang sudah mundur tanpa membersihkan volume lama. Tidak ada komponen yang rusak, dan itu sebabnya tidak ada error yang menunjuk ke komponennya.

Angkanya yang menentukan urutan kerja berikutnya. Lima paket terbawah ada di 0,0%, 20,4%, 30,7%, 31,6%, dan 33,4%, sementara 18 paket berada di bawah target yang ditetapkan tim. Itu daftar kerja saya, disusun dari angka, bukan dari perasaan mana bagian yang terasa rapuh.

Lapisan lain dicatat, bukan diperbaiki

Lapisan frontend hijau sejak awal: 10 berkas dan 69 test vitest lolos, lint 0 error dengan 3 warning, dan build menghasilkan 42 halaman. Vitest sendiri menghitung coverage lewat v8 atau instrumentasi istanbul [5], jadi angkanya langsung bisa dipakai. Smoke test di tiga rute utama juga lolos.

Baseline E2E saya catat persis seperti hasilnya: 45 pass, 3 fail, 1 flaky, 4 not-run. Tidak ada satu pun dari tiga kegagalan itu yang saya perbaiki di sesi baseline. Mengubah sistem yang sedang diukur membuat angka pengukurannya tidak bisa dipercaya, jadi klasifikasi (bug produk atau bug test) saya tunda sampai daftar temuan itu benar-benar dibaca.

Satu daftar keputusan setelah baseline

Hasil semua lapisan masuk ke satu dokumen rencana, lengkap dengan checklist F0-1 sampai F0-6 yang sudah dicentang beserta statusnya, bukan cuma PASS/FAIL. Urutan kerja berikutnya langsung terbaca dari sana: paket dengan coverage terbawah dipatch lebih dulu, healthcheck diperiksa biner mana yang benar-benar ada di image, dan tiga kegagalan E2E menunggu keputusan pemilik project.

Dua sinyal merah yang saya temukan justru yang paling murah diperbaiki: satu perintah untuk lingkungan bersih dan satu baris konfigurasi healthcheck. Sisanya butuh keputusan, dan baseline menjaga keputusan itu tetap berada di daftar temuan, bukan di tangan siapa saja yang keburu panik melihat layar merah.

Sumber

[1] Docker docs: CLI compose down
[2] Docker docs: Compose file volumes
[3] golang-migrate README
[4] Go docs: cmd/cover
[5] Vitest docs: coverage