Test Impact Analysis adalah pendekatan untuk memilih subset test yang paling relevan berdasarkan perubahan kode, sehingga pipeline CI tidak selalu menjalankan seluruh test suite pada setiap commit. Tujuannya bukan sekadar menghemat waktu, tetapi mengurangi durasi feedback tanpa menurunkan kepercayaan terhadap hasil build.

Jika diterapkan dengan benar, Test Impact Analysis untuk CI lebih cepat tanpa mengurangi cakupan bekerja dengan menggabungkan beberapa input: file yang berubah, dependency graph, mapping modul-ke-test, dan aturan fallback ke full run saat tingkat keyakinan rendah. Kunci utamanya ada pada desain seleksi yang konservatif, validasi berkala, dan kontrol risiko false negative.

Apa itu Test Impact Analysis dan bagaimana bedanya dengan full test suite?

Pada pipeline tradisional, setiap perubahan memicu seluruh test suite: unit, integration, contract, end-to-end, dan seterusnya. Pendekatan ini sederhana dan aman, tetapi sering menjadi mahal ketika codebase membesar, terutama di monorepo atau service backend dengan banyak lapisan dependensi.

Test Impact Analysis (TIA) mengubah pertanyaan dari:

  • “Test apa saja yang tersedia?”
  • menjadi “Test mana yang terdampak oleh perubahan ini?”

Perbedaannya dengan menjalankan seluruh suite:

  • Full test suite: cakupan eksekusi maksimal, implementasi sederhana, biaya waktu tinggi.
  • TIA: eksekusi lebih selektif, feedback lebih cepat, tetapi membutuhkan data dependensi dan mekanisme mitigasi risiko.

TIA bukan pengganti total untuk full suite. Praktiknya, TIA dipakai untuk pull request atau commit-level validation, sementara full suite tetap berjalan secara terjadwal atau pada milestone tertentu seperti merge ke branch utama, release candidate, atau deployment production.

Kapan Test Impact Analysis cocok dipakai?

TIA paling cocok ketika bottleneck utama CI adalah waktu eksekusi test, bukan waktu build artifact atau provisioning environment.

Kondisi yang cocok

  • Monorepo dengan banyak package, service, atau aplikasi frontend/backend.
  • Backend service dengan unit test cepat tetapi integration test cukup mahal.
  • Tim dengan frekuensi commit tinggi dan kebutuhan feedback cepat di pull request.
  • Codebase yang sudah punya struktur dependensi cukup jelas.
  • Test suite besar, tetapi perubahan harian biasanya lokal pada area tertentu.

Kondisi yang kurang cocok

  • Codebase kecil dengan total test sudah cepat.
  • Arsitektur sangat dinamis sehingga sulit memetakan dependensi secara andal.
  • Banyak side effect lintas modul yang tidak terdokumentasi.
  • Test suite didominasi test end-to-end yang semuanya menyentuh jalur sistem yang sama.

Jika saat ini seluruh suite selesai dalam beberapa menit dan stabil, kompleksitas TIA mungkin belum sepadan. Tetapi jika CI sering memakan waktu lama dan menghambat review, TIA layak dipertimbangkan.

Input utama yang dipakai oleh Test Impact Analysis

Akurasi TIA bergantung pada kualitas input. Semakin baik informasi tentang perubahan dan relasi antar komponen, semakin kecil risiko salah memilih test.

1. Perubahan file

Input paling dasar adalah daftar file yang berubah antara branch feature dan target branch. Ini biasanya diambil dari diff git.

git diff --name-only origin/main...HEAD

Dari daftar file ini, sistem dapat mulai dengan aturan sederhana:

  • Jika file source di modul A berubah, jalankan test untuk modul A.
  • Jika file konfigurasi global berubah, jalankan full suite.
  • Jika migration database berubah, jalankan test yang menyentuh persistence dan integration test terkait.

Ini adalah titik awal yang praktis, tetapi belum cukup untuk kasus dependensi tidak langsung.

2. Dependency graph

Dependency graph menggambarkan modul mana yang bergantung pada modul lain. Jika library inti berubah, test pada consumer-nya juga perlu dipilih meskipun file test tidak berada di area yang sama.

Contoh logika:

  • packages/core-auth diimpor oleh services/api dan services/admin.
  • Jika core-auth berubah, test untuk dua service tersebut ikut terdampak.

