Apa Itu Pengujian Otomatis: Pengujian Otomatis Dijelaskan

Kamu mungkin sedang menghadapi salah satu situasi berikut. Atau tim kamu masih melakukan tes regresi manual sebelum setiap rilis, mengklik melalui login, checkout, push notifikasi, pengaturan, dan pemulihan offline sambil menunggu orang lain.

Automated testing adalah infrastruktur rilis yang sebenarnya. Bagi tim yang berfokus pada platform cross, risiko bahkan lebih tinggi. Kamu memiliki web code yang bergerak cepat, jembatan native yang bisa rusak dalam cara yang halus, dan kadang-kadang jalur update yang berubah bagaimana cepat kamu bisa pulih dari kesalahan.

Daftar Isi

• Apakah Automated Testing dan Mengapa Hal Ini Penting?
• Mengerti Piramida Automated Testing
  • Mulai dari dasar
  • Mengapa bagian atas piramida tetap kecil
• Kasus Bisnis untuk Automated Testing
  • Dimana tim merasakan kembali keuntungan
  • Cara Praktis untuk Berpikir tentang ROI
• Mengilih Apa yang Harus Dijalankan Otomatis dan Apa yang Harus Dites Secara Manual
  • Calon yang Baik untuk Dijalankan Otomatis
  • Kerja yang harus tetap manual
• Integrasi Otomatisasi ke Pipa CI/CD Anda
  • Ubahlah tes menjadi pintu rilis
  • Pengukuran suite seperti sistem
• Strategi Pengujian untuk Capacitor dan Aplikasi Electron
  • Pisahkan stack berdasarkan mode gagal
  • Bagaimana pembaruan hidup mengubah prioritas pengujian
• Menghindari Kesalahan Otomatisasi yang Umum

Apa Itu Pengujian Otomatis dan Mengapa Hal Ini Penting

Polanya rilis yang familiar seperti ini. Produk ingin memperbaiki bug hari ini. Teknik mengatakan bahwa perubahan kecil. Kemudian seseorang memulai checklist manual dan menemukan bahwa perubahan

kecil mengubahsuatu cara untuk mengubah pengecekan yang berulang menjadi validasi yang dapat diandalkan, code-driven. Sebaliknya, Anda tidak perlu mengandalkan seseorang untuk mengonfirmasi secara manual aliran yang sama setiap kali rilis, karena otomatisasi tes memastikan perilaku yang diharapkan setiap kali code berubah. Hal ini membantu tim menangkap regresi lebih awal dan menjaga keputusan rilis berdasarkan feedback yang konsisten. Hal ini menjadi sangat berharga bagi aplikasi lintas platform, di mana satu perubahan code yang sama dapat mempengaruhi pengalaman web, mobile, dan desktop secara bersamaan.

Automated testing adalah praktek menulis tes yang menjalankan pengecekan yang telah ditentukan terhadap perangkat lunak Anda tanpa seseorang yang secara manual mengulangi langkah yang sama setiap kali rilis. Dalam istilah yang lebih sederhana, Anda memindahkan verifikasi yang berulang dari daftar checklist manusia ke code. code tersebut dapat memvalidasi fungsi, kontrak API, transisi layar, atau aliran pengguna yang lengkap.

Alasan mengapa hal ini penting adalah sederhana. Hal ini mengubah kepercayaan rilis dari berdasarkan ingatan ke berdasarkan sistem. Menurut Ringkasan statistik otomatisasi tes tahun 2025 dari Testlio, lebih dari 70% dari profesional tes menggunakan otomatisasi untuk mengidentifikasi bug lebih cepat, dan 46% dari tim mengatakan bahwa otomatisasi telah menggantikan 50% atau lebih dari tes manual mereka. Hal ini sesuai dengan apa yang sebagian besar tim engineering sudah merasakan: regresi manual tidak dapat berkembang biak ketika rilis menjadi lebih sering.

Untuk Capacitor dan tim Electron, tekanan tersebut muncul lebih awal karena satu basis kode seringkali melayani beberapa lingkungan. Perubahan tunggal dalam JavaScript yang digunakan bersama dapat mempengaruhi perilaku iOS, Android, dan desktop secara berbeda. Jika tim Anda juga berusaha meningkatkan retensi dan kualitas rilis, maka membantu menghubungkan disiplin tes dengan prioritas pengalaman pengguna aplikasi lebih baik karena bug yang dihadapi pengguna setelah peluncuran merupakan bagian dari pengalaman produk, bukan hanya masalah QA. prioritas pengalaman pengguna aplikasi, karena bug yang dihadapi pengguna setelah peluncuran merupakan bagian dari pengalaman produk, bukan hanya masalah QA.

