Pengujian shift-left adalah pendekatan dalam pengembangan perangkat lunak yang menekankan pada pemindahan aktivitas pengujian lebih awal dalam proses pengembangan untuk meningkatkan kualitas perangkat lunak, cakupan pengujian yang lebih baik, umpan balik yang berkesinambungan, dan waktu ke pasar yang lebih cepat.
Pernahkah Anda terlibat dalam proyek perangkat lunak yang melebihi anggaran dan melewati setiap tenggat waktu? Tentu saja, pernah–kita semua pasti pernah. Faktanya, jika Anda belum mengalaminya, Anda pasti satu dari seratus juta orang dan saya ingin mendengar kisah Anda.
Di tahap awal dalam karier pengembangan perangkat lunak saya, saya belajar pentingnya bekerja ke belakang mulai dari tenggat waktu. Jika sebuah proyek harus selesai pada tanggal tertentu dan pengujian akan memakan waktu tertentu, maka kita dapat menggunakan informasi tersebut untuk bekerja ke belakang dan memilih tanggal jatuh tempo untuk proyek kita. Sempurna, bukan?
Yah, tidak juga. Meskipun mengerjakannya tepat waktu untuk pengujian manual mengurangi tekanan pada hari-hari terakhir proyek, masih ada terlalu banyak kejutan.
Membangun aplikasi tepat waktu untuk pengujian QA memang bagus secara teori, tetapi semuanya akan berantakan dalam praktiknya begitu bug atau cacat pertama teridentifikasi.
Berapa lama cacat ini akan diperbaiki? Seberapa besar pengaruhnya terhadap lini masa? Apakah bug baru akan diperkenalkan? Bagaimana kami memastikan setiap perbaikan diverifikasi dengan waktu yang tepat untuk memperbaiki apa pun yang rusak saat kami memperbaiki hal pertama?
Pada akhirnya, saya tidak pernah dapat menemukan durasi waktu yang tepat untuk dialokasikan untuk QA. Tak pelak lagi, perbaikan yang terburu-buru digabungkan pada menit-menit terakhir; saya belajar untuk mengosongkan kalender saya selama beberapa minggu setelah peluncuran besar, sehingga saya bisa melakukan triase terhadap semua masalah yang terlewatkan (atau muncul) dalam kesibukan kami untuk menyelesaikannya.
Masalahnya, pada akhirnya, bukanlah waktu yang tersedia untuk pengujian melainkan penentuan waktu pengujian. Saya perlu melakukan pengujian lebih awal dan lebih sering. Saya perlu pengujian shift-left.
Jika kita membayangkan proses pengembangan perangkat lunak kita sebagai garis waktu yang mengalir dari kiri ke kanan, maka "pengujian shift-left" tak perlu dijelaskan lagi. Sederhananya, ini adalah praktik pengujian tahap awal, yang melibatkan anggota tim, termasuk penguji, pengembang, dan pemangku kepentingan dalam strategi pengujian, serta mengintegrasikan pengujian untuk fitur yang sudah ada dan fitur baru lebih sering dalam siklus hidup pengembangan.
Model-V adalah cara yang bermanfaat untuk membuat konsep siklus pengembangan perangkat lunak. Jika kita mengambil aliran air terjun tradisional dan “membalik” sumbu Y pada fase implementasi, kita mendapatkan model-V.
Siklus pengembangan dimulai dengan persyaratan umum. Persyaratan ini dipersempit dengan setiap langkah berurutan ke bawah "V" sampai kita mencapai implementasi tingkat kode itu sendiri. Kami kemudian memverifikasi implementasinya, dimulai dengan pengujian unit yang paling terperinci dan terus meningkat hingga ke pengujian penerimaan pengguna yang lebih abstrak.
Dalam proses air terjun, seluruh proyek terdiri dari satu "V." Sebagai sebuah industri, kami telah belajar bahwa ketika Anda membiarkan semua validasi Anda sampai akhir proyek yang kompleks, pada dasarnya Anda menyiapkan diri Anda untuk gagal.
Dalam proses yang berulang, kita dapat menganggap setiap putaran atau ulangan sebagai “V” yang lebih kecil Kami secara teoretis telah mencapai tujuan shift-left kami: pengujian lebih cepat dan lebih sering. Masalah terpecahkan, bukan? Yah, tidak juga.
Anda mungkin telah memperhatikan bahwa ada dua label pada saluran masukan yang ada di dalam model V: verifikasi dan validasi. Keduanya sama-sama penting.
Kita perlu memvalidasi bahwa persyaratan pengguna kita benar-benar memecahkan masalah yang ingin kita selesaikan. Kita juga perlu memverifikasi bahwa implementasi kita sesuai dengan spesifikasi yang didapatkan dari persyaratan pengguna tersebut.
Pengujian otomatis dapat diterapkan pada validasi dan verifikasi. BDD (Behavior Driven Design) telah menghasilkan teknologi seperti Cucumber yang dapat mengotomatiskan beberapa bagian dari proses validasi. Untuk tujuan artikel ini, kami akan berfokus pada pengujian otomatis untuk verifikasi.
Pengujian unit
Pengujian unit memverifikasi fungsionalitas modul tertentu dalam aplikasi yang lebih besar. Modul diuji secara terpisah, dan komunikasi apa pun dengan proses eksternal lainnya disimulasikan atau direkayasa. Pengujian unit dan TDD mewakili fase pengembangan pertama dalam pengujian shift-kiri.
Pengujian integrasi
Uji integrasi mencoba memverifikasi fungsionalitas keseluruhan layanan atau aplikasi, termasuk efek samping. Proses ini adalah anti-pola karena alasan yang akan kita bahas nanti.
Pengujian API dan pengujian kontrak
Pengujian API memverifikasi titik akhir eksternal dari satu layanan. Cakupan pengujian API mirip dengan cakupan pengujian integrasi; Namun, dalam konteks SOA atau layanan mikro, kita dapat menganggap pengujian API sebagai pengujian unit yang baru.
Pengujian UI
Pengujian UI memverifikasi fungsionalitas lengkap aplikasi dari lapisan antarmuka pengguna. Alat seperti Selenium membuat pengujian UI otomatis dapat diakses secara luas.
Lebih dari sekadar otomatisasi
Shift-left bukan hanya tentang otomatisasi. Cara lain untuk menguji lebih awal dan lebih sering adalah dengan memastikan bahwa spesialis QA Anda terlibat dalam setiap langkah proses Anda, mulai dari penemuan dan pengumpulan persyaratan. Teknisi pengujian dapat bekerja lebih baik jika mereka memiliki pemahaman yang lebih baik tentang implementasi secara keseluruhan, dan insight mereka dapat membantu membuat arsitektur menjadi lebih transparan dan tangguh.
Ketika kita berpikir untuk menguji “lebih cepat dan lebih sering”, kata tertentu muncul di benak kita: terus-menerus. Banyak (sebagian besar) tim pengembangan perangkat lunak mempraktikkan beberapa bentuk integrasi berkelanjutan dan pengiriman berkelanjutan. Pengujian berkelanjutan adalah siklus berulang masukan penting dalam siklus DevOps ini.
Pengujian berkelanjutan
Jika kita menganggap TDD sebagai "shift-left untuk monolit", maka pengujian berkelanjutan adalah "shift-left untuk arsitektur terdistribusi".
TDD membuat kami berfokus pada pengujian unit. Untuk pengujian berkelanjutan, kami harus berfokus pada tes API dan kontrak. Pengujian API memiliki sejumlah manfaat:
Uji API dapat mencegah salah satu cara paling umum untuk menimbulkan kesalahan dalam aplikasi layanan mikro: mengubah dependensi yang tidak sinkron dengan layanan hulu atau hilir.
Pengujian API dapat dimiliki oleh tim yang sama yang memiliki layanan.
Tes API menghindari kerentanan efek samping pengujian dan detail implementasinya.
Idealnya, pengujian API ini akan dijalankan terus-menerus terhadap lingkungan produksi dan pra-produksi. Alat pengujian kontrak dapat membantu mengotomatiskan proses ini, tetapi itu membutuhkan infrastruktur tambahan.
Bagaimana jika kita dapat menggunakan pengujian API berkelanjutan yang dibangun ke dalam alat observabilitas kita? Fitur pengujian API sintetis yang akan datang dari Instana akan memungkinkan Anda untuk terus menjalankan pengujian API terhadap semua lingkungan Anda dengan sedikit upaya.
Shift-left melibatkan pemindahan aktivitas pengujian lebih dekat ke awal siklus pengembangan perangkat lunak, sehingga masukan diperoleh lebih cepat dan mengurangi waktu dan upaya yang diperlukan untuk memperbaiki bug. Berikut beberapa praktik terbaik untuk pengujian shift-left dalam pengembangan tangkas:
Keterlibatan awal: Kegiatan pengujian harus dimulai sedini mungkin dalam proses pengembangan. Penguji harus dilibatkan sejak tahap pengumpulan persyaratan untuk memahami ruang lingkup proyek, tujuan, dan ekspektasi pengguna.
Kolaborasi dan komunikasi: Bangun kolaborasi dan komunikasi yang erat antara pengembang, penguji, dan pemangku kepentingan lainnya. Dorong pelaksanaan rapat harian, sesi perencanaan singkat, dan retrospeksi rutin untuk memastikan pemahaman dan keselarasan bersama.
Otomatisasi pengujian: Manfaatkan otomatisasi pengujian sehingga pengujian dapat lebih sering dilakukan dan efisien. Uji otomatis harus dibuat bersamaan dengan proses pengembangan dan diintegrasikan ke dalam jalur integrasi dan penerapan yang berkelanjutan. Ini membantu dalam mendeteksi cacat lebih awal, mengurangi masalah regresi, dan mempercepat siklus masukan.
Pengembangan yang didorong pengujian (TDD): Mendorong praktik TDD, agar pengembang dapat menulis contoh uji sebelum menulis kode yang sebenarnya. Pendekatan pengujian shift-left ini membantu mendefinisikan perilaku yang diinginkan dan hasil yang diharapkan di awal, sehingga menghasilkan kode yang lebih andal dan dapat diuji.
Integrasi berkelanjutan dan pelaksanaan berkelanjutan (CI/CD): Terapkan pipeline CI/CD untuk mengotomatiskan proses pembuatan, pengujian, dan penerapan. Praktik ini memastikan bahwa setiap perubahan kode diuji secara menyeluruh dan diterapkan ke lingkungan produksi dengan cepat dan sering, sehingga mengurangi risiko masalah integrasi.
Pengujian keamanan shift-left: Pertimbangkan untuk mengintegrasikan praktik pengujian keamanan di awal proses pengembangan. Lakukan tinjauan kode keamanan, analisis kode statis, dan pengujian yang berfokus pada keamanan untuk mengidentifikasi kerentanan dan mengatasinya secara proaktif.
Pengujian eksploratif: Di samping pengujian otomatis, dorong pengujian eksploratif untuk menjelajahi aplikasi dari perspektif pengguna. Penguji yang terampil dapat mengidentifikasi potensi masalah kegunaan, kasus unik, dan skenario yang mungkin terlewatkan oleh pengujian otomatis.
Pengujian kinerja: Lakukan pengujian kinerja lebih awal untuk mengidentifikasi potensi hambatan dan masalah skalabilitas. Ini membantu dalam mengoptimalkan kinerja aplikasi dan memastikan bahwa aplikasi memenuhi kriteria kinerja yang diperlukan.
Lingkungan dan data pengujian: Penyediaan lingkungan pengujian yang sangat mirip dengan lingkungan produksi untuk memastikan pengujian perangkat lunak yang realistis. Pastikan juga data pengujian yang cukup dan representatif tersedia untuk menyimulasikan skenario dunia nyata.
Pembelajaran dan peningkatan berkelanjutan: Menumbuhkan budaya pembelajaran dan peningkatan yang berkelanjutan. Dorong retrospeksi rutin untuk merefleksikan proses pengujian, mengidentifikasi hambatan, dan mengimplementasikan perubahan untuk meningkatkan efektivitas pengujian shift-left.
Dengan menerapkan praktik-praktik terbaik ini, tim yang tangkas dapat mencapai kolaborasi yang lebih baik, masuk yang lebih cepat, dan produk perangkat lunak yang lebih berkualitas melalui pengujian shift-left.
Siklus masukan yang lebih pendek yang diterapkan ke dalam proses shift-left memberdayakan kami dalam beberapa cara. Antara lain, cacat dapat ditemukan lebih cepat, perbaikan dapat diterapkan lebih efisien, dan pelajaran yang dipetik dalam satu iterasi dapat diterapkan di iterasi berikutnya.
Apa pun metodologi manajemen proyek atau siklus rilis yang dimiliki tim Anda, Anda bisa mendapatkan manfaat dari siklus masukan verifikasi yang lebih pendek dari pengujian shift-left.
Penghematan biaya
Cacat yang ditemukan oleh pengujian unit otomatis pada mesin lokal pengembang lebih murah untuk diidentifikasi dan diperbaiki. Namun, ketika cacat telah sampai ke lingkungan sisi pelanggan, biaya untuk memperbaikinya meningkat.
Kesejahteraan pengembang
Jika dilakukan dengan benar, pengujian otomatis dan CI dapat memberikan kepercayaan diri yang dibutuhkan oleh para insinyur perangkat lunak untuk mengirimkan aplikasi sesering mungkin—bahkan pada hari Jumat. Menemukan cacat lebih cepat berarti lebih sedikit momen penuh kepanikan. Karena rilis sangatlah mudah dilakukan, memperbaiki beberapa kesalahan yang berhasil lolos juga lebih cepat dan lebih mudah.
Arsitektur yang tangguh
Perangkat lunak yang lebih mudah diakses biasanya lebih mudah digunakan oleh kita semua. Demikian pula perangkat lunak yang lebih teruji akan lebih mudah untuk dipikirkan dan dipelihara. Memikirkan pengujian lebih awal dapat membantu pemisahan perhatian yang lebih baik dan arsitektur keseluruhan yang lebih tangguh.
Kualitas keseluruhan yang lebih baik
Meningkatkan pengalaman pelanggan adalah tujuan akhir kami. Shift-left dapat menghilangkan beberapa insiden yang mungkin dialami pengguna akhir dan mengurangi dampak insiden lainnya. Kami dapat menggunakan observabilitas untuk menyelesaikan siklus masukan ini dan meningkatkan kesehatan perangkat lunak kami secara keseluruhan.
Dengan alat otomatisasi canggih yang ada, kita mungkin ingin menerapkan setiap jenis pengujian pada setiap baris kode. Ini adalah jalan yang berbahaya.
Menguji efek samping—apakah catatan benar-benar disimpan ke database?—adalah sebuah ide yang menarik. Tetapi pengujian detail implementasi merupakan anti-pola karena jenis pengujian ini sangat rapuh. Pengujian ini mungkin perlu diubah setiap kali aplikasi Anda berubah. Antarmuka pengguna juga merupakan detail implementasi, sehingga pengujian UI juga sama.
Uji verifikasi berfokus semata pada “apa,” bukan “bagaimana” atau “mengapa.” Idealnya, persyaratan pengguna telah dirancang untuk memvalidasi “mengapa.” Untuk menjawab “bagaimana”, kita dapat mengandalkan otomatisasi yang lebih kuat dalam bentuk platform observabilitas.
Pengujian shift-right adalah praktik pengujian di akhir proses pengembangan, biasanya di lingkungan produksi. Meski mungkin terdengar aneh, pengujian shift-left dan shift-right saling melengkapi.
Pengujian shift-right memungkinkan kami mengidentifikasi masalah produksi sebelum pelanggan kami mengalaminya. Siklus masukan yang lebih pendek dari pengujian shift-left memberi kami kemampuan untuk menanggapi dan memperbaiki masalah produksi ini dengan cepat.
Pengujian API sintetis sebagai bagian dari platform observabilitas Anda adalah cara yang sempurna untuk menggabungkan manfaat dari praktik shift-left dan shift-right.
Meningkatkan fungsionalitas dan observabilitas di APM perusahaan Anda; meningkatkan manajemen kinerja aplikasi dan percepat jalur CI/CD di mana pun aplikasi berada.
Cari tahu bagaimana observabilitas memberikan visibilitas mendalam terhadap aplikasi terdistribusi modern untuk proses identifikasi dan penyelesaian masalah yang lebih cepat dan otomatis.
Baca bagaimana pengujian berkelanjutan berperan penting dalam mempercepat pengembangan perangkat lunak, meningkatkan kualitas kode, dan menghindari kemacetan yang merugikan.
Jelajahi bagaimana DevOps mempercepat pengiriman perangkat lunak berkualitas tinggi dengan menggabungkan dan mengotomatiskan pekerjaan pengembangan perangkat lunak dan tim operasi TI.
Pelajari semua yang perlu Anda ketahui tentang pemantauan sintetis termasuk apa itu pemantauan sintetis, cara menggunakannya, tantangannya, dan banyak lagi.
Pelajari bagaimana penerapan teknologi, program, robotika, atau proses dapat membantu mencapai hasil dengan input manusia yang minimal.
Memprediksi dan mencegah masalah kinerja sebelum berdampak pada bisnis Anda dengan manajemen kinerja aplikasi.