17.6 Evidence Minimum Berdasarkan Jenis Perubahan

Audit menemukan masalah, tetapi kita perlu bukti bahwa output benar-benar siap dipakai. Di sinilah evidence dibutuhkan.

Masalahnya, tidak semua perubahan membutuhkan jenis evidence yang sama. Seorang engineer yang mengubah satu baris konfigurasi environment tidak perlu melakukan pengujian yang sama dengan engineer yang mengubah logika pembayaran. Tapi dalam praktiknya, banyak tim memperlakukan semua perubahan secara seragam: semua harus lewat unit test, semua harus lewat staging, semua harus direview dengan checklist yang sama. Akibatnya, perubahan kecil jadi lambat, dan perubahan besar tetap bocor karena evidence yang dikumpulkan tidak sesuai dengan risiko sebenarnya.

Bayangkan dua skenario. Pertama, seorang engineer meminta AI mengubah port database di file konfigurasi. Perubahannya satu baris, dampaknya hanya ke koneksi database. Kedua, seorang engineer meminta AI menambahkan fitur otorisasi baru yang mengubah cara sistem menentukan siapa yang boleh mengakses data pasien. Dua perubahan ini memiliki risiko yang sangat berbeda, tetapi sering diperlakukan sama.

Kita perlu membedakan jenis perubahan berdasarkan apa yang berubah, bukan berdasarkan seberapa besar kode yang dihasilkan. Setidaknya ada delapan jenis perubahan yang umum muncul dalam pekerjaan software:

Perubahan logika mengubah cara sistem mengambil keputusan. Evidence minimumnya adalah skenario uji yang mencakup kondisi batas dan kondisi gagal. Jika AI mengubah logika diskon, kita perlu bukti bahwa diskon benar dihitung untuk semua kategori pelanggan, bukan hanya skenario normal.

Perubahan API mengubah antarmuka yang dipakai sistem lain. Evidence minimumnya adalah kontrak API yang terdokumentasi dan pengujian kompatibilitas mundur. Jika AI menambahkan parameter baru ke endpoint yang sudah dipakai, kita perlu bukti bahwa sistem pemanggil lama tidak rusak.

Perubahan data mengubah struktur, format, atau interpretasi data. Evidence minimumnya adalah skema data yang tervalidasi dan migrasi yang teruji. Jika AI mengubah tipe kolom harga dari integer menjadi decimal, kita perlu bukti bahwa data lama tidak korup dan aplikasi yang membaca kolom itu masih berfungsi.

Perubahan integrasi mengubah cara sistem terhubung dengan sistem lain. Evidence minimumnya adalah pengujian koneksi dan penanganan error dari sisi lawan bicara. Jika AI mengubah cara sistem mengirim invoice ke API akuntansi, kita perlu bukti bahwa sistem bisa menangani timeout, reject, dan response tak terduga.

Perubahan keamanan mengubah mekanisme autentikasi, otorisasi, atau enkripsi. Evidence minimumnya adalah pengujian skenario akses yang tidak seharusnya diizinkan. Jika AI menambahkan endpoint baru, kita perlu bukti bahwa endpoint itu tidak bisa diakses tanpa token yang sah.

Perubahan konfigurasi mengubah nilai parameter yang memengaruhi perilaku sistem. Evidence minimumnya adalah daftar parameter yang berubah beserta dampak yang diketahui. Jika AI mengubah ukuran koneksi pool, kita perlu bukti bahwa sistem tidak kehabisan koneksi di beban puncak.

Perubahan deployment mengubah cara sistem dipasang, dijalankan, atau dihentikan. Evidence minimumnya adalah pengujian di lingkungan yang identik dengan production. Jika AI mengubah script startup, kita perlu bukti bahwa sistem bisa restart tanpa kehilangan data.

Perubahan alur pengetahuan mengubah cara pengetahuan diproses, dicari, atau disajikan ke pengguna. Evidence minimumnya adalah pengujian akurasi hasil dan konsistensi dengan sumber pengetahuan. Jika AI mengubah cara sistem merangkum dokumen hukum, kita perlu bukti bahwa ringkasan tidak menghilangkan klausul penting.