Aturan praktis: Jika seseorang harus mengulang validasi yang sama setiap sprint, maka tim harus setidaknya bertanya apakah periksa tersebut termasuk dalam otomatisasi.

Tim baru yang masuk ke ruang ini biasanya mendapatkan manfaat dari sumber daya yang menggambarkan dasar-dasar tanpa tenggelam dalam debat perangkat lunak. Panduan singkat tentang sederhana otomatisasi pengujian perangkat lunak dapat membantu mengalinhkan insinyur dan produk pada gelombang pertama tes yang layak ditulis.

Piramida Pengujian Otomatis

Cara termudah untuk membuat otomatisasi menjadi mahal adalah dengan memulai dari UI dan berhenti di sana. Piramida pengujian ada untuk mencegah kesalahan tersebut.

Pertimbangkan proses pembuatan mobil. Anda tidak hanya menguji keselamatan jalan dengan mengemudi mobil yang selesai di jalan raya. Anda terlebih dahulu memverifikasi bagian mesin, kemudian bagaimana mesin tersebut terhubung dengan sistem lainnya, dan baru kemudian Anda menguji pengalaman mengemudi yang lengkap. Perangkat lunak bekerja sama seperti itu.

Mulai dengan dasar

Pada bagian bawah ada pengujian unit. Pengujian ini memvalidasi bagian kecil logika secara terisolasi. Di sebuah aplikasi Capacitor, itu mungkin adalah logika refresh token, format tanggal, evaluasi flag fitur, atau transisi keadaan di dalam penyimpanan. Di sebuah aplikasi Electron, itu mungkin adalah pengelolaan state jendela atau utilitas yang mengubah data lokal sebelum sinkronisasi.

Pengujian unit adalah yang termurah untuk dijalankan dan paling mudah untuk didebug. Ketika mereka gagal, Anda biasanya tahu tepatnya di mana harus mencari.

Lapisan tengah adalah pengujian integrasi. Pengujian ini memverifikasi bahwa modul-modul yang terpisah bekerja bersama-sama dengan benar. Contoh termasuk antarmuka depan yang berbicara dengan klien API, lapisan penyimpanan lokal yang memulihkan keadaan aplikasi, atau wrapper jembatan native yang mengembalikan nilai yang diharapkan ke JavaScript.

Kemudian Anda memiliki pengujian UI atau pengujian akhir-ke-akhiran di bagian atas. Pengujian ini menyimulasikan perilaku pengguna di seluruh antarmuka aplikasi. Mereka kuat karena mereka menangkap aliran yang rusak yang diabaikan oleh pengujian level yang lebih rendah. Mereka juga lebih lambat, lebih rapuh, dan lebih mahal untuk dipelihara.

Stack yang sehat biasanya terlihat seperti ini:

Mengapa bagian atas piramida tetap kecil

Tim seringkali menginvestasikan terlalu banyak dalam UI tests karena tes-tes itu terasa paling dekat dengan perilaku nyata. Insting ini memang wajar, tapi menyebabkan rasa sakit nanti. Suite UI rusak ketika ada perubahan selector, waktu muat, animasi, dan perubahan lingkungan. Anda masih membutuhkannya, tapi tidak untuk segalanya.

Ringkasan Qt tentang manfaat pengujian otomatis perangkat lunak menjelaskan pilihan inti dengan jelas: otomatisasi paling kuat untuk periksa ulang yang berulang, periksa ulang yang dapat diulang, sementara pengujian manusia masih penting untuk pengujian eksploratori, penggunaan, dan validasi kasus tepi. Sumber yang sama menyebutkan otomatisasi dapat mengurangi siklus tes dari hari ke jam dan meningkatkan coverase, tapi tidak menggantikan pengujian manual.

Pertahankan bagian atas piramida fokus pada aliran kritis bisnis. Jangan menghabiskan anggaran otomatisasi UI untuk membuktikan bahwa setiap tombol masih dapat diklik jika tes tingkat rendah sudah menutupi logika.

