Menjelajahi metode pengujian shift-left
Pengujian dalam manajemen siklus hidup aplikasi sangat penting untuk memaksimalkan kualitas kode dan meminimalkan risiko operasional yang terkait dengan penyebaran dan pembaruan perangkat lunak. Istilah shift-left dalam konteks ini menyampaikan gagasan untuk memindahkan aktivitas pengujian sedini mungkin dalam fase pengembangan. Organisasi dalam skenario sampel kami harus mempertimbangkan untuk menggabungkan pendekatan ini ke dalam strategi DevOps-nya untuk meminimalkan masalah keamanan dan stabilitas saat ini. Dalam unit ini, tinjau berbagai jenis pengujian yang dapat diimplementasikan dengan cara ini dan kemudian periksa metode implementasinya.
Tes apa yang harus menjadi bagian dari pengujian shift-left?
Pengembangan perangkat lunak menggabungkan berbagai jenis pengujian, tetapi yang menarik bagi kami meliputi:
Pengujian unit: Pengujian ini berfokus pada bagian terkecil yang dapat diuji dari kode aplikasi, seperti fungsi atau metode secara individual. Tujuannya adalah untuk menetapkan apakah setiap unit kode dapat berhasil melakukan operasi yang dimaksudkan dalam isolasi dari basis kode dan dependensi eksternal lainnya. Pengujian tersebut harus sepenuhnya otomatis, cepat (selesai dalam waktu 30 detik), dan memberikan cakupan kode penuh (yang pada dasarnya berarti bahwa semua pengujian unit harus secara kolektif menguji seluruh basis kode). Pengujian unit cocok untuk pendekatan shift-left, yaitu strategi menggeser proses pengujian ke tahap lebih awal dalam pengembangan. Sebaiknya terapkan ke semua kode sedini mungkin dalam siklus pengembangan, sebaiknya di awal fase pemrograman.
Smoke tests: Pengujian ini dimaksudkan untuk menilai fungsionalitas inti aplikasi di lingkungan pengujian. Meskipun mereka menguji aplikasi secara keseluruhan (bukan komponen individual yang terisolasi, seperti dalam pengujian unit), tujuan mereka adalah untuk menentukan apakah build atau penyebaran aplikasi cukup stabil untuk menjamin pengujian yang lebih mendalam. Namun, mereka tidak memverifikasi interoperabilitas antar aplikasi. Seperti halnya pengujian unit, pengujian harus sepenuhnya otomatis dan relatif cepat (interaksi pengguna dapat disimulasikan dengan menggunakan alat otomatisasi browser dan kerangka kerja otomatisasi antarmuka pengguna). Istilah uji asap dimaksudkan untuk menyampaikan gagasan asap yang menunjukkan masalah besar (kebakaran) yang harus ditangani sesegera mungkin. Pengujian asap juga harus diimplementasikan di awal siklus pengembangan, sebaiknya segera setelah versi perangkat lunak yang menyediakan fungsionalitas intinya tersedia. Ini berlaku untuk fase build dan penyebaran aplikasi.
Pengujian integrasi: Pengujian ini memvalidasi interaksi antara komponen aplikasi yang berbeda. Tidak seperti pengujian unit, pengujian ini dapat membutuhkan waktu yang cukup lama untuk diselesaikan. Durasi yang diperpanjang dari pengujian ini biasanya digunakan sebagai argumen untuk menjalankannya di awal siklus hidup pengembangan perangkat lunak. Secara umum, Anda harus mempertimbangkan pengujian integrasi dalam skenario yang tidak cocok untuk pengujian unit atau asap. Namun, rekomendasinya adalah menjadwalkannya untuk dijalankan secara berkala. Pendekatan ini menawarkan kompromi yang wajar antara potensi penundaan dalam mendeteksi masalah integrasi dan waktu tunggu tambahan yang diperlukan untuk menyelesaikannya.
Pengujian penerimaan: Pengujian ini menentukan apakah produk perangkat lunak memenuhi persyaratan bisnis dan siap untuk pengiriman kepada konsumennya. Pengujian penerimaan tidak sejalan dengan strategi shift-left, tetapi mungkin saja beberapa elemennya dapat diintegrasikan lebih awal dalam siklus hidup pengembangan perangkat lunak. Misalnya, kriteria penerimaan dan cerita pengguna, yang merupakan komponen penting dari pengujian penerimaan, harus diperkenalkan di awal proses pengembangan. Ini memfasilitasi kolaborasi antara tim pengembangan, pemilik produk, dan pemangku kepentingan proyek. Selain itu, konsumen perangkat lunak dan pemangku kepentingan proyek harus terlibat dalam fase pengujian sebelumnya untuk berbagi umpan balik mereka. Ini mungkin melibatkan penggunaan metode seperti pengujian alfa atau beta, pengujian kegunaan, atau rilis awal, sebelum pengujian penerimaan formal.