Graph ini bisa dibangun dari:

  • import/include analysis statis,
  • dependency manifest per package,
  • build graph internal,
  • atau metadata dari sistem build yang sudah ada.

Semakin formal struktur dependensinya, semakin mudah menerapkan TIA. Monorepo biasanya lebih diuntungkan karena relasi package dapat dipetakan lebih konsisten.

3. Mapping modul-ke-test

Selain dependensi kode, Anda perlu tahu test mana yang memverifikasi modul tertentu. Ini bisa berupa mapping eksplisit atau hasil observasi historis.

Beberapa pendekatan umum:

  • Konvensi direktori: test di tests/service-a diasumsikan memverifikasi service-a.
  • Tagging atau metadata: test diberi label area seperti billing, auth, search.
  • Historical test selection: catatan file yang disentuh saat test dieksekusi sebelumnya.
  • Code ownership sebagai petunjuk tambahan, bukan sumber kebenaran utama.

Mapping yang terlalu longgar membuat TIA kurang efektif karena terlalu banyak test dipilih. Mapping yang terlalu sempit berisiko false negative karena ada area terdampak yang terlewat.

4. Fallback full run

Fallback full run adalah mekanisme pengaman. Jangan menerapkan TIA tanpa kondisi yang jelas kapan sistem harus kembali menjalankan seluruh suite.

Contoh kondisi fallback:

  • File build system, dependency manifest, atau konfigurasi global berubah.
  • Perubahan menyentuh framework bootstrap, shared kernel, atau middleware inti.
  • Graph dependensi gagal dibangun.
  • Mapping test tidak ditemukan untuk area tertentu.
  • Perubahan terlalu besar, misalnya refactor lintas banyak modul.

Prinsip aman: jika keyakinan seleksi rendah, pilih lebih banyak test atau jalankan full suite. TIA yang baik bersifat konservatif, bukan agresif.

Workflow implementasi bertahap di monorepo atau backend service

Implementasi TIA sebaiknya dilakukan bertahap. Tujuannya agar tim bisa mengukur akurasi dan mengendalikan risiko sebelum menjadikannya bagian utama dari CI.

Tahap 1: Mulai dari rules-based selection

Buat aturan deterministik berbasis path dan kategori perubahan.

rules:
  - if_changed: ["services/user/**"]
    run_tests: ["tests/unit/user", "tests/integration/user"]

  - if_changed: ["packages/shared/db/**"]
    run_tests: ["tests/integration/**", "tests/contract/**"]

  - if_changed: ["schema/**", "migrations/**"]
    run_tests: ["tests/integration/**", "tests/smoke/**"]

  - if_changed: ["ci/**", "build/**", "package-lock.json", "pom.xml", "go.mod"]
    fallback: full_run

Pada tahap ini, belum perlu analisis graph yang rumit. Fokusnya adalah mendapatkan pengurangan waktu CI yang aman di area dengan struktur jelas.

Tahap 2: Tambahkan dependency graph

Setelah aturan path stabil, perluas seleksi dengan transitive impact.

Contoh alur:

  1. Ambil file yang berubah.
  2. Petakan file ke modul pemilik.
  3. Cari modul yang bergantung langsung atau tidak langsung pada modul tersebut.
  4. Kumpulkan test milik modul-modul terdampak.
  5. Tambahkan smoke test wajib.
  6. Jika ada sinyal ketidakpastian, fallback ke full run.

Untuk backend service, dependency graph sering cukup dibangun pada level package, folder domain, atau komponen aplikasi. Tidak selalu harus sampai level file jika biaya pemeliharaan terlalu tinggi.

Tahap 3: Rekam dan validasi hasil seleksi

Sebelum TIA menjadi gate utama, jalankan mode shadow selama beberapa minggu:

  • CI tetap menjalankan full suite.
  • Sistem TIA menghitung subset test yang seharusnya dijalankan.
  • Bandingkan apakah subset itu akan menangkap failure yang sama.

Ini membantu mengukur false negative tanpa mempertaruhkan kualitas merge.

Tahap 4: Jadikan TIA sebagai default untuk PR

Setelah tingkat akurasi cukup baik, gunakan TIA untuk pull request dan commit validation, sambil mempertahankan full suite pada event tertentu:

  • nightly build,
  • merge ke branch utama,
  • release branch,
  • deployment candidate.