Untuk tim mobile, hal ini lebih penting karena permukaan UI menyebar ke perangkat dan sistem operasi yang berbeda. Suatu suite E2E yang lebih kecil dan lebih dipilih memberikan lebih banyak signal daripada suatu suite besar yang tidak dipercaya.

Kasus Bisnis untuk Pengujian Otomatis

Tim teknik sering menjelaskan otomatisasi dalam istilah teknis. Stakeholder biasanya peduli dengan hal lain. Mereka ingin tahu apakah tim dapat mengirimkan produk dengan lebih sedikit kejutan, pulih lebih cepat ketika sesuatu rusak, dan menghabiskan waktu yang lebih sedikit untuk pekerjaan release yang berulang.

Kasus bisnis tersebut tidak lagi di pinggir. Ringkasan Pasar Pengujian Perangkat Lunak TestGrid menaksir pasar pengujian perangkat lunak secara keseluruhan pada 48,17 miliar dolar pada tahun 2025 dan memproyeksikan 93,94 miliar dolar pada tahun 2030, sementara pengujian otomatisasi sendiri diperkirakan pada $29,29 miliar pada tahun 2025, meningkat dari $25,4 miliar pada tahun 2024, dengan tingkat pertumbuhan CAGR sebesar 15,3% . Pengambilan hikmah yang berguna bukanlah hype. Itu adalah fakta bahwa tim terus berinvestasi karena pengujian otomatis menyelesaikan masalah operasional yang mereka rasakan setiap minggu.

Dimana tim sebenarnya merasakan kembali

Kembali pertama biasanya muncul dalam alur rilis, bukan dalam skor kualitas abstrak.

• Feedback yang lebih cepat: Pengembang belajar dengan cepat apakah perubahan mengganggu jalur yang diketahui.
• Repetisi manual yang lebih sedikit: Timbangan kualitas dan insinyur berhenti menjalankan skrip regresi yang sama setiap kali rilis.
• Kurangnya kejutan terlambat: Bug dapat tertangkap sebelum mendarat di tahap staging atau produksi.
• Penanganan yang lebih bersih: Produk, QA, dan insinyur dapat membahas gagalnya menggunakan artefak yang sama.

Ada juga aspek moral yang jarang disebutkan oleh tim. Pemeriksaan manual berulang-ulang menguras insinyur-insinyur yang baik. Penerapan otomatisasi mengubah upaya ke diagnosis risiko yang sebenarnya daripada mereproduksi skenario lama.

Cara praktis untuk berpikir tentang ROI

Tidak mulai dengan spreadsheet penuh asumsi. Mulai dengan biaya tidak otomatisasi.

Tanyakan beberapa pertanyaan langsung:

1. Banyak kali tim menjalankan pemeriksaan regresi yang sama?
2. Fluktuasi mana yang menghalangi rilis jika gagal?
3. Banyak waktu insinyur yang digunakan untuk memverifikasi fluktuasi tersebut secara manual?
4. Apa yang terjadi ketika salah satu aliran tersebut gagal setelah rilis?

Framing biasanya membuat target pertama jelas. Login, pembayaran, sinkronisasi, onboarding, pengiriman update, dan penyimpanan pengaturan cenderung lebih penting daripada layar brosur dengan risiko rendah.

Tes yang berguna untuk ROI: jika kegagalan akan memperlambat rilis atau memicu volume dukungan, otomatisasi periksa secepat mungkin yang dapat Anda justifikasi.

ROI yang baik tidak berasal dari mengejar penutupan yang sempurna. Ini berasal dari otomatisasi periksa yang melindungi pendapatan, ritme rilis, dan beban dukungan.

Mengilih Apa yang Harus Diotomatisasi dan Apa yang Harus Dites Secara Manual

Tim sering gagal karena mereka memilih alat yang salah. Mereka gagal karena mereka mengotomatisasi pekerjaan yang salah terlebih dahulu.

Poin awal yang tepat adalah untuk menilai tes berdasarkan ulang, kritisitas bisnis, dan stabilitas. Jika alur kerja berubah setiap minggu, otomatisasi akan menjadi gangguan. Jika alur kerja stabil dan mahal untuk diverifikasi secara manual, otomatisasi biasanya membayar dirinya sendiri.

Kandidat otomatisasi yang baik

