Audit test strategy untuk tim yang makin bergantung pada AI perlu dimulai dari kenyataan sederhana: AI bisa mempercepat penulisan kode dan test, tetapi juga bisa mempercepat produksi keyakinan yang salah. Banyak tim melihat pull request lebih cepat selesai, coverage naik, dan test bertambah banyak, namun tetap lolos bug yang seharusnya tertangkap.

Masalah utamanya bukan sekadar “AI membuat bug”, melainkan AI sering menyalin pola asumsi dari kode ke test. Akibatnya, implementasi salah dan test-nya sama-sama salah. Artikel ini membahas cara mengaudit strategi testing dalam situasi itu: bagaimana mengenali pola risikonya, metrik apa yang masuk akal, seperti apa review PR yang sehat, dan bagaimana tim kecil bisa mengadopsinya tanpa birokrasi berlebihan.

Sebagai konteks reflektif, tren seperti “What Kind of AI-Assisted Developer Are You?” menarik karena menunjukkan bahwa cara developer memakai AI sangat beragam: ada yang hanya minta boilerplate, ada yang minta refactor, ada yang membiarkan AI ikut menulis test. Perbedaan perilaku ini penting karena profil risiko testing juga ikut berubah. Fokus artikel ini bukan kuisnya, melainkan dampaknya pada strategi test yang harus diaudit ulang.

Mengapa strategi testing perlu diaudit ulang saat AI makin sering dipakai

Pada workflow tradisional, banyak test lahir dari pemahaman manusia terhadap requirement, bug lama, dan area rapuh dalam sistem. Saat AI masuk ke loop, test sering dibuat dari:

  • potongan kode yang baru saja ditulis AI,
  • nama fungsi dan signature yang tersedia,
  • pola test yang sering muncul di repository,
  • interpretasi umum atas prompt, bukan atas requirement bisnis asli.

Itu berarti test bisa tampak rapi tetapi lemah secara verifikasi. Beberapa gejala yang sering muncul:

  • Test ikut menyalin asumsi bug: implementasi salah, test mengafirmasi kesalahan yang sama.
  • Coverage tinggi tapi verifikasi lemah: banyak baris dieksekusi, sedikit perilaku penting yang benar-benar dibuktikan.
  • Flaky test diabaikan: karena perubahan cepat, tim memilih rerun pipeline daripada mencari sumber nondeterminism.
  • Regression gap setelah refactor cepat: AI mempercepat refactor lintas file, tetapi test kontrak dan skenario lintas komponen tidak ikut diperkuat.

Audit diperlukan agar tim tidak tertipu oleh volume test, kecepatan merge, atau angka coverage yang naik tanpa peningkatan kualitas sinyal.

Pola risiko yang paling sering muncul

1. Test ikut menyalin asumsi bug

Ini pola paling berbahaya. Misalnya, requirement menyatakan diskon hanya berlaku untuk pelanggan premium, tetapi implementasi AI menerapkan diskon untuk semua pelanggan dengan total belanja tertentu. Lalu AI juga membuat test berdasarkan implementasi itu, bukan requirement. Hasilnya: semua hijau, perilaku bisnis tetap salah.

Biasanya cirinya:

  • assertion terlalu dekat dengan detail perhitungan internal,
  • test disusun setelah melihat implementasi, bukan acceptance criteria,
  • tidak ada test negatif atau boundary case dari perspektif domain.

Masalah ini makin sering terjadi jika reviewer hanya memeriksa apakah test ada, bukan apakah test membuktikan hal yang benar.

2. Coverage tinggi, verifikasi lemah

Code coverage berguna sebagai indikator area yang tersentuh, tetapi bukan bukti bahwa sistem aman. AI sangat pandai membuat test yang mengeksekusi banyak jalur dasar tanpa memeriksa outcome yang penting.

