Apa Itu Pengujian Otomatis: Pengujian Otomatis Dijelaskan

Saat ini, Anda mungkin menghadapi salah satu situasi berikut. Atau tim Anda masih menjalankan pengujian regresi manual sebelum setiap rilis, mengklik melalui login, checkout, push notifikasi, pengaturan, dan pemulihan offline sambil menunggu orang lain.

That’s where automated testing stops being an abstract QA term and starts becoming release infrastructure. For cross-platform teams, the stakes are even higher. You have web code moving fast, native bridges that can break in subtle ways, and sometimes a live update path that changes how quickly you can recover from mistakes. The useful question isn’t just what is automated testing. It’s which parts of your app should prove themselves automatically on every change, and which still need a human eye.

Itu di mana pengujian otomatis berhenti menjadi istilah QA abstrak dan mulai menjadi infrastruktur rilis. Untuk tim lintas platform, risiko bahkan lebih tinggi. Anda memiliki web __CAPGO_KEEP_0__ yang bergerak cepat, jembatan native yang dapat rusak dalam cara yang halus, dan kadang-kadang jalur update hidup yang mengubah seberapa cepat Anda dapat pulih dari kesalahan.

• Pertanyaan yang berguna bukan hanya apa itu pengujian otomatis. Tapi bagian mana dari aplikasi Anda yang harus membuktikan diri secara otomatis pada setiap perubahan, dan mana yang masih memerlukan mata manusia.
• Daftar Isi
  • Apa itu Pengujian Otomatis dan Mengapa Hal Ini Penting
  • Mengerti Piramida Pengujian Otomatis
• Mulai dengan dasar
  • Di mana tim-tim merasa mendapatkan kembali
  • Cara yang praktis untuk berpikir tentang ROI
• Memilih Apa yang Harus Dijalankan Otomatis dan Apa yang Harus Dijalankan Secara Manual
  • Kandidat otomatisasi yang baik
  • Kerja yang harus tetap manual
• Mengintegrasikan Otomatisasi ke Dalam Pipa CI/CD Anda
  • Ubahlah tes menjadi pintu rilis
  • Ukur suku cadang seperti sistem
• Strategi Pengujian untuk Capacitor dan Aplikasi Electron
  • Bagi lapisan menurut 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 terlihat seperti ini. Produk ingin memperbaiki masalah hari ini. Teknik mengatakan perubahan kecil. Kemudian seseorang memulai checklist manual dan menemukan bahwa perubahan

kecil menyentuh status autentikasi, jalur WebView, acara analitik, dan satu aliran izin native. Saat tim selesai mengklik melalui semua hal, setengah hari sudah hilang dan tidak ada yang sepenuhnya percaya pada hasilnya.: a way to turn repeated checks into reliable, code-driven validation. Instead of depending on someone to manually confirm the same flows every release, automated tests verify expected behavior whenever the code changes. This helps teams catch regressions earlier and keep release decisions grounded in consistent feedback. That becomes especially valuable for cross-platform apps where one shared code change can impact web, mobile, and desktop experiences at the same time.

apa itu pengujian otomatis is the practice of writing tests that execute predefined checks against your software without someone manually repeating the same steps every release. In plain terms, you move repeated verification out of a human checklist and into code. That code can validate a function, an API contract, a screen transition, or a full user flow.

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

Untuk Capacitor dan tim Electron, tekanan itu muncul lebih awal karena satu kodebase sering kali melayani beberapa lingkungan. Perubahan tunggal dalam JavaScript yang sama dapat mempengaruhi perilaku iOS, Android, dan desktop secara berbeda. Jika tim Anda juga mencoba meningkatkan retensi dan kualitas rilis, membantu untuk menghubungkan disiplin tes dengan prioritas pengalaman pengguna aplikasi yang lebih luas , karena bug yang dihadapi pengguna setelah peluncuran adalah bagian dari pengalaman produk, bukan hanya masalah QA.Aturan praktis:

Jika seseorang harus mengulangi validasi yang sama setiap sprint, tim harus setidaknya bertanya apakah cek itu termasuk dalam otomatisasi. Tim baru di bidang ini biasanya mendapatkan manfaat dari sumber daya yang menggambarkan dasar-dasar tanpa tenggelam dalam debat perangkat lunak. Panduan ringkas tentang

Panduan ringkas tentang otomatisasi tes Mengurangi otomatisasi pengujian perangkat lunak Dapat membantu menyelaraskan insinyur dan produk pada gelombang pertama tes yang layak ditulis.

Mengerti Piramida Pengujian Otomatis