Ringkasan GeeksforGeeks tentang otomatisasi tes adalah berguna di sini karena menghindari perangkap yang menganggap otomatisasi sebagai satu hal. Ini paling kuat untuk pengujian regresi, pengulangan, pengujian data-dorong, dan pengujian sensitif ketepatan.dan pengujian otomatis haruslah yang terpisah dan mandiri. sehingga kesalahan lebih mudah didiagnosis.

Itu berarti backlog pertama yang praktis:

• Alur kritis: masuk, keluar, pembelian, pemulihan langganan, pemulihan akun.
• Pengecekan regresi: fungsionalitas yang rusak sebelumnya dan sekarang memerlukan perlindungan permanen.
• Pengujian validasi data-dorong: aturan formulir, logika harga, format lokal, hak akses paket.
• Pengujian kontrak lintas platform: Penyandang JavaScript yang memanggil plugin native dan memnormalisasi hasil.

For CapacitorJS dan Electron, pola yang sangat berharga adalah untuk mengotomatisasi sambungan antara lapisan aplikasi. Jika JavaScript Anda bergantung pada perilaku kamera native, sistem file, push, atau deep-link, tulislah tes sekitar kontrak wrapper daripada hanya bergantung pada tes UI luas.

Pekerjaan yang harus tetap manual

Beberapa periksaan masih memerlukan orang karena mereka bergantung pada penilaian, bukan hanya kebenaran.

• Pengujian eksploratori: menemukan interaksi aneh yang tidak dapat diprediksi oleh jalur yang ditulis.
• Pengujian kenyamanan: apakah aliran baru membingungkan, berisik, atau terlalu lambat untuk pengguna nyata.
• Polish visual: spasi, perasaan animasi, ton teks, dan hierarki.
• Penginvestigasi satu kali: masalah yang tidak stabil cukup untuk membenarkan otomatisasi.

Apa itu pengujian otomatis?

Tim mendapatkan lebih banyak nilai dari sepuluh tes yang dapat diandalkan pada alur kerja yang berisiko tinggi daripada seratus pengecekan yang terpisah yang tidak pernah direview.

Jika ragu, otomatisasi apa pun yang harus selalu diketahui, dan uji coba secara manual apa yang masih perlu dipelajari.

Mengintegrasikan Otomatisasi ke Dalam Pipa CI/CD Anda

Otomatisasi sendiri sangat berguna. Otomatisasi yang terintegrasi ke dalam proses pengiriman yang apa yang mengubah perilaku tim.

Jika tes hanya berjalan ketika seseorang mengingat untuk menjalankannya, Anda masih memiliki proses manual dengan langkah tambahan. Pola yang lebih baik adalah mengaktifkan suite yang tepat secara otomatis pada permintaan pull, penggabungan, jalankan malam, dan kandidat rilis. Untuk tim dan Electron Capacitor, biasanya berarti menggabungkan GitHub Actions, GitLab CI, Jenkins, atau runner pipeline lainnya dengan pekerjaan terpisah untuk tahap unit, integrasi, dan E2E.

Ubah tes menjadi pintu rilis

Sistem harus menjawab beberapa pertanyaan secara otomatis setelah setiap perubahan yang bermakna:

• Apakah code build bersih?
• Apakah layer tes cepat melewati?
• Apakah staging menerima artefak yang dapat di-deploy?
• Apakah aliran yang lebih berisiko masih berfungsi di lingkungan yang dekat dengan produksi?

Pedoman implementasi AFIT menggambarkan otomatisasi sebagai siklus hidup Rencanakan, Kembangkan, Jalankan, dan Analisisdi mana eksekusi menghasilkan data dan analisis digunakan untuk mengidentifikasi anomali dan ROI dalam siklus perbaikan yang terus-menerus, seperti yang dijelaskan dalam Implementasi Panduan Pengujian Otomatis AFIT. Itulah mindset yang perlu diadopsi. Pipa bukan hanya tempat menjalankan tes. Ini adalah sistem yang mengubah hasil tes menjadi keputusan rilis.

Jika Anda membangun alur pengiriman sekitar aset mobile dan web bersama-sama, referensi praktis tentang Pengembangan Aplikasi Perusahaan Modern bermanfaat karena menghubungkan arsitektur, disiplin pengiriman, dan keandalan operasional dalam percakapan yang sama.