Contoh gejala:

  • assertion hanya memeriksa bahwa response bernilai 200, tanpa memeriksa body atau efek samping,
  • mock berlebihan sehingga test hanya membuktikan bahwa mock dipanggil,
  • snapshot besar yang lolos meski perubahan semantik penting tersembunyi di dalamnya.

Jika test utama Anda berkata “fungsi dipanggil”, “status OK”, atau “objek tidak null”, itu sering lebih dekat ke sinyal aktivitas daripada sinyal kebenaran.

3. Flaky test yang dibiarkan menjadi noise

Saat AI mempercepat perubahan, jumlah test sering bertambah lebih cepat daripada disiplin perawatannya. Test yang kadang gagal karena timing, urutan data, race condition, dependensi eksternal, atau waktu lokal mulai dianggap normal. Tim lalu membangun kebiasaan buruk: rerun sampai hijau.

Dampaknya serius:

  • kegagalan nyata tersamarkan oleh noise,
  • kepercayaan pada CI turun,
  • reviewer berhenti menganggap red build sebagai sinyal penting.

4. Regression gap setelah refactor cepat

AI bagus untuk refactor mekanis: rename, ekstraksi fungsi, pemindahan struktur, penyederhanaan conditional. Namun refactor cepat bisa menggeser perilaku secara halus, terutama di boundary antarmuka, serialisasi, query, caching, atau error handling. Jika test yang ada dominan implementation-centric, perubahan besar bisa lolos tanpa pengaman perilaku.

Regression gap umum terjadi pada:

  • API contract dan format payload,
  • perilaku idempotensi,
  • urutan side effect,
  • error path yang jarang disentuh,
  • integrasi antar layanan.

Framework audit test strategy yang praktis

Audit tidak harus dimulai dari tool baru. Mulailah dari lima area yang bisa diperiksa langsung di repository, CI, dan proses review.

1. Petakan critical path, jangan audit semua test sekaligus

Kesalahan umum saat audit adalah mencoba memperbaiki seluruh suite test sekaligus. Lebih efektif jika tim memetakan critical path: alur bisnis dan teknis yang jika rusak akan berdampak paling besar.

Contoh critical path:

  • login dan otorisasi,
  • checkout atau pembayaran,
  • pembuatan invoice,
  • sinkronisasi data ke sistem lain,
  • proses background yang memengaruhi status order.

Untuk tiap critical path, dokumentasikan secara ringkas:

  • perilaku yang harus selalu benar,
  • input dan boundary penting,
  • efek samping yang diharapkan,
  • komponen yang terlibat,
  • jenis test yang saat ini melindunginya.

Tujuannya adalah mengetahui apakah area paling penting dilindungi oleh test perilaku yang benar, bukan sekadar oleh banyak unit test.

2. Bedakan test behavior vs implementation

Ini inti audit yang paling penting. Test perilaku memverifikasi hasil yang terlihat dari kontrak sistem. Test implementasi memverifikasi langkah internal. Keduanya punya tempat, tetapi ketika tim makin bergantung pada AI, proporsi test implementasi biasanya naik terlalu banyak.

Test behavior biasanya memeriksa:

  • response API dan kontraknya,
  • status domain setelah operasi,
  • event yang dipublikasikan,
  • perubahan data yang bermakna,
  • pesan error pada kondisi gagal.

Test implementation biasanya memeriksa:

  • fungsi internal tertentu dipanggil,
  • urutan helper tertentu,
  • nama method atau struktur internal,
  • detail mock yang terlalu spesifik.

Sebagai contoh, bandingkan dua gaya test berikut.

// Lebih implementation-centric
it('memanggil calculator dan repository', async () => {
  const calculator = { calculate: jest.fn().mockReturnValue(120000) };
  const repo = { save: jest.fn() };
  const service = new CheckoutService(calculator, repo);

  await service.checkout({ userType: 'premium', items: [{ price: 100000, qty: 1 }] });

  expect(calculator.calculate).toHaveBeenCalled();
  expect(repo.save).toHaveBeenCalled();
});