Cara termurah untuk membuat otomatisasi 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 terhubung dengan sistem lainnya, dan hanya setelah itu Anda menguji pengalaman mengemudi yang lengkap. Perangkat lunak bekerja sama seperti itu.

Mulai dari dasar

Pada bagian bawah ada tes unit. Ini memvalidasi bagian kecil logika secara isolasi. Dalam sebuah aplikasi Capacitor , itu mungkin adalah logika pembaruan token, format tanggal, evaluasi flag fitur, atau transisi keadaan di dalam penyimpanan. Dalam aplikasi Electron, itu mungkin adalah pengaturan jendela atau utilitas yang mengubah data lokal sebelum sinkron.

Tes 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 tes integrasi. Ini memastikan bahwa modul-modul yang berbeda bekerja sama dengan benar. Contoh termasuk klien API di depan berbicara dengan klien, lapisan penyimpanan lokal memulihkan keadaan aplikasi, atau wrapper jembatan native mengembalikan nilai yang diharapkan ke JavaScript.

Maka Anda memiliki UI atau tes akhir-ke-akhiran di atas. Ini menyimulasikan perilaku pengguna di seluruh antarmuka aplikasi. Mereka sangat kuat karena menangkap aliran yang rusak yang diabaikan oleh tes 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 itu memang wajar, tapi menyebabkan rasa sakit nanti. Suite UI rusak ketika ada perubahan selector, waktu loading, animasi, dan perubahan lingkungan. Anda masih membutuhkannya, tapi tidak untuk segalanya.

Ringkasan Qt tentang manfaat pengujian perangkat lunak otomatis membuat keuntungan utama jelas: otomatisasi paling kuat untuk pengujian ulang, pengujian yang dapat diulang, sementara pengujian manusia masih penting untuk pengujian eksploratori, pengujian keterampilan pengguna, dan pengujian kasus tepi. Sumber yang sama menyebutkan bahwa otomatisasi dapat mengurangi siklus pengujian dari hari ke jam dan meningkatkan coverase, tetapi tidak menggantikan pengujian manual Tetapkan bagian atas piramida fokus pada aliran bisnis yang kritis. 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 menjangkau 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.

Alasan Bisnis untuk Pengujian Otomatis

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

Alasan bisnis ini tidak lagi di pinggiran.

__CAPGO_KEEP_0__ Ringkasan pasar pengujian perangkat lunak TestGrid diperkirakan pasar pengujian perangkat lunak lebih luas pada tahun $48.17 miliar pada tahun 2025 dan diproyeksikan $93.94 miliar pada tahun 2030, sementara pengujian otomatis sendiri diperkirakan pada $29.29 miliar pada tahun 2025, meningkat dari $25.4 miliar pada tahun 2024, dengan 15.3% CAGR. Pengambilan hikmah yang berguna bukanlah hype. Itu adalah tim yang terus berinvestasi karena pengujian otomatis menyelesaikan masalah operasional yang mereka rasakan setiap minggu.

Di mana tim-tim itu merasakan kembali keinvestasian.

Pertama kali kembali biasanya muncul dalam aliran rilis, bukan dalam skor kualitas abstrak.

• Feedback yang lebih cepat: Para pengembang belajar dengan cepat apakah perubahan itu mengganggu jalur yang diketahui.
• Manual ulang yang kurang: QA dan insinyur berhenti menjalankan skrip regresi yang sama setiap rilis.
• Surprise yang lebih sedikit: Bug dapat tertangkap sebelum mendarat di staging atau produksi.
• Handoff yang lebih bersih: Produk, QA, dan insinyur dapat membahas gagalnya menggunakan artefak yang sama.

Terdapat juga sudut pandang moralitas yang jarang disebutkan secara terbuka. Pengujian manual berulang-ulang menguras insinyur-insinyur yang baik. Otomatisasi yang kuat mengubah upaya menuju mendiagnosis risiko nyata bukan mengulangi skenario lama.

Aplikasi yang efektif untuk berpikir tentang ROI

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

Tanyakan beberapa pertanyaan langsung:

1. Banyak kali tim mengulang lagi tes regresi yang sama?
2. Flows mana yang menghalangi rilis jika gagal?
3. Banyak waktu insinyur yang digunakan untuk memverifikasi flows manual?
4. Apa yang terjadi ketika salah satu flows gagal setelah rilis?

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

Tes yang berguna untuk ROI: jika gagalnya akan memperlambat rilis atau memicu volume dukungan, otomatisasi tes secepat mungkin yang dapat dibenarkan.

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