Setiap jenis perubahan punya evidence minimum yang berbeda. Tugas arsitek bukan menentukan apakah semua perubahan harus diuji dengan cara yang sama, tetapi memastikan bahwa untuk setiap perubahan, evidence yang dikumpulkan cukup untuk meyakinkan bahwa perubahan itu aman. Jika evidence minimum terpenuhi, perubahan bisa lanjut. Jika tidak, perubahan harus ditahan sampai bukti terkumpul.

Berikut adalah contoh definisi evidence minimum dalam format YAML yang bisa langsung diadaptasi menjadi checklist tim.

evidence_minimum:
  - type: logika
    description: Perubahan logika keputusan sistem
    minimumEvidence:
      - skenario kondisi batas
      - skenario kondisi gagal
    contohSkenario: AI mengubah logika diskon; perlu bukti diskon benar untuk semua kategori pelanggan

  - type: api
    description: Perubahan antarmuka yang dipakai sistem lain
    minimumEvidence:
      - kontrak API terdokumentasi
      - pengujian kompatibilitas mundur
    contohSkenario: AI menambah parameter baru ke endpoint; perlu bukti pemanggil lama tidak rusak

  - type: data
    description: Perubahan struktur, format, atau interpretasi data
    minimumEvidence:
      - validasi skema data
      - migrasi teruji
    contohSkenario: AI mengubah tipe kolom harga integer ke decimal; perlu bukti data lama tidak korup

  - type: integrasi
    description: Perubahan cara sistem terhubung dengan sistem lain
    minimumEvidence:
      - pengujian koneksi
      - penanganan error dari lawan bicara
    contohSkenario: AI mengubah cara kirim invoice ke API akuntansi; perlu bukti bisa tangani timeout

  - type: keamanan
    description: Perubahan mekanisme autentikasi, otorisasi, atau enkripsi
    minimumEvidence:
      - pengujian akses tidak sah
    contohSkenario: AI menambah endpoint baru; perlu bukti tidak bisa diakses tanpa token sah

  - type: konfigurasi
    description: Perubahan nilai parameter yang memengaruhi perilaku sistem
    minimumEvidence:
      - daftar parameter berubah
      - uji dampak beban
    contohSkenario: AI mengubah ukuran koneksi pool; perlu bukti tidak kehabisan koneksi di beban puncak

  - type: deployment
    description: Perubahan cara sistem dipasang, dijalankan, atau dihentikan
    minimumEvidence:
      - pengujian di lingkungan identik production
    contohSkenario: AI mengubah script startup; perlu bukti bisa restart tanpa kehilangan data

  - type: alur_pengetahuan
    description: Perubahan cara pengetahuan diproses, dicari, atau disajikan
    minimumEvidence:
      - pengujian akurasi hasil
      - konsistensi dengan sumber pengetahuan
    contohSkenario: AI mengubah cara merangkum dokumen hukum; perlu bukti tidak hilangkan klausul penting

Diagram berikut merangkum delapan jenis perubahan dan evidence minimum yang direkomendasikan.

flowchart TD A[Jenis Perubahan] --> B[Logika] A --> C[API] A --> D[Data] A --> E[Integrasi] A --> F[Keamanan] A --> G[Konfigurasi] A --> H[Deployment] A --> I[Alur Pengetahuan] B --> B1[Uji skenario batas & gagal] C --> C1[Dokumen kontrak & uji kompatibilitas mundur] D --> D1[Validasi skema & uji migrasi] E --> E1[Uji koneksi & penanganan error] F --> F1[Uji akses tidak sah] G --> G1[Daftar parameter & uji dampak beban] H --> H1[Uji di lingkungan identik production] I --> I1[Uji akurasi & konsistensi sumber]

Ini membawa kita ke pertanyaan berikutnya: kapan evidence harus dikumpulkan? Apakah cukup sekali sebelum merge, atau perlu diulang di tahap lain?