Cara meningkatkan CI / CD dengan pengujian shift-left

Menguji aplikasi dulunya merupakan aktivitas yang menantang secara teknis dan waktu terbatas yang dijadwalkan beberapa hari atau minggu sebelum aplikasi dirilis. Tim pengembang diberi kelonggaran untuk membuat kode hingga jam kesebelas, dan penguji, yang melakukan sebagian besar pekerjaan mereka secara manual, tidak punya banyak pilihan selain puas dengan sedikit waktu yang diberikan kepada mereka. Hasilnya adalah banyak aplikasi menjalani pengujian di bawah standar, dan tim teknologi dipaksa untuk menanggapi masalah produksi dan cacat yang meningkat oleh pengguna akhir dan sistem pemantauan aplikasi.

Praktik integrasi berkelanjutan Devops, kerangka pengujian unit, dan praktik otomatisasi pengujian telah meningkatkan paradigma ini. Alih-alih melakukan jaminan kualitas di akhir proses pengembangan, banyak praktik pengujian sekarang mulai dan dijalankan sepenuhnya selama pengkodean, integrasi, dan penerapan. Tim pengembang dan agile mengotomatiskan skrip pengujian, dan pipeline CI / CD memanggil untuk menjalankan pengujian selama fase integrasi atau pengiriman kode mereka. Hasil akhirnya adalah pengembang diberi tahu ketika perubahan kode mereka merusak build dan dapat segera mengambil langkah untuk mengatasi masalah yang dilaporkan.

Mengotomatiskan pengujian dan mengintegrasikan skrip pengujian ke dalam pipeline CI / CD dikenal sebagai pengujian shift-left. Ini menyiratkan bahwa lebih banyak praktik jaminan kualitas dapat dilakukan dalam fase pengembangan untuk menangkap masalah lebih awal dalam jadwal rilis. Mengotomatiskan pengujian adalah salah satu prioritas pra-penerapan untuk tim tangkas dan pengembang yang ingin meningkatkan frekuensi penerapan.

Saat pengenalan fungsi baru, skrip pengujian yang dibangun memvalidasi kemampuan baru. Tes ini kemudian dapat diotomatiskan dan disertakan dalam langkah membangun atau menerapkan. Alih-alih meminta teknisi QA menjalankan pengujian regresi di akhir proses rilis, Anda dapat menjalankan dan memvalidasi banyak pengujian ini sebagai bagian dari pengembangan. Tes ini bergeser ke kiri dari akhir proses rilis ke fase pengembangan dan pengkodean sebelumnya.

Pengujian shift-kiri memungkinkan komitmen tim yang gesit terhadap kualitas

Pengujian shift-left tidak hanya mendorong efisiensi dan meningkatkan kualitas, tetapi juga menciptakan perubahan budaya yang signifikan dalam proses pengembangan yang gesit.

Beberapa tim pengembangan menganggap jaminan kualitas dan pengujian sebagai penghalang untuk mengirimkan kode mereka ke produksi. Setelah semua kerja keras dalam memuaskan pemilik produk yang gesit dan menyelesaikan kode, rekan tim QA mengidentifikasi daftar bug yang memerlukan perbaikan. Jika QA menemukan banyak bug, hal itu dapat memengaruhi timeline rilis untuk memperbaikinya. Lebih buruk lagi adalah ketika bagian penting dari kode perlu rekayasa ulang karena kekurangan mengekspos masalah logika, keamanan, atau kinerja. Dalam skenario ini, pengembang dan teknisi QA mungkin berada di tim gesit yang sama tetapi tidak bertindak sebagai tim.

Pengujian shift-left memungkinkan tim yang gesit untuk mengalihkan tanggung jawab kualitas ke tim pengembang dan penguji sepenuhnya. Saat pengujian dijalankan sebagai bagian dari pipeline CI / CD, ini memberikan peluang yang lebih baik bagi developer untuk mengatasi masalah kualitas pada saat mereka mengerjakan kode yang relevan. Pipeline CI / CD memberi tahu pengembang tentang build yang gagal, dan sebagian besar tim pengembangan yang mengatur dirinya sendiri perlu segera memperbaiki masalah ini.

Pengujian shift-left juga memberikan kesempatan kepada pengembang dan teknisi QA untuk mengotomatiskan lebih banyak pengujian. Praktik terbaik adalah bagi tim untuk memutuskan siapa yang menerapkan otomatisasi, bergantung pada jenis pengujian yang diperlukan untuk fungsionalitas yang dikembangkan. Misalnya, pengembang sering kali bertanggung jawab untuk mengotomatiskan pengujian unit dan API, tetapi teknisi otomatisasi QA sering kali mengembangkan pengujian pengalaman pengguna ujung ke ujung dan pengujian transaksi yang mensimulasikan panggilan API multistep ke beberapa layanan.

Kapan menerapkan pengujian shift-left

Pengujian shift-left berfungsi paling baik untuk pengujian atomik tingkat unit lainnya yang memiliki waktu eksekusi yang singkat. Sangat penting bahwa pengujian otomatis dalam pipeline CI / CD, dan yang dijalankan setiap kali developer memicu build, jalankan dengan cepat dan tidak memperlambat proses build.

Pengujian yang lebih kompleks dan intensif waktu seperti pengujian pengalaman pengguna ujung ke ujung, pengujian transaksi, analisis kode statis, dan pengujian keamanan sering kali berjalan lebih baik di luar pipeline CI / CD dan pada jadwal harian atau yang lebih sering. Pengujian ini masih memberikan umpan balik awal kepada pengembang tentang masalah kualitas, tetapi dilakukan secara otomatis di luar CI / CD untuk menghindari build yang melambat atau menghambat.