Contoh aturan seleksi test yang praktis

Aturan seleksi sebaiknya mudah diaudit oleh tim. Hindari logika yang terlalu pintar tetapi sulit dijelaskan saat terjadi miss.

Contoh 1: Backend service modular

if changed_files match ["src/auth/**"]:
  select tests ["tests/unit/auth/**", "tests/integration/auth/**", "tests/smoke/login/**"]

if changed_files match ["src/db/**", "migrations/**"]:
  select tests ["tests/integration/**", "tests/smoke/**"]

if changed_files match ["src/shared/**"]:
  select dependent module tests via dependency_graph

if changed_files match ["Dockerfile", "compose/**", "infra/**"]:
  fallback full_run

Contoh 2: Monorepo dengan package bersama

changed package: packages/ui-core
impact:
  - apps/web
  - apps/admin
selected tests:
  - tests for packages/ui-core
  - component tests for apps/web and apps/admin
  - smoke tests for critical rendering paths

Perhatikan bahwa smoke test wajib tetap dijalankan walaupun perubahan terlihat kecil. Ini memberi jaring pengaman terhadap kesalahan mapping atau side effect yang tidak tertangkap graph.

Strategi validasi akurasi Test Impact Analysis

TIA hanya berguna jika tim bisa mempercayainya. Karena itu, validasi akurasi harus menjadi bagian inti dari desain, bukan pekerjaan setelah implementasi.

1. Shadow mode

Bandingkan hasil TIA dengan full suite tanpa memengaruhi keputusan merge. Pertanyaan yang ingin dijawab:

  • Apakah test yang gagal pada full run juga termasuk dalam subset TIA?
  • Seberapa sering TIA memilih terlalu banyak test?
  • Area mana yang paling sering menyebabkan fallback?

2. Periodic replay

Ambil sampel commit historis, lalu jalankan ulang simulasi seleksi. Ini berguna untuk menguji perubahan aturan TIA terhadap riwayat bug yang pernah terjadi.

3. Diff-based audit

Untuk setiap miss atau bug lolos, audit:

  • file apa yang berubah,
  • modul apa yang semestinya dianggap terdampak,
  • test apa yang seharusnya terpilih,
  • mengapa mapping atau graph gagal menangkapnya.

Hasil audit harus kembali menjadi aturan atau metadata baru agar sistem membaik dari waktu ke waktu.

4. Conservative rollout

Mulailah dari area dengan struktur paling jelas dan test paling stabil. Hindari langsung menerapkan TIA pada seluruh kategori test sekaligus. Umumnya lebih aman memulai dari:

  • unit test,
  • component/integration test yang punya kepemilikan modul jelas,
  • bukan end-to-end global yang sangat sensitif terhadap perubahan sistemik.

Metrik yang perlu dipantau

Keberhasilan TIA tidak cukup diukur dari CI yang lebih cepat. Anda juga perlu memastikan kualitas deteksi tetap terjaga.

  • Median dan p95 durasi CI: apakah feedback benar-benar lebih cepat?
  • Jumlah test yang dijalankan per PR: seberapa besar pengurangan dibanding baseline?
  • Fallback rate: terlalu tinggi berarti aturan terlalu konservatif atau mapping belum matang.
  • Miss rate / false negative indicator: berapa kali full run menemukan kegagalan yang tidak dipilih oleh TIA?
  • Post-merge failure rate: apakah kegagalan meningkat setelah merge ke branch utama?
  • Flaky test rate: test flaky bisa merusak evaluasi akurasi TIA.
  • Coverage by risk area: area kritis seperti auth, pembayaran, migrasi data, dan permission harus diawasi khusus.

Jika durasi CI turun tetapi post-merge failure naik, berarti TIA terlalu agresif atau data dependensinya belum cukup baik.

Risiko false negative dan cara menguranginya

Risiko terbesar TIA adalah false negative: ada bug yang seharusnya terdeteksi, tetapi test relevan tidak dijalankan.

Penyebab umum false negative

  • Dependency graph tidak lengkap atau usang.
  • Shared utility dianggap lokal padahal dipakai luas.
  • Konfigurasi runtime memengaruhi perilaku lintas modul.
  • Perubahan schema, query, atau contract API berdampak lebih luas dari path file.
  • Test mapping terlalu sempit atau hanya berdasarkan struktur folder.