Pedoman Panduan Terfokus untuk Capacitor otomatisasi pipa CI/CD juga dapat membantu ketika langkah-langkah pembangunan aplikasi, bundel web, tanda tangan, dan langkah-langkah pengiriman semua harus berurutan.

Berikut adalah ringkasan singkat tentang aliran CI/CD dalam prakteknya:

Pantau suite seperti sistem

A suite tes yang hanya melaporkan lulus atau gagal kurang lengkap. Tim juga harus melihat:

• Waktu eksekusi: Suit yang lambat akan dilewati.
• Polanya lulus dan gagal: Kegagalan yang berulang mungkin menunjukkan masalah lingkungan, bukan bug produk.
• Rasio tes flaky: Keterandalan merusak kepercayaan lebih cepat daripada rendahnya coverage.
• Upaya perawatan: Jika setiap perubahan UI memecahkan sepuluh tes, desain suite perlu diperbaiki.

Pertanyaan sehat bukanlah “Apakah kami memiliki otomatisasi?” Melainkan “Apakah otomatisasi kami memberikan signal cepat dan dapat dipercaya di dalam pengiriman?”

Strategi Pengujian untuk Capacitor dan Aplikasi Electron

Aplikasi lintas platform memerlukan strategi pengujian yang menghargai bagaimana stack dibangun. Aplikasi Capacitor bukan hanya aplikasi web, dan bukan hanya aplikasi native juga. Electron memiliki pemisahan yang sama, hanya di desktop. Anda memiliki JavaScript yang dibagikan, UI framework, jembatan code, pengemasan, dan perilaku spesifik platform yang duduk di satu kereta pengiriman.

Arti umum tentang pengujian otomatis seringkali melewatkan bagian yang paling sulit. Bug yang berisiko tinggi biasanya hidup di batas-batas.

Bagi stack yang gagal

Strategi praktis adalah memisahkan tes berdasarkan asal kegagalan.

Untuk logika bisnis bersamagunakan tes unit dengan alat seperti Jest atau Vitest. Tes ini sangat cocok untuk aturan validasi, keputusan izin, penanganan konflik sinkron, flag fitur, dan transformasi data lokal.

Untuk interaksi modulbuat tes integrasi di sekitar lapisan API Anda, adapter penyimpanan, dan antarmuka wrapper native. Jika aplikasi Anda menggunakan @capacitor/preferencespush notifikasi, akses kamera, atau plugin native kustom, tes kontrak wrapper yang UI Anda bergantung. Di Electron, lakukan hal yang sama di sekitar skrip preload, batas IPC, dan akses sistem file.

Untuk aliran wajah penggunaGunakan Playwright atau Cypress untuk perilaku WebView. Dalam prakteknya, banyak tim mendapatkan nilai terbaik dari suatu suite E2E yang sempit yang mencakup:

• Jalur autentikasi: masuk baru, sesi yang kadaluarsa, keluar, entri ulang kata sandi
• Aliran offline dan pemulihan: keadaan yang dicache, perilaku ulang, logika koneksi ulang
• Screen yang kritis navigasi: pembukaan, pembayaran, pengaturan akun
• Fungsi yang sensitif update: screen yang paling mungkin rusak setelah rilis front-end

Strategi ini penting karena jika suatu tes gagal, maka Anda harus mengetahui di mana harus mencari. Jika semua masalah hanya muncul dalam suatu jalur E2E, maka debugging menjadi lambat.

Dalam aplikasi multi-platform, uji kontrak di setiap batas. Batas antara web dan native serta batas antara renderer dan proses utama menciptakan risiko rilis yang lebih besar daripada komponen biasa code.

Bagaimana pembaruan hidup mengubah prioritas tes

Platform pembaruan langsung mengubah model risiko. Jika tim Anda dapat mengirimkan perubahan JavaScript, CSS, salinan, konfigurasi, dan aset di luar siklus tinjauan toko aplikasi, maka regresi layer web masih serius, tetapi bukan identik secara operasional dengan regresi yang terkait dengan native.

Tidak berarti Anda menurunkan standar. Artinya Anda menyesuaikan kembali mereka.

Pertukaran plugin native, pengelolaan izin, konfigurasi biner, dan apa pun yang terkait dengan code yang disampaikan ke toko layanan membutuhkan pemeriksaan sebelum rilis yang paling berat karena rollback lebih lambat dan dampak pengguna bertahan lebih lama. Perubahan layer web masih membutuhkan coveran otomatis, tetapi tim sering dapat bergerak lebih cepat ketika mereka tahu mereka dapat memperbaiki masalah dengan cepat setelah peluncuran.

