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. Atau Anda sudah menulis beberapa tes, tetapi mereka terasa rapuh, lambat, dan terpisah dari risiko rilis nyata di aplikasi CapacitorJS atau Electron Anda.

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 code yang bergerak cepat, jembatan native yang dapat rusak dalam cara yang halus, dan kadang-kadang jalur pembaruan 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
  • Mengapa bagian atas piramida tetap kecil
• Kasus Bisnis untuk Pengujian Otomatis
  • Di mana tim merasakan kembali
  • Cara berpikir yang praktis tentang ROI
• Memilih Apa yang Dapat 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
  • Ubahlah tes menjadi pintu keluar rilis
  • Ukur suite seperti sistem
• Strategi Pengujian untuk Capacitor dan Aplikasi Electron
  • Bagi stack berdasarkan mode kegagalan
  • Bagaimana pembaruan hidup mengubah prioritas pengujian
• Menghindari Kesalahan Otomatisasi yang Umum

Apa Itu Pengujian Otomatis dan Mengapa Hal Ini Penting

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

kecil menyentuh status autentikasi, rute WebView, acara analitik, dan satu aliran izin native. Saat tim selesai mengklik melalui semuanya, 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 adalah praktek menulis tes yang dieksekusi oleh periksa yang telah ditentukan terhadap perangkat lunak Anda tanpa ada orang yang secara manual mengulangi langkah-langkah yang sama setiap kali rilis. Dalam istilah yang lebih sederhana, Anda memindahkan verifikasi yang berulang dari daftar checklist manusia ke dalam code. Perangkat code tersebut dapat memvalidasi sebuah fungsi, sebuah API kontrak, 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 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 tersebut 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 periksa tersebut termasuk dalam otomatisasi. __CAPGO_KEEP_0__ : automation

Tim baru yang terlibat di ruang ini biasanya mendapatkan manfaat dari sumber daya yang menggambarkan dasar-dasar tanpa tenggelam dalam perdebatan alat. Panduan ringkas tentang mengurangi otomatisasi tes perangkat lunak dapat membantu mengalihkan insinyur dan produk pada gelombang pertama tes yang layak ditulis.

Mengerti Piramida Tes Otomatis

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

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

Mulai dari dasar

Di bagian bawah ada tes unit. Tes ini memvalidasi bagian kecil logika secara isolasi. Dalam sebuah aplikasi Capacitor , itu mungkin logika pembaruan token, format tanggal, evaluasi flag fitur, atau transisi keadaan di toko. Dalam aplikasi Electron, itu mungkin 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.

Layer tengah adalah Uji coba integrasi. Uji coba ini memastikan bahwa modul-modul yang terpisah bekerja bersama-sama dengan benar. Contoh termasuk frontend Anda berbicara dengan klien API , lapisan penyimpanan lokal memulihkan keadaan aplikasi, atau penghubung jembatan native mengembalikan nilai yang diharapkan ke JavaScript.

Kemudian Anda memiliki Uji coba UI atau uji coba akhir-ke-akhir di atas. Uji coba ini menyimulasikan perilaku pengguna di seluruh antarmuka aplikasi. Mereka sangat berkuasa karena mereka menangkap aliran yang rusak yang diabaikan oleh uji coba tingkat 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 sukses seringkali menginvestasikan terlalu banyak dalam UI tests karena tes-tes itu terasa paling dekat dengan perilaku nyata. Intuisi ini 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 otomatisasi tes perangkat lunak menjelaskan keuntungan utama otomatisasi: otomatisasi paling kuat untuk periksaan yang berulang dan dapat diulang, sementara tes manual masih penting untuk validasi eksplorasi, kenyamanan, dan kasus di tepi. Sumber yang sama menyebutkan bahwa otomatisasi dapat mengurangi siklus tes dari hari ke jam dan meningkatkan coverase, tapi tidak menggantikan tes manual.

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

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

Kasus Bisnis untuk Otomatisasi Tes

Tim teknik seringkali menjelaskan otomatisasi dalam istilah teknis. Stakeholder biasanya peduli dengan sesuatu yang 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.

Skenario bisnis itu tidak lagi di pinggir. 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 memecahkan masalah operasional yang mereka rasakan setiap minggu.

Di mana tim sebenarnya merasakan kembali

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