// Lebih behavior-centric
it('memberikan diskon premium dan menyimpan total akhir', async () => {
  const order = await checkout({
    userType: 'premium',
    items: [{ price: 100000, qty: 1 }]
  });

  expect(order.total).toBe(90000);
  expect(order.discount).toBe(10000);
  expect(order.status).toBe('confirmed');
});

Test pertama berguna dalam situasi tertentu, tetapi tidak cukup untuk membuktikan aturan bisnis. Test kedua lebih kuat sebagai pagar terhadap refactor dan perubahan implementasi.

3. Ukur sinyal flaky, bukan hanya jumlah gagal

Banyak tim tahu mereka punya flaky test, tetapi tidak punya cara sederhana untuk mengukurnya. Audit yang baik perlu membedakan antara failure deterministik dan failure yang muncul secara acak.

Metrik praktis yang bisa dipakai:

  • failure rate per test: berapa kali test gagal dalam jangka waktu tertentu,
  • rerun pass rate: seberapa sering test gagal lalu langsung hijau pada rerun,
  • top flaky files: file test dengan kegagalan intermiten terbanyak,
  • mean time to quarantine/fix: berapa lama test flaky dibiarkan aktif,
  • CI noise ratio: proporsi build merah yang ternyata bukan bug produk.

Kalau tool Anda belum menyediakan analitik detail, mulai dari log CI sederhana. Simpan daftar test gagal per run dan hitung test yang gagal lebih dari sekali tetapi tidak konsisten.

# pseudo-workflow sederhana dari log CI
run_101: test_a fail, test_b pass, test_c fail
run_102: test_a pass, test_b pass, test_c fail
run_103: test_a fail, test_b pass, test_c pass

# indikasi flaky:
# test_a dan test_c berubah hasil tanpa perubahan jelas di area yang sama

Yang penting bukan akurasi statistik tingkat lanjut pada awalnya, melainkan membuat flaky test terlihat sebagai backlog nyata, bukan gangguan biasa.

4. Review test oracle: dari mana kebenaran test berasal?

Oracle test adalah sumber pembanding yang membuat kita yakin hasil test memang benar. Dalam konteks AI, audit oracle sangat penting karena test sering dibuat berdasarkan implementasi yang baru ditulis, bukan berdasarkan sumber kebenaran independen.

Pertanyaan audit yang perlu diajukan:

  • Assertion ini dibandingkan terhadap apa?
  • Apakah expected value berasal dari requirement, fixture yang diverifikasi, atau hasil perhitungan ulang yang independen?
  • Apakah test hanya mengulang logika produksi dengan cara sedikit berbeda?
  • Apakah snapshot terlalu besar sehingga reviewer tidak benar-benar memeriksa perubahan?

Contoh test oracle yang lemah:

it('menghitung total', () => {
  const items = [{ price: 100, qty: 2 }];
  const result = calculateTotal(items);
  const expected = items.reduce((sum, item) => sum + item.price * item.qty, 0);
  expect(result).toBe(expected);
});

Jika fungsi produksi juga memakai logika yang sama, test ini mudah menjadi cermin implementasi. Lebih baik tambahkan contoh domain eksplisit, boundary case, dan aturan bisnis yang tidak sekadar menyalin algoritme.

it('menolak total negatif setelah diskon berlebih', () => {
  const result = calculateInvoice({
    items: [{ price: 5000, qty: 1 }],
    discount: 10000
  });

  expect(result.total).toBe(0);
  expect(result.validationErrors).toContain('discount_exceeds_subtotal');
});

Oracle yang kuat biasanya datang dari salah satu sumber ini:

  • acceptance criteria yang jelas,
  • contoh kasus bisnis yang disepakati,
  • kontrak API atau schema,
  • golden dataset yang direview,
  • hasil sistem referensi yang dipercaya.

5. Tambahkan checklist CI untuk perubahan yang dibantu AI

