Jalan Menuju Pengujian Agile yang Lebih Baik

Laporan Kualitas Dunia tahunan yang dibuat oleh Capgemini menunjukkan bahwa 42% responden survei mencantumkan “kurangnya keahlian pengujian profesional” sebagai tantangan dalam menerapkan pengujian pada pengembangan Agile. Sementara munculnya Agile telah membawa peningkatan kecepatan iterasi untuk pengembangan perangkat lunak, dalam beberapa kasus, ini datang dengan mengorbankan kualitas.

Persaingan yang ketat menekan tim untuk terus-menerus memberikan pembaruan produk baru, tetapi ini terkadang datang dengan biaya sendiri, termasuk penurunan perhatian terhadap pengujian. Beberapa, seperti Rob Mason, melangkah lebih jauh dan berpendapat bahwa Agile membunuh pengujian perangkat lunak. Baru-baru ini, Facebook telah mengubah motonya dari "bergerak cepat dan menghancurkan segalanya" menjadi "bergerak cepat dengan infrastruktur yang stabil" dalam upaya untuk menyelesaikan godaan untuk mengorbankan kualitas.

Jadi, bagaimana pengujian dapat diintegrasikan dengan lebih baik ke dalam dunia baru pengembangan perangkat lunak Agile? Pengujian tangkas.

Pengujian tradisional cukup rumit dan tergantung pada banyak dokumentasi. Pengujian Agile adalah pendekatan untuk proses pengujian yang meniru prinsip-prinsip pengembangan perangkat lunak Agile dimana:

• Pengujian dilakukan lebih sering,
• Pengujian kurang bergantung pada dokumentasi dan lebih banyak pada kolaborasi anggota tim, dan
• Beberapa aktivitas pengujian dilakukan tidak hanya oleh penguji tetapi juga oleh pengembang.

Selama tujuh tahun terakhir, saya telah mentransisikan banyak tim ke pengujian Agile dan bekerja berdampingan dengan penguji untuk membantu proses mereka sesuai dengan metodologi baru. Dalam artikel ini, saya akan membagikan beberapa tip paling berdampak yang telah saya pelajari di sepanjang jalan saya menuju pengujian Agile yang lebih baik. Meskipun wajar jika ada gesekan antara kecepatan dan kualitas dalam praktik Agile, artikel ini akan membahas beberapa teknik yang dapat digunakan untuk meningkatkan kualitas pengujian tanpa mengurangi kelincahan. Sebagian besar saran yang diuraikan di sini akan memerlukan keterlibatan dari tim sehingga akan bermanfaat jika pengembang dan penguji berpartisipasi dalam perencanaan.

Meresmikan Proses Siklus Uji Rilis

Satu masalah dengan pengujian adalah tidak adanya siklus pengujian rilis, tidak ada jadwal rilis, atau permintaan pengujian yang tidak teratur. Permintaan pengujian sesuai permintaan membuat proses QA menjadi sulit, terutama jika penguji menangani banyak proyek.

Banyak tim hanya melakukan satu build setelah setiap sprint, yang tidak ideal untuk proyek Agile. Pindah ke rilis seminggu sekali bisa bermanfaat, secara bertahap beralih ke beberapa versi per minggu. Idealnya, pembangunan dan pengujian pengembangan harus dilakukan setiap hari, artinya pengembang memasukkan kode ke repositori setiap hari dan pembangunan dijadwalkan untuk berjalan pada waktu tertentu. Untuk mengambil satu langkah lebih jauh, pengembang akan dapat menerapkan kode baru sesuai permintaan. Untuk mengimplementasikan ini, tim dapat menggunakan proses continuous integration dan continuous deployment (CI/CD). CI/CD membatasi kemungkinan build yang gagal pada hari rilis mayor.

Ketika CI/CD dan otomatisasi pengujian digabungkan, deteksi dini terhadap bug kritis dimungkinkan, memungkinkan pengembang memiliki cukup waktu untuk memperbaiki bug kritis sebelum rilis klien yang dijadwalkan. Salah satu prinsip Agile menyatakan bahwa perangkat lunak yang berfungsi adalah ukuran utama kemajuan. Dalam konteks ini, siklus rilis formal membuat proses pengujian lebih gesit.