Pemilihan Apa yang Harus Dijalankan Otomatis dan Apa yang Harus Dites Manual

Tim sering gagal karena mereka tidak mengotomasi pekerjaan yang tepat terlebih dahulu.

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

Kandidat otomatisasi yang baik

Ringkasan GeeksforGeeks tentang tes otomatisasi Bermanfaat di sini karena menghindari jerat menganggap otomatisasi sebagai satu hal. Ini paling kuat untuk tes regresi, berulang, data-driven, dan sensitif terhadap ketepatan, dan tes otomatis harus tertutup dan independen sehingga gagalnya lebih mudah didiagnosis.

Hal itu berarti ke dalam backlog pertama yang praktis:

• Alur kritis: flow Masuk, Keluar, Pembelian, Pengembalian Langganan, Pemulihan Akun.
• Periksa Kembali: Fungsi yang rusak sebelumnya dan sekarang memerlukan perlindungan permanen.
• Validasi Data-Driven: Aturan Form, Logika Harga, Format Lokal, Hak Akses Paket.
• Uji Kontrak Berbasis Platform: Pemanggilan JavaScript yang memanggil plugin native dan memnormalisasi hasilnya.

Untuk 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 uji sekitar kontrak pemanggilan wrapper daripada hanya bergantung pada uji UI luas.

Kerja yang harus tetap manual

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

• Pengujian Eksploratori: Mencari interaksi aneh yang tidak dapat diprediksi oleh jalur yang ditulis skrip.
• Ulasan ketergunaan: apakah alur baru yang menimbulkan kebingungan, berisik, atau terlalu lambat untuk pengguna nyata.
• Polish visual: spasi, perasaan animasi, ton teks, dan hierarki.
• Penginvestigasian satu kali: masalah yang tidak stabil untuk membenarkan otomatisasi.

Perbandingan singkat membantu tim memutuskan lebih cepat:

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

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

Integrasi Otomatisasi ke Dalam Pipa CI/CD

Otomatisasi sendiri saja tidak berguna. Otomatisasi yang terintegrasi ke dalam proses pengiriman yang mengubah perilaku tim.

Jika tes hanya dijalankan ketika seseorang mengingat untuk menjalankannya, maka masih ada 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 Capacitor dan Electron, biasanya berarti menggabungkan GitHub Actions, GitLab CI, Jenkins, atau runner pipeline lainnya dengan pekerjaan terpisah untuk tahap unit, integrasi, dan E2E.

Ubah tes menjadi penghalang rilis

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

• Apakah code berhasil dibangun dengan bersih
• Apakah layer tes cepat berhasil
• Apakah tahap staging menerima artefak yang dapat di-deploy
• Apakah aliran yang lebih berisiko masih berfungsi di lingkungan yang mirip dengan produksi

Pedoman implementasi AFIT menjelaskan otomatisasi sebagai siklus dari Rencana, Pengembangan, Pelaksanaan, dan Analisisdi mana eksekusi menghasilkan data dan analisis digunakan untuk mengidentifikasi anomali dan ROI dalam lingkaran perbaikan yang terus-menerus, seperti yang dijelaskan dalam Pedoman implementasi otomatisasi pengujian perangkat lunak AFITItulah mindset yang perlu diadopsi. Pipa bukan hanya tempat menjalankan tes. Itu adalah sistem yang mengubah hasil tes menjadi keputusan rilis.

Jika Anda membangun alur pengiriman aset mobile dan web bersama-sama, referensi yang berguna adalah membangun aplikasi enterprise modern bermanfaat karena menghubungkan arsitektur, disiplin pelaksanaan, dan keandalan operasional dalam percakapan yang sama.

Petunjuk pengaturan yang fokus untuk Capacitor otomatisasi aliran CI/CD Juga dapat membantu ketika langkah-langkah pembangunan aplikasi, pembundelan web, penandatanganan, dan langkah-langkah pelaksanaan semua harus berurutan.

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

Uji coba suite seperti sistem

Suatu suite uji coba yang hanya melaporkan pass atau fail adalah kurang lengkap. Tim juga harus memantau:

• Waktu eksekusi: suite yang lambat akan diabaikan.
• Polanya pass dan fail: kegagalan yang berulang dapat menunjukkan masalah lingkungan, bukan bug produk.
• Kadar uji coba flaky: instabilitas merusak kepercayaan lebih cepat daripada rendemen yang rendah.
• Upaya perawatan: Jika setiap perubahan UI memecahkan sepuluh tes, desain suite perlu diperbaiki.

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