Jika AI dipakai aktif di tim, CI sebaiknya tidak hanya menjalankan test, tetapi juga memaksa beberapa bentuk verifikasi tambahan untuk perubahan berisiko.

Checklist CI yang praktis:

  • Wajib menjalankan test pada file yang berubah dan area critical path terkait.
  • Jalankan subset integration/contract test untuk modul yang disentuh AI.
  • Tolak merge jika snapshot besar berubah tanpa persetujuan reviewer.
  • Tandai PR yang menambah test tetapi tidak menambah assertion bermakna pada area berisiko.
  • Tampilkan file flaky terkait jika area yang sama berubah.
  • Wajibkan deskripsi PR berisi sumber verifikasi: requirement, bug report, atau reproduksi issue.

Anda tidak harus mengotomatisasi semuanya sekaligus. Bahkan checklist manual di template pull request sudah memberi dampak besar.

## Verifikasi Perubahan
- [ ] Perubahan ini menyentuh critical path
- [ ] Test baru memverifikasi behavior, bukan hanya pemanggilan internal
- [ ] Expected result berasal dari requirement / kontrak / bug reproduction
- [ ] Integration atau contract test sudah dijalankan bila relevan
- [ ] Tidak ada flaky test yang diabaikan untuk area ini
- [ ] Jika kode/test dibantu AI, saya sudah review asumsi domain dan edge case

Workflow pull request yang lebih aman saat AI ikut menulis kode dan test

Audit strategi testing akan lebih efektif jika diterjemahkan ke workflow PR yang konkret. Berikut pola yang cukup ringan untuk tim kecil sampai menengah.

Langkah 1: Penulis PR menandai jenis perubahan

Tambahkan label atau bagian template:

  • bug fix,
  • refactor,
  • fitur baru,
  • AI-assisted code,
  • AI-assisted test.

Tujuannya bukan menghakimi pemakaian AI, tetapi menaikkan kewaspadaan review ketika source of truth perlu dicek ekstra.

Langkah 2: Reviewer memeriksa pasangan code-test-requirement

Jangan hanya bertanya “apakah test ada?”. Tanyakan tiga hal ini:

  1. Apa perilaku yang berubah?
  2. Test mana yang membuktikan perilaku itu?
  3. Dari mana expected outcome berasal?

Kalau jawaban ketiganya tidak jelas, PR belum siap meski coverage naik.

Langkah 3: Untuk refactor, minta bukti non-fungsional bahwa perilaku tetap sama

Refactor besar yang dibantu AI sering menyentuh banyak file. Dalam kasus seperti ini, reviewer perlu meminta kombinasi berikut:

  • test kontrak tetap hijau,
  • perbandingan output sebelum-sesudah pada contoh data penting,
  • daftar area yang sengaja tidak berubah.

Jika memungkinkan, gunakan fixture atau golden file pada jalur penting. Ini membantu menangkap regression halus yang tidak terlihat pada unit test kecil.

Langkah 4: Jangan merge flaky failure dengan asumsi “nanti dibenahi”

Jika pipeline merah karena test yang dikenal flaky di area yang sedang berubah, ada dua pilihan sehat:

  • perbaiki flaky test sekarang, atau
  • quarantine dengan tiket, owner, dan tenggat yang jelas.

Yang tidak sehat adalah rerun tanpa jejak keputusan. Itu menghapus sinyal audit.

Metrik yang relevan untuk audit test strategy

Metrik harus membantu pengambilan keputusan, bukan sekadar mempercantik dashboard. Untuk konteks tim yang makin memakai AI, fokus pada metrik yang mengukur kualitas verifikasi dan stabilitas.

Metrik inti

  • Critical path test depth: berapa banyak alur penting yang punya test behavior dan integration, bukan hanya unit test.
  • Assertion quality ratio: proporsi test baru yang memeriksa outcome bisnis/kontrak dibanding yang hanya memeriksa call atau status umum.
  • Flaky signal rate: jumlah kegagalan intermiten per periode.
  • Regression escape count: bug produksi yang seharusnya bisa dicegah oleh test.
  • Refactor safety score: untuk perubahan refactor, apakah ada test kontrak atau golden-path yang dijalankan.