• Feedback yang lebih cepat: Pengembang belajar dengan cepat apakah perubahan tersebut menghancurkan jalur yang diketahui.
• Kurang manual repetisi: QA dan insinyur berhenti menjalankan skrip regresi yang sama setiap rilis.
• Surprise yang lebih sedikit: Bug tertangkap sebelum mereka mendarat di staging atau produksi.
• Handoff yang lebih bersih: Produk, QA, dan insinyur dapat membahas gagal menggunakan artefak yang sama.

Ada juga sudut pandang moralitas yang jarang disebutkan oleh tim secara lantang. Pengulangan pengecekan manual menguras insinyur-insinyur yang baik. Pemutakhiran otomatis mengalihkan upaya menuju mendiagnosis risiko nyata daripada mengulangi skenario-skenario lama.

Cara praktis untuk berpikir tentang ROI

Jangan memulai dengan spreadsheet penuh asumsi. Mulai dengan biaya tidak otomatisasi.

Tanyakan beberapa pertanyaan langsung:

1. Berapa sering tim mengulang pengecekan regresi yang sama?
2. Flows mana yang menghalangi rilis jika gagal?
3. Berapa banyak waktu insinyur yang digunakan untuk memverifikasi flows tersebut secara manual?
4. Apa yang terjadi ketika salah satu flows tersebut gagal setelah rilis?

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

Tes berguna untuk ROI: Jika kegagalan akan memperlambat rilis atau memicu volume dukungan, otomatisasi pengecekan secepat mungkin yang dapat dibenarkan.

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

Pilih Apa yang Dapat Diamati Otomatis dan Apa yang Dapat Diamati 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 menilai tes berdasarkan ulang, kekritisan bisnis, dan stabilitas. Jika alur kerja berubah setiap minggu, otomatisasi akan menjadi pengganti yang berulang. 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 yang menganggap otomatisasi sebagai satu hal. Ini paling kuat untuk tes regresi, berulang, data-driven, dan sensitif terhadap ketepatan, dan tes otomatis haruslah tertutup dan independen sehingga gagalnya lebih mudah untuk diidentifikasi.

Terjemahan ini berarti backlog pertama yang praktis:

• Alur kritis: masuk, keluar, pembelian, pengaktifan ulang langganan, pemulihan akun.
• Pengecekan regresi: fungsi yang rusak sebelumnya dan sekarang memerlukan perlindungan permanen.
• Validasi data-terpusat: aturan formulir, logika harga, format lokasi, hak akses paket.
• Uji kontrak lintas platform: pemanggilan JavaScript yang memanggil plugin native dan mengnormalisasi 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 wrapper daripada hanya bergantung pada uji UI luas.

Tugas yang harus tetap manual

Beberapa pengecekan masih memerlukan orang karena mereka bergantung pada keputusan, bukan hanya kebenaran.

• Pengujian eksploratori: menemukan interaksi aneh yang tidak dapat diprediksi oleh jalur yang ditulis secara skrip.
• Ulasan ketergunaan: apakah alur baru yang menimbulkan kebingungan, bising, 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 alur 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.

Mengintegrasikan Otomatisasi ke Dalam Pipa CI/CD Anda

Otomatisasi sendiri tidak berguna. Otomatisasi yang terintegrasi ke dalam pengiriman adalah 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 Capacitor dan tim Electron, biasanya berarti menggabungkan GitHub Actions, GitLab CI, Jenkins, atau pengguna pipa lainnya dengan pekerjaan terpisah untuk tahap unit, integrasi, dan E2E.

Ubahlah tes menjadi pintu rilis

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

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

Dokumen pedoman AFIT menggambarkan otomatisasi sebagai siklus hidup dari Rencanakan, Kembangkan, Jalankan, dan Analisis, di mana eksekusi menghasilkan data dan analisis digunakan untuk mengidentifikasi anomali dan ROI dalam lingkaran perbaikan yang terus-menerus, seperti yang dijelaskan dalam Dokumen pedoman implementasi otomatisasi tes perangkat lunak AFIT. Itulah 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, sebuah referensi yang praktis adalah membangun aplikasi bisnis modern bermanfaat karena menghubungkan arsitektur, disiplin peluncuran, 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 peluncuran semua harus berurutan.

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

Mengukur suite seperti suatu sistem

Suite tes yang hanya melaporkan pass atau fail menghilangkan setengah gambaran. Tim juga harus memantau:

• Waktu eksekusi: Suite yang lambat akan dilewati.
• Polanya pass dan fail: Kegagalan yang berulang dapat menunjukkan masalah lingkungan, bukan bug produk.
• Kualitas tes yang tidak stabil: Kerusakan kepercayaan terjadi lebih cepat daripada rendahnya coverage.
• Upaya perawatan: Jika setiap perubahan UI memecahkan sepuluh tes, maka desain suite perlu diperbaiki.

Pertanyaan sehat bukanlah “Apakah kami memiliki otomatisasi?” Tapi “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 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 bersama, UI framework, jembatan code, pengemasan, dan perilaku spesifik platform yang berada di satu kereta pengiriman.

Artinya, saran umum tentang apa yang diotomatisasi seringkali melewatkan bagian yang paling sulit. Bug yang berisiko biasanya hidup di perbatasan.

Pisahkan stack oleh mode kegagalan

Strategi yang praktis adalah memisahkan tes berdasarkan asal kegagalan.

Untuk logika bisnis bersamagunakan unit test dengan tools seperti Jest atau Vitest. Ini sangat 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, push notifikasi, akses kamera, atau plugin native kustom, tes kontrak wrapper yang UI Anda bergantung.

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

• Jalur autentikasi: masuk baru, sesi yang telah kedaluwarsa, keluar, entri ulang kata sandi
• Aliran offline dan pemulihan: status yang disimpan, perilaku ulang, logika koneksi ulang
• Navigasi layar kritis: onboarding, checkout, pengaturan akun
• Fitur sensitif update: layar yang paling mungkin rusak setelah rilis front-end

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

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

Bagaimana update hidup mengubah prioritas tes

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

Itu tidak berarti Anda menurunkan standar. Itu berarti Anda merebalansinya.

Perubahan plugin native, pengelolaan izin, konfigurasi biner, dan apa pun yang terkait dengan code yang disubmit ke toko harus mendapat 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 seringkali bergerak lebih cepat ketika mereka tahu mereka dapat memperbaiki masalah dengan cepat setelah rollout.

Untuk tim yang menggunakan sistem update hidup seperti CapgoJika perlu, otomatisasi jalur pembaruan itu sendiri patut dilakukan. Tes deteksi pembaruan, 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 harus dimasukkan ke dalam suite.

Model pemisahan yang masuk akal untuk Capacitor dan tim Electron tampak seperti ini:

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

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

Menghindari Kesalahan Otomatisasi yang Umum

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

Biaya perawatan yang nyata. Seperti yang dijelaskan di Penulisan Cegeka tentang kesulitan otomatisasi tesOtomatisasi kehilangan nilai ketika perubahan UI, selektor yang rapuh, dan logika tes yang usang menciptakan ketidakstabilan dan ulang pekerjaan. Ketika insinyur berhenti percaya pada kegagalan, mereka berhenti bertindak atasnya.

Beberapa pola menyebabkan sebagian besar kesulitan:

• 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 rusak yang mengganggu tes berikutnya.
• Strategi data tes yang tidak ada: Lingkungan berubah, pengguna yang dijadikan acuan menjadi tidak valid, dan kegagalan menjadi sulit untuk direproduksi.
• Kegagalan yang diabaikan: Tim berulang-ulang hingga hijau dan melatih diri mereka untuk menolak sinyal.
• Penggunaan yang berlebihan pada pengujian UI: Terlalu banyak tes E2E yang luas, tidak cukup periksa tingkat rendah.

Hanya otomatisasi yang membantu ketika suite tetap terkini dengan produk. Tes-tes lama tidak netral. Mereka aktif menghabiskan waktu rilis.

Tim-tim yang berhasil disiplin tentang pemangkasan. Mereka menghapus tes-tes rendah nilai, stabilisasi tes-tes yang berharga, dan memeriksa gagal cepat. Mereka juga menulis tes dengan standar yang sama yang mereka aplikasikan 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 ke pengguna tanpa menunggu ulasan toko aplikasi. Hal ini mengubah cara tim berpikir tentang risiko rilis, rollback, dan apa yang suite otomatisasi mereka 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, Pembangunan Nativ Capgo untuk alur kerja produk di Pembangunan Nativ Capgo Integrasi Capgo untuk alur kerja produk di Integrasi Capgo Integrasi CI/CD untuk detail implementasi di Integrasi CI/CD, dan GitHub Integrasi Aksi untuk detail implementasi di GitHub Integrasi Aksi.