Strategi Pengujian untuk Capacitor dan Aplikasi Electron

Aplikasi lintas platform memerlukan strategi pengujian yang menghormati 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.

Itu berarti saran umum tentang apa yang diotomatisasi pengujian seringkali melewatkan bagian yang paling sulit. Bug yang berisiko biasanya hidup di batas-batas.

Pisahkan stack oleh mode kegagalan

Strategi yang praktis adalah memisahkan tes berdasarkan asal kegagalan.

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

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

Untuk aliran pengguna, gunakan Playwright atau Cypress untuk perilaku WebView-sentris. Dalam prakteknya, banyak tim mendapatkan nilai terbaik dari suite E2E yang sempit yang mencakup:

• Jalur autentikasi: masuk baru, sesi yang telah kedaluwarsa, keluar, dan entri password reset
• Aliran offline dan pemulihan: status yang disimpan, perilaku ulang, logika koneksi ulang
• Tampilan layar navigasi kritis: Pendaftaran, checkout, pengaturan akun
• Fitur yang sensitif terhadap update: Layar yang paling mungkin rusak setelah rilis front-end

Pendekatan yang berlapis ini penting karena jika tes gagal, maka Anda akan tahu di mana harus mencari. Jika semua masalah hanya muncul dalam jalankan akhir-ke-akhir, maka debugging menjadi lambat.

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

Bagaimana update hidup mengubah prioritas tes

Platform update hidup mengubah model risiko. Jika tim Anda dapat mengirimkan JavaScript, CSS, teks, konfigurasi, dan perubahan aset di luar siklus tinjauan toko aplikasi, maka regresi layer web masih serius, tetapi tidak identik dengan regresi native.

Itu tidak berarti Anda menurunkan standar. Itu berarti Anda merebalansirnya.

Perubahan plugin native, pengelolaan izin, konfigurasi biner, dan apa pun yang terkait dengan code yang disubmit ke toko aplikasi memerlukan perhatian pemeriksaan sebelum rilis yang paling berat karena rollback lebih lambat dan dampak pengguna bertahan lebih lama. Perubahan layer web masih memerlukan coverage otomatis, tetapi tim dapat sering bergerak lebih cepat ketika mereka tahu mereka dapat memperbaiki masalah dengan cepat setelah rollout.

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

A cara yang masuk akal untuk membagi tim Capacitor dan Electron adalah seperti ini:

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

Itu adalah 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 diselesaikan sekali. Suite yang baik berperilaku lebih seperti basis kode. Mereka memerlukan kepemilikan, refaktorisasi, dan standar.

Biaya perawatan nyata. Seperti yang dijelaskan dalam Tulisan Cegeka tentang kesalahan otomasi pengujianKetika otomatisasi kehilangan nilai ketika perubahan UI, pilihan yang rapuh, dan logika uji yang usang menciptakan ketidakstabilan dan ulang kerja. Ketika insinyur kehilangan kepercayaan pada kegagalan, mereka berhenti bertindak atasnya.

Beberapa pola menyebabkan sebagian besar kesulitan:

• Pilihan yang rapuh: Uji yang terikat pada detail DOM yang tidak stabil rusak karena alasan yang salah.
• Skenario yang terkait: Satu uji meninggalkan status yang rusak untuk uji berikutnya.
• Tidak ada strategi data uji: Environment yang berubah, pengguna yang dihasilkan menjadi tidak valid, dan kegagalan menjadi sulit untuk direproduksi.
• Kegagalan yang diabaikan: Tim berulang-ulang hingga hijau dan melatih diri mereka untuk menolak sinyal.
• Pengujian UI yang terlalu luas: Pengujian E2E yang terlalu luas, tidak cukup pengujian tingkat rendah.

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

Tim-tim yang berhasil disiplin tentang pemangkasan. Mereka menghapus tes dengan nilai rendah, stabilisasi tes dengan nilai tinggi, dan memeriksa gagal dengan cepat. Mereka juga menulis tes dengan standar yang sama yang mereka terapkan pada produksi code: asseri 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 adalah salah satu pilihan untuk mengirimkan pembaruan hidup yang ditandatangani kepada pengguna tanpa 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.

Teruslah 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 Build Nativ untuk alur kerja produk di Capgo Pembangunan Asli, Capgo Integrasi untuk alur kerja produk di Capgo Integrasi, Integrasi CI/CD untuk detail implementasi di Integrasi CI/CD, dan GitHub Integrasi Aksi untuk detail implementasi di GitHub Integrasi Aksi.