Mitigasi yang efektif

  • Fallback full run untuk perubahan berisiko tinggi.
  • Smoke test wajib di setiap PR.
  • Nightly full test untuk mendeteksi miss yang tidak terlihat pada PR level.
  • Audit coverage area berisiko seperti authentication, authorization, transaksi, data migration, dan integrasi eksternal.
  • Review aturan TIA setiap ada insiden lolos ke main branch atau staging.

Jangan menganggap TIA sebagai optimasi murni. Ini adalah sistem keputusan berbasis risiko. Desain yang aman selalu lebih penting daripada penghematan beberapa menit tambahan.

Pencegahan regresi yang wajib disiapkan

Nightly full test

Jalankan seluruh suite secara terjadwal, misalnya setiap malam atau beberapa kali sehari tergantung volume perubahan. Ini berfungsi sebagai jaring pengaman terhadap miss yang tidak terdeteksi pada level PR.

Smoke test wajib

Pilih sekumpulan test singkat yang memverifikasi jalur kritis aplikasi, lalu jalankan di setiap PR tanpa pengecualian. Smoke test harus kecil, stabil, dan mewakili fitur yang paling berisiko jika rusak.

Quarantine untuk flaky test

Flaky test dapat menutupi kualitas TIA karena sulit membedakan apakah miss terjadi akibat seleksi test atau test yang memang tidak stabil. Pisahkan test flaky ke jalur quarantine:

  • tetap dicatat dan dipantau,
  • tidak dijadikan sinyal utama akurasi TIA,
  • punya backlog perbaikan yang jelas.

Jangan gunakan keberadaan flaky test sebagai alasan memperluas subset test tanpa batas, karena itu hanya memindahkan masalah.

Audit coverage area berisiko

Lakukan review berkala pada area yang dampaknya besar terhadap bisnis atau reliabilitas sistem:

  • autentikasi dan otorisasi,
  • billing atau payment,
  • database migration dan rollback,
  • contract API publik,
  • fitur yang sering berubah.

Untuk area ini, sering kali lebih baik menetapkan aturan minimum test yang selalu dijalankan, terlepas dari hasil TIA.

Kesalahan implementasi yang sering terjadi

  • Langsung mengganti full suite sepenuhnya tanpa shadow mode atau fallback.
  • Mengandalkan path file saja pada codebase dengan dependensi lintas modul yang kompleks.
  • Tidak mendefinisikan area berisiko tinggi yang harus selalu punya baseline test.
  • Mengukur sukses hanya dari kecepatan, bukan akurasi deteksi.
  • Membiarkan graph dan mapping usang setelah refactor besar.
  • Mengabaikan flaky test sehingga evaluasi kualitas TIA menjadi bias.

Checklist adopsi Test Impact Analysis

Gunakan checklist ini sebelum mengaktifkan TIA sebagai default di CI:

  • Apakah bottleneck utama memang ada pada waktu eksekusi test?
  • Apakah ada daftar file berubah yang andal dari pipeline CI?
  • Apakah modul dan dependensi antarmodul dapat dipetakan?
  • Apakah test dapat dihubungkan ke modul atau area fungsional?
  • Apakah aturan fallback full run sudah jelas?
  • Apakah smoke test wajib sudah tersedia dan stabil?
  • Apakah ada nightly full test?
  • Apakah flaky test sudah dipisahkan atau ditandai?
  • Apakah metrik akurasi dan post-merge failure dipantau?
  • Apakah tim siap melakukan audit setiap kali ada miss?

Penutup

Test Impact Analysis untuk CI lebih cepat tanpa mengurangi cakupan bukan soal menjalankan test sesedikit mungkin, melainkan menjalankan test yang tepat dengan mekanisme pengaman yang memadai. Pendekatan ini paling efektif jika diterapkan bertahap: mulai dari aturan sederhana berbasis perubahan file, lalu ditingkatkan dengan dependency graph, mapping modul-ke-test, dan fallback yang konservatif.

Jika tujuan Anda adalah mempercepat feedback di pull request tanpa menurunkan kepercayaan rilis, TIA bisa menjadi strategi yang sangat berguna. Namun keberhasilannya bergantung pada disiplin operasional: validasi akurasi, nightly full run, smoke test wajib, quarantine flaky test, dan audit area berisiko. Dengan kombinasi itu, CI bisa menjadi lebih cepat tanpa berubah menjadi lebih rapuh.