Apa itu pengujian shift-left?

Pernahkah Anda terlibat dalam proyek perangkat lunak yang melebihi anggaran dan melewati setiap tenggat waktu? Anda dan kita semua pernah mengalaminya. 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 belajar pentingnya bekerja ke belakang mulai dari tenggat waktu. Jika suatu proyek memiliki tenggat waktu tertentu dan pengujian akan memakan waktu tertentu, maka dengan informasi itu, kita dapat bekerja mundur 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 waktu untuk pengujian QA sangat bagus dalam teori tetapi dengan cepat berantakan dalam praktik ketika bug atau cacat pertama diidentifikasi.

Berapa lama cacat ini akan diperbaiki? Seberapa besar pengaruhnya terhadap lini masa? Apakah bug baru akan diperkenalkan? Bagaimana kami akan memastikan bahwa setiap perbaikan Verify dengan waktu untuk memperbaiki apa pun yang kami 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 terakhir. Saya belajar untuk tidak menjadwalkan agenda apa pun selama beberapa minggu setelah peluncuran penting. Pendekatan ini memungkinkan saya untuk mengidentifikasi masalah apa pun yang terlewatkan (atau muncul) dalam upaya terburu-buru kami menuju garis finish.

Masalahnya, pada akhirnya, bukanlah pada waktu yang tersedia untuk pengujian melainkan 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” menjadi jelas. Sederhananya, ini adalah praktik pengujian tahap awal, yang melibatkan anggota tim, termasuk penguji, pengembang, dan pemangku kepentingan dalam strategi pengujian. Selain itu, proses ini melibatkan pengintegrasian pengujian untuk fitur yang ada dan baru lebih sering dalam siklus 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 tingkat tinggi. 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 industri, kami telah belajar bahwa ketika Anda membiarkan semua validasi Anda sampai akhir proyek yang kompleks, Anda sebenarnya 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 dibangun ke dalam model V: verifikasi dan validasi. Kedua label ini penting.

Kita perlu memvalidasi bahwa persyaratan pengguna kita memecahkan masalah yang ingin kita pecahkan. Kita juga perlu memverifikasi bahwa implementasi kita sesuai dengan spesifikasi yang didapatkan dari persyaratan pengguna tersebut.

Pengujian otomatis dapat diterapkan pada validasi dan verifikasi. Desain berbasis perilaku (BDD) telah mengarah pada penciptaan 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 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.

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 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 memverifikasi fungsionalitas lengkap aplikasi dari lapisan antarmuka pengguna. Alat seperti Selenium membuat pengujian UI otomatis dapat diakses secara luas.

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 uji dapat melakukan yang lebih baik ketika mereka memiliki pemahaman yang lebih besar tentang implementasi secara keseluruhan, dan insight mereka dapat membantu membuat arsitektur lebih terbuka 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.

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, kita harus fokus pada pengujian API dan kontrak. Pengujian API memiliki beberapa manfaat:

• Pengujian API dapat mencegah salah satu cara paling umum untuk memperkenalkan kesalahan dalam aplikasi layanan mikro: mengubah ketergantungan yang tidak sinkron dengan layanan hulu atau hilirnya.
   

• 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 lebih banyak infrastruktur.

Bagaimana jika kita dapat menggunakan pengujian API berkelanjutan yang terintegrasi 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:

1. Keterlibatan awal: Kegiatan pengujian harus dimulai sedini mungkin dalam proses pengembangan. Penguji harus dilibatkan dari fase pengumpulan persyaratan untuk memahami ruang lingkup proyek, tujuan, dan harapan pengguna.
    

2. 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.
    

3. 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.
    

4. Pengembangan yang didorong pengujian (TDD): Dorong praktik TDD, agar pengembang dapat menulis contoh uji sebelum menulis kode yang sebenarnya. Pendekatan pengujian shift-left ini membantu dalam mendefinisikan perilaku yang diinginkan dan hasil yang diharapkan di muka, yang mengarah ke kode yang lebih kuat dan dapat diuji.
    

5. 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.
    

6. 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.
    

7. Pengujian eksploratif: Di samping pengujian otomatis, dorong pengujian eksploratif untuk menjelajahi aplikasi dari perspektif pengguna. Penguji yang terampil dapat mengidentifikasi potensi masalah kegunaan, kasus tepi, dan skenario yang mungkin terlewatkan oleh pengujian otomatis.
    

8. 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.
    

9. 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.
    

10. 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 terbaik ini, tim yang tangkas dapat mencapai kolaborasi yang lebih baik,masukan yang lebih cepat, dan produk piranti lunak berkualitas tinggi 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.

Cacat yang ditemukan oleh pengujian unit otomatis pada mesin lokal pengembang lebih murah untuk diidentifikasi dan diperbaiki. Tetapi ketika cacat telah sampai ke lingkungan yang menghadap pelanggan, biaya untuk perbaikan meningkat.

Jika dilakukan dengan benar, pengujian otomatis dan CI dapat memberikan kepercayaan diri yang dibutuhkan oleh para insinyur perangkat lunak untuk menerapkan aplikasi sesering mungkin—bahkan pada hari Jumat. Menemukan cacat lebih cepat berarti lebih sedikit momen penuh kepanikan. Karena rilis sangat tidak menyakitkan, memperbaiki beberapa kesalahan yang berhasil melewatinya lebih cepat dan lebih mudah juga.

Karena perangkat lunak yang lebih mudah diakses lebih mudah digunakan untuk kita semua, perangkat lunak yang lebih dapat diuji dapat lebih mudah untuk dipertimbangkan dan dipelihara. Memikirkan pengujian lebih awal dapat membantu pemisahan perhatian yang lebih baik dan arsitektur keseluruhan yang lebih tangguh.

Meningkatkan pengalaman pelanggan adalah tujuan kami. Shift-left dapat menghilangkan beberapa insiden yang mungkin dialami pengguna dan mengurangi dampak insiden lainnya. Kita dapat menggunakan observabilitas untuk menyelesaikan loop masukan ini dan meningkatkan kesehatan perangkat lunak kita secara keseluruhan.

Dengan alat otomatisasi canggih yang ada, kita mungkin ingin menerapkan setiap jenis pengujian pada setiap baris kode. Pendekatan ini adalah jalan yang berbahaya.

Menguji efek samping—apakah catatan itu disimpan ke basis data? —adalah sebuah ide yang menarik. Tetapi pengujian detail implementasi adalah anti-pola karena jenis tes ini rapuh. Detailnya 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. Meskipun mungkin tampak 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.