Berdayakan Penguji dengan Alat Penerapan

Salah satu titik gesekan umum untuk pengujian adalah memiliki kode yang dikerahkan ke lingkungan pementasan. Proses ini bergantung pada infrastruktur teknis yang mungkin tidak dapat dipengaruhi oleh tim Anda. Namun, jika ada beberapa fleksibilitas, alat dapat dibuat untuk orang non-teknis seperti penguji atau manajer proyek yang memungkinkan mereka untuk menyebarkan basis kode yang diperbarui untuk pengujian sendiri.

Misalnya, di salah satu tim saya, kami menggunakan Git untuk kontrol versi dan Slack untuk komunikasi. Pengembang membuat Slackbot yang memiliki akses ke Git, skrip penerapan, dan satu mesin virtual. Penguji dapat melakukan ping ke bot dengan nama cabang yang diperoleh dari GitHub atau Jira dan menerapkannya di lingkungan pementasan.

Penyiapan ini membebaskan banyak waktu bagi pengembang sekaligus mengurangi pemborosan komunikasi dan interupsi terus-menerus saat penguji harus meminta pengembang untuk menerapkan cabang untuk pengujian.

Bereksperimenlah dengan TDD dan ATDD

Test-driven development (TDD) adalah jenis proses pengembangan perangkat lunak yang memberikan banyak penekanan pada kualitas. Secara tradisional, pengembang menulis kode dan kemudian seseorang mengujinya dan melaporkan jika ada bug yang ditemukan. Di TDD, pengembang menulis pengujian unit terlebih dahulu bahkan sebelum menulis kode apa pun yang akan menyelesaikan cerita pengguna. Tes awalnya gagal sampai pengembang menulis jumlah kode minimal untuk lulus tes. Setelah itu, kode di-refactored untuk memenuhi persyaratan kualitas tim.

Pengembangan berbasis tes penerimaan (ATDD) mengikuti logika yang sama seperti TDD tetapi, seperti namanya, berfokus pada tes penerimaan. Dalam hal ini, tes penerimaan dibuat sebelum pengembangan bekerja sama dengan pengembang, penguji, dan pemohon (klien, pemilik produk, analis bisnis, dll.). Tes ini membantu semua orang di tim memahami persyaratan klien sebelum kode apa pun ditulis.

Teknik seperti TDD dan ATDD membuat pengujian lebih gesit dengan memindahkan prosedur pengujian ke tahap awal siklus hidup pengembangan. Saat menulis skenario pengujian sejak awal, pengembang perlu memahami persyaratan dengan sangat baik. Ini meminimalkan pembuatan kode yang tidak perlu dan juga menyelesaikan ketidakpastian produk di awal siklus pengembangan. Ketika pertanyaan atau konflik produk muncul hanya pada tahap selanjutnya, waktu dan biaya pengembangan meningkat.

Temukan Inefisiensi dengan Melacak Pergerakan Kartu Tugas

Di salah satu tim saya, kami memiliki pengembang yang sangat cepat, terutama dengan fitur kecil. Dia akan mendapatkan banyak komentar selama tinjauan kode, tetapi master Scrum kami dan saya menulisnya sebagai kurangnya pengalaman. Namun, saat ia mulai mengkodekan fitur yang lebih kompleks, masalahnya menjadi lebih jelas. Dia telah mengembangkan pola melewati kode untuk pengujian sebelum sepenuhnya siap. Pola ini biasanya berkembang ketika ada kurangnya transparansi dalam proses pengembangan—misalnya, tidak jelas berapa banyak waktu yang dihabiskan orang yang berbeda untuk tugas yang diberikan.