Untuk tim yang menggunakan sistem pembaruan langsung seperti Capgomaka layak untuk mengotomatisasi jalur pembaruan itu sendiri. Uji deteksi pembaruan, perilaku download, waktu instalasi, perilaku fallback, dan kondisi rollback dengan cara yang sama seperti Anda menguji login atau pembelian. Jika mekanisme rilis Anda merupakan bagian dari risiko produksi, maka itu termasuk dalam suite.

Penyebaran yang masuk akal untuk tim Capacitor dan Electron terlihat seperti ini:

• Sebelum pengajuan ke toko: penutupan yang dalam pada jembatan native, izin, startup, kompatibilitas pembaruan, dan perjalanan inti
• Sebelum peluncuran bundle web: regresi yang kuat pada aliran UI bersama dan perilaku pengiriman pembaruan
• Setelah peluncuran: pemeriksaan asap yang sasaran di kondisi yang mirip produksi plus pemantauan log

Model yang lebih praktis daripada berpura-pura setiap perubahan memerlukan intensitas tes yang sama.

Menghindari Kesalahan Automasi yang Umum

Kesalahan otomasi yang paling mahal adalah menganggap suite seperti proyek yang selesai sekali. Suite yang baik berperilaku lebih seperti basis kode. Mereka memerlukan kepemilikan, refactoring, dan standar.

Biaya perawatan yang nyata. Seperti yang dijelaskan dalam tulisan Cegeka tentang kesalahan otomasi tes Otomasi kehilangan nilai ketika perubahan UI, selektor yang rapuh, dan logika tes yang usang menciptakan flakitas dan rework. Ketika insinyur berhenti percaya pada gagalnya, mereka berhenti bertindak atasnya.Beberapa pola menyebabkan sebagian besar rasa sakit:

Selektor yang rapuh:

• Tes yang terikat pada detail DOM yang tidak stabil rusak karena alasan yang salah. Skenario yang terkait:
• Satu tes meninggalkan status yang memecahkan tes berikutnya. Kesalahan otomasi yang paling mahal adalah menganggap suite seperti proyek yang selesai sekali.
• Strategi data tes tidak ada: Tidak ada strategi data tes:
• Tidak ada strategi data tes: Tidak ada strategi data tes:
• Koverasi UI yang terlalu besar: Terlalu banyak tes E2E yang luas, tidak cukup tes yang lebih rendah.

Aplikasi otomatis hanya membantu ketika suite tetap relevan dengan produk. Tes lama tidak netral. Mereka aktif menghabiskan waktu rilis.

Tim yang berhasil disiplin dalam memangkas. Mereka menghapus tes yang tidak berharga, stabilisasi tes yang berharga, dan memeriksa gagal dengan cepat. Mereka juga menulis tes dengan standar yang sama yang mereka gunakan untuk produksi code: asertasi yang jelas, setup yang terisolasi, bantuan yang dapat digunakan kembali, dan kepemilikan yang eksplisit.

Jika tim Anda Capacitor atau Electron ingin memulihkan lebih cepat dari regresi layer web: Capgo Capgo adalah salah satu opsi untuk mengirimkan pembaruan hidup yang ditandatangani ke pengguna tanpa harus menunggu ulasan toko aplikasi. Hal ini mengubah cara tim berpikir tentang risiko rilis, rollback, dan apa yang suite otomatis harus memvalidasi sebelum dan setelah pengiriman.

Teruskan dari Apa Itu Pengujian Otomatis: Pengujian Otomatis Dijelaskan

Jika Anda menggunakan Apa Itu Pengujian Otomatis: Pengujian Otomatis Dijelaskan untuk merencanakan otomatisasi CI/CD, hubungkannya dengan Capgo CI/CD untuk alur kerja produk di Capgo CI/CD, Capgo Pembangunan Nativ untuk alur kerja produk di Capgo Pembangunan Nativ, Capgo Integrasi untuk alur kerja produk di Capgo Integrasi, Integrasi CI/CD untuk detail implementasi di Integrasi CI/CD, dan GitHub Aksi Integrasi untuk detail implementasi di GitHub Aksi Integrasi.