Thomas J. Sweet, VP dalam Layanan TI di GM Financial, berbagi dengan saya wawasan pribadinya tentang batasan strategi pengujian shift-left. Dia menyarankan, “Geser ke kiri selalu merupakan strategi, kecuali saat melakukan pengujian integrasi pada pengiriman vendor pihak ketiga, karena Anda sering tidak memiliki akses ke kode sumber mereka. Meskipun Anda memiliki aplikasi internal dengan arsitektur monolitik lama, Anda dapat mulai dengan menerapkan kebijakan check-in dasar yang memerlukan tinjauan kode dan pemindaian keamanan. Check-in harus ditolak jika pemindaian menyertakan peringatan dan kegagalan penting. "

Salah satu solusi potensial untuk pengujian hilir dengan mitra integrasi adalah dengan menerapkan virtualisasi layanan. Teknik ini memungkinkan tim pengembangan untuk mensimulasikan respons sistem hilir untuk input yang berbeda. Ini bekerja dengan baik ketika sistem hilir didefinisikan dengan baik. Alat dari Micro Focus, Tricentis, dan lainnya memungkinkan kemampuan ini.

Rob Pociluk, manajer jaminan kualitas yang sangat berpengalaman, adalah pendukung kuat pengujian shift-left dalam pengembangan yang gesit. “Bersiap dan dapat menguji bagian-bagian kecil kode membuat QA tetap fleksibel dan selalu mengikuti perkembangan sprint. Tim harus tetap berhati-hati agar tidak terlalu sering menggunakan shift-left karena Anda dapat kehilangan tujuan dari kode itu sendiri. ”

Jadi, meskipun tim sepenuhnya merangkul pengujian shift-left, ada alasan bagus untuk tetap menjadwalkan jendela pengujian pada build lengkap kode yang ditargetkan untuk rilis. Ini memastikan bahwa semua pengujian otomatis dilakukan pada build akhir, tetapi juga memungkinkan penjadwalan pengujian tambahan yang memerlukan sistem yang berfungsi penuh.

Salah satu tes tersebut adalah UAT (pengujian penerimaan pengguna), di mana pengguna akhir dan ahli materi pelajaran terpilih memvalidasi dan memberikan umpan balik. Beberapa UAT dapat dilakukan selama pengembangan, tetapi mungkin tidak mudah membuat orang sering melakukan pengujian ini atau ketika fungsionalitas belum sepenuhnya siap.

Prasyarat untuk strategi pengujian shift-left

Shift-left testing adalah praktik developer yang berkembang, tetapi memiliki prasyarat dan investasi di muka. Beberapa kemampuan dan praktik penting diperlukan.

  • Kapasitas dan lingkungan pengujian yang memadai diperlukan untuk mendukung jumlah build dan pengujian yang berjalan secara bersamaan.
  • Tim Agile memerlukan perangkat pengujian produk yang mudah diintegrasikan ke dalam pipeline CI / CD dan alat penjadwalan pekerjaan, dan yang dapat memvalidasi fungsionalitas, kualitas kode, keamanan, dan kinerja.
  • Arsitek, spesialis infosec, pimpinan QA, dan anggota senior organisasi lainnya harus menetapkan standar pengujian dan tujuan tingkat layanan yang membentuk kriteria penerimaan default.
  • Saat aplikasi memerlukan masukan pengguna, tim penguji memerlukan data dan pola pengujian yang memadai untuk memvalidasi cukup persona, kasus penggunaan, dan pola masukan.
  • Pada komitmen sprint atau sebelumnya, tim scrum, termasuk teknisi otomasi pengujian QA, harus menetapkan strategi pengujian tentang kemampuan apa yang diuji, jenis pengujian apa yang diterapkan, proses otomatisasi apa yang diperbarui, dan siapa yang mengembangkan pengujian.
  • Tim pengembang harus mengukur durasi berjalannya pipeline CI / CD dan menandai saat langkah pengujian otomatis memengaruhi produktivitas. Tim pengembang sering kali memerlukan jadwal pengujian tambahan di luar pipeline CI / CD untuk menjalankan pengujian yang berjalan lebih lama.
  • Tim harus secara teratur mendiskusikan celah dalam pengujian otomatis mereka, terutama validasi yang membutuhkan ahli materi pelajaran, UAT, atau pengujian dengan mitra. Jika tim yang gesit tidak dapat mengatasi celah ini dengan otomatisasi, siklus rilis harus memperhitungkan overhead untuk mengurangi risiko dan menyelesaikan pengujian ini.

Terakhir, tim yang gesit dan organisasi pengembang harus secara teratur mengukur dan mendiskusikan cakupan ujian mereka. Menerapkan strategi pengujian shift-left tidak berhasil jika tim pengembangan dan teknisi otomasi kualitas tidak benar-benar menerapkan, mengotomatiskan, dan mengintegrasikan pengujian yang memadai untuk menangkap masalah dan mengatasi risiko.

Mempercepat siklus rilis atau memungkinkan pengiriman berkelanjutan tanpa otomatisasi pengujian yang memadai dapat mengakibatkan masalah kualitas yang signifikan yang menurunkan pengalaman pengguna akhir. Tim pengembangan yang gesit terlalu sering mendorong rilis, kemudian menemukan diri mereka sendiri menangani masalah produksi dan cacat daripada berinvestasi dalam otomatisasi yang lebih banyak dan lebih baik.