Terkadang, pengembang terburu-buru bekerja dalam upaya untuk mengeluarkan fitur sesegera mungkin dan "mengalihdayakan" kualitas ke penguji. Pengaturan seperti itu hanya memindahkan hambatan lebih jauh ke bawah sprint. Jaminan kualitas (QA) adalah jaring pengaman terpenting yang dimiliki tim, tetapi itu dapat berarti bahwa keberadaan QA memberi pengembang kemampuan untuk mengabaikan pertimbangan kualitas.

Banyak alat manajemen proyek modern memiliki kemampuan untuk melacak pergerakan kartu tugas pada papan Scrum atau Kanban. Dalam kasus kami, kami menggunakan Jira untuk menganalisis apa yang terjadi dengan tugas pengembang yang bersangkutan dan membuat perbandingan dengan pengembang lain dalam tim. Kami menemukan bahwa:

• Tugasnya menghabiskan hampir dua kali jumlah waktu di kolom pengujian papan kami;
• Tugasnya akan jauh lebih sering dikembalikan dari QA untuk perbaikan putaran kedua atau ketiga.

Jadi selain penguji harus menghabiskan lebih banyak waktu untuk tugasnya, mereka juga harus melakukannya berkali-kali. Proses buram kami membuatnya tampak seperti pengembang sangat cepat; namun, itu terbukti salah ketika kami memperhitungkan waktu pengujian. Memindahkan cerita pengguna bolak-balik jelas bukan pendekatan yang ramping.

Untuk mengatasi ini, kami memulai dengan berdiskusi jujur ​​dengan pengembang ini. Dalam kasus kami, dia sama sekali tidak menyadari betapa merusak pola kerjanya. Itu hanya cara dia terbiasa bekerja di perusahaan sebelumnya, yang memiliki persyaratan kualitas yang lebih rendah dan kumpulan penguji yang lebih besar. Setelah percakapan kami dan dengan bantuan beberapa sesi pemrograman berpasangan dengan master Scrum kami, dia secara bertahap beralih ke pendekatan pengembangan yang lebih berkualitas. Karena kemampuan pengkodeannya yang cepat, dia masih berkinerja tinggi, tetapi "pemborosan" yang dihilangkan dari proses QA membuat seluruh proses pengujian jauh lebih gesit.

Tambahkan Otomasi Tes ke Skillset Tim QA

Pengujian dalam proyek non-Agile melibatkan aktivitas seperti analisis pengujian, desain pengujian, dan pelaksanaan pengujian. Kegiatan ini berurutan dan memerlukan dokumentasi yang ekstensif. Ketika sebuah perusahaan bertransisi ke Agile, lebih sering daripada tidak, transisi sebagian besar berfokus pada pengembang dan tidak terlalu pada penguji. Mereka berhenti membuat dokumentasi ekstensif (pilar pengujian tradisional) tetapi terus melakukan pengujian manual. Namun, pengujian manual lambat dan biasanya tidak dapat mengatasi putaran umpan balik cepat dari Agile.

Otomatisasi pengujian adalah solusi populer untuk masalah ini. Pengujian otomatis membuatnya lebih mudah untuk menguji fitur baru dan kecil, karena kode pengujian dapat berjalan di latar belakang sementara pengembang dan penguji fokus pada tugas lain. Selain itu, karena pengujian dijalankan secara otomatis, cakupan pengujian dapat jauh lebih besar dibandingkan dengan upaya pengujian manual.

Tes otomatis adalah potongan kode perangkat lunak yang mirip dengan basis kode yang sedang diuji. Ini berarti bahwa orang yang menulis tes otomatis akan membutuhkan keterampilan teknis agar berhasil. Ada banyak variasi berbeda tentang bagaimana pengujian otomatis diterapkan di berbagai tim. Terkadang pengembang sendiri mengambil peran sebagai penguji dan meningkatkan basis kode pengujian dengan setiap fitur baru. Di tim lain, penguji manual belajar menggunakan alat otomatisasi pengujian atau penguji teknis berpengalaman dipekerjakan untuk mengotomatisasi proses pengujian. Apa pun jalur yang diambil tim, otomatisasi menghasilkan pengujian yang jauh lebih gesit.

Kelola Prioritas Pengujian