Metrik yang perlu diperlakukan hati-hati

  • Line coverage: tetap berguna, tetapi jangan dijadikan target utama.
  • Jumlah test: banyak test tidak berarti proteksi kuat.
  • Durasi CI total: penting, tetapi jangan memotong integration test penting hanya demi angka cepat.

Jika ingin memulai sederhana, buat dashboard mingguan dengan empat angka saja:

  1. jumlah PR AI-assisted,
  2. jumlah flaky failure,
  3. jumlah bug regresi,
  4. jumlah perubahan critical path yang punya test behavior baru atau diperbarui.

Kesalahan umum saat melakukan audit

  • Menganggap AI sebagai masalah tunggal. Sering kali akar masalah sebenarnya adalah requirement kabur, review lemah, atau suite test yang memang rapuh sejak awal.
  • Memaksa semua test jadi integration test. Ini membuat CI lambat dan sulit didiagnosis. Yang penting adalah komposisi test yang tepat.
  • Mengejar coverage setelah bug lolos. Respons yang lebih baik adalah menambah test yang membuktikan perilaku yang benar, bukan hanya menambah baris yang dieksekusi.
  • Menyimpan snapshot besar tanpa disiplin review. Snapshot mudah dihasilkan AI, tetapi sulit diverifikasi manusia.
  • Mengabaikan failure yang “jarang”. Flaky kecil yang dibiarkan akan menurunkan kualitas keputusan merge secara sistemik.

Langkah adopsi bertahap untuk tim kecil

Tim kecil tidak perlu langsung membangun platform observability testing. Pendekatan bertahap justru lebih realistis dan berkelanjutan.

Tahap 1: Dua minggu pertama

  • Tentukan 3-5 critical path utama.
  • Tambahkan template PR dengan checklist verifikasi perubahan AI-assisted.
  • Identifikasi 10 test paling sering gagal atau paling sering disentuh.
  • Mulai tandai test behavior vs implementation pada review.

Tahap 2: Bulan pertama

  • Tambahkan minimal satu behavior test atau contract test untuk tiap critical path.
  • Buat daftar flaky test beserta owner-nya.
  • Review snapshot besar dan hapus yang tidak memberi nilai verifikasi jelas.
  • Catat bug regresi dan hubungkan ke gap test yang spesifik.

Tahap 3: Setelah kebiasaan terbentuk

  • Otomatisasi pelacakan flaky dari log CI.
  • Tambahkan gate ringan untuk area critical path.
  • Gunakan label PR untuk perubahan AI-assisted dan refactor besar.
  • Lakukan review bulanan: bug mana yang lolos, test mana yang noise, area mana yang masih tanpa oracle kuat.

Poin pentingnya: jangan mulai dari “larang AI”. Mulailah dari “naikkan kualitas bukti”. AI bisa tetap dipakai, tetapi test strategy harus diubah agar tidak menerima output AI sebagai valid hanya karena terlihat lengkap.

Penutup

Audit test strategy untuk tim yang makin bergantung pada AI pada dasarnya adalah audit terhadap kualitas keyakinan tim. Pertanyaannya bukan apakah AI menulis kode atau test, tetapi apakah test Anda benar-benar membuktikan perilaku penting, stabil di CI, dan cukup independen dari asumsi implementasi yang mungkin salah.

Jika harus memilih satu titik mulai, pilih ini: petakan critical path lalu audit apakah test di sana memverifikasi behavior dengan oracle yang kuat. Dari situ, lanjutkan dengan pengukuran flaky signal, review PR yang lebih disiplin, dan checklist CI untuk perubahan AI-assisted. Dengan cara itu, tim kecil pun bisa meningkatkan safety net tanpa kehilangan kecepatan.