Dengan pengembangan perangkat lunak non-Agile, penguji biasanya dialokasikan berdasarkan per proyek. Namun, dengan munculnya Agile dan Scrum, sudah menjadi hal biasa bagi para profesional QA yang sama untuk beroperasi di beberapa proyek. Tanggung jawab yang tumpang tindih ini dapat menciptakan konflik dalam jadwal dan menyebabkan penguji melewatkan upacara penting saat penguji memprioritaskan pengujian rilis satu tim di atas sesi perencanaan sprint lainnya.

Alasan mengapa penguji terkadang mengerjakan banyak proyek sudah jelas—jarang ada aliran tugas yang konstan untuk pengujian untuk mengisi peran penuh waktu. Oleh karena itu, mungkin sulit untuk meyakinkan pemangku kepentingan untuk memiliki sumber daya pengujian khusus yang dialokasikan untuk sebuah tim. Namun, ada beberapa tugas wajar yang dapat dilakukan penguji untuk mengisi waktu henti mereka saat tidak terlibat dalam aktivitas pengujian.

Dukungan Klien

Satu pengaturan yang mungkin adalah meminta penguji menghabiskan waktu henti sprint mereka untuk membantu tim dukungan klien. Dengan terus-menerus menghadapi masalah yang dimiliki klien, penguji memiliki pemahaman yang lebih baik tentang pengalaman pengguna dan cara meningkatkannya. Mereka mampu berkontribusi pada diskusi selama sesi perencanaan. Selain itu, mereka menjadi lebih perhatian selama aktivitas pengujian mereka karena mereka lebih terbiasa dengan bagaimana klien benar-benar menggunakan perangkat lunak mereka.

Manajemen Produk

Teknik lain untuk mengelola prioritas penguji adalah dengan menjadikan mereka sebagai manajer produk junior yang melakukan pengujian manual. Ini juga merupakan solusi yang layak untuk mengisi waktu tidak bertugas penguji karena manajer produk junior menghabiskan banyak waktu untuk membuat persyaratan untuk cerita pengguna dan oleh karena itu memiliki pengetahuan yang mendalam tentang sebagian besar tugas.

Tes Otomatisasi

Seperti yang telah kita bahas sebelumnya, pengujian manual seringkali lebih rendah daripada otomatisasi. Dalam konteks ini, dorongan untuk otomatisasi dapat digabungkan dengan memiliki penguji yang mendedikasikan perhatian penuh mereka kepada tim dan memanfaatkan waktu luang mereka untuk belajar bekerja dengan alat otomatisasi pengujian seperti Selenium.

Ringkasan: Pengujian Agile Kualitas

Membuat pengujian lebih gesit adalah keniscayaan yang dihadapi banyak tim pengembangan perangkat lunak. Namun, kualitas tidak boleh dikompromikan dengan mengadopsi pola pikir "uji secepat yang Anda bisa". Sangat penting bahwa transisi Agile mencakup pergeseran ke pengujian Agile, dan ada beberapa cara untuk mencapainya:

• Meresmikan proses siklus uji rilis.
• Berdayakan penguji dengan alat penerapan.
• Bereksperimenlah dengan pengembangan yang digerakkan oleh tes dan pengembangan yang didorong oleh penerimaan.
• Temukan inefisiensi dengan melacak pergerakan kartu tugas.
• Tambahkan otomatisasi pengujian ke keahlian tim QA.
• Kelola prioritas penguji.

Setiap tahun, perangkat lunak semakin baik dan harapan pengguna meningkat. Selain itu, karena klien terbiasa dengan produk berkualitas tinggi dari merek perangkat lunak teratas seperti Google, Apple, dan Facebook, harapan ini juga beralih ke produk perangkat lunak lain. Dengan demikian, penekanan pada kualitas kemungkinan akan menjadi lebih penting di tahun-tahun mendatang. Pengujian ini dan peningkatan proses pengembangan secara keseluruhan dapat membuat pengujian lebih gesit dan memastikan kualitas produk tingkat tinggi.