Praktik Terbaik dalam Menguji Strategi untuk Tim Scrum

Scrum minus rencana pengujian sama dengan POC pada steroid.

Saat ini, sebagian besar proyek yang sukses dimulai dengan Proof of Concept (POC), penilaian ide berukuran relatif kecil, di mana paket teknologi dan fitur yang dipilih akan diverifikasi terlebih dahulu, dievaluasi untuk dampak potensial pada pengguna bisnis, dan kemudian, setelah terbukti layak investasi, tim proyek berukuran penuh ditugaskan untuk merancang dan mengirimkan produk berfitur lengkap dan menyebarkannya ke produksi.

Ini adalah kasus yang sempurna untuk tim Scrum. Tim dapat dengan cepat mengembangkan prototipe, menambahkan fitur baru yang substansial setiap sprint, sementara pengguna bisnis dapat melihat kemajuan cepat secara real-time dan bagaimana ide dibangun dari awal hanya dalam waktu sekitar 10 sprint. Itu meninggalkan kesan yang kuat (yang merupakan target utama POC), tetapi juga memiliki satu properti yang signifikan – aktivitas pengujian minimal atau tidak sama sekali, dan bahkan memikirkan proses pengujian akan menjadi lelucon langsung.

Ini bukanlah aktivitas yang menyenangkan di dalam tim Scrum, dan sebagian besar orang akan menyukai ide pengembangan tanpa proses untuk memperlambat mereka. Ini pada dasarnya adalah aktivitas pengujian yang akan dilakukan secara implisit. Dan siapa yang menginginkan kelambatan yang tidak perlu selama waktu yang paling kita butuhkan untuk mengesankan pengguna akhir?

Keadaan yang terjadi jika tim proyek melanjutkan dengan cara yang sama setelah periode POC selesai adalah sesuatu yang saya gunakan untuk memanggil POC pada steroid – sistem produksi yang tumbuh dalam ukuran dan fitur, tetapi tetap berperilaku seperti POC – produk lengkap wannabee dengan cacat tersembunyi dan kotak sudut yang belum dijelajahi, hanya menunggu kecelakaan serius.

Tetapi sebelum dikonversi di sana, tim akan mengalami kesulitan dari sprint ke sprint mengikuti rilis stabil, karena memperbaiki masalah bergulir hanya akan menjadi lebih kompleks.

Berikut adalah beberapa teknik yang terbukti berhasil ketika saya berurusan dengan masalah serupa dan yang saya percaya dapat disebut sebagai praktik terbaik untuk menerapkan proses pengujian yang solid, masih tanpa terlalu banyak mengacaukan kemajuan pengembangan - karena itulah yang kita semua inginkan. tim scrum.

Mendistribusikan rasa sakit

Di mana lagi kita akan mulai ketika berurusan dengan gangguan yang tidak perlu selain dengan membagi rasa sakit :).

Dan yang saya maksud dengan ini adalah membuat rencana yang akan membutuhkan aktivitas tambahan kecil dari pengembang di sana-sini tetapi itu akan sangat berkontribusi pada target bersama dari waktu ke waktu, secara bertahap tetapi konsisten.

#1. Kembangkan kode pengujian Unit untuk setiap potongan kode baru yang dibuat

Jika Anda berhasil meyakinkan tim scrum Anda untuk menambahkan pengembangan pengujian unit ke dalam klausa Definisi Selesai untuk setiap kode baru yang dibuat dalam sprint, maka dari perspektif jangka panjang, ini akan menjadi pencapaian yang luar biasa.

Alasannya cukup jelas:

Ini akan memaksa pengembang untuk memikirkan berbagai jalur kode yang tidak standar. –

• Pengujian unit semacam itu dapat dihubungkan ke pipeline DevOps otomatis dan dijalankan dengan setiap penerapan tunggal ke lingkungan dev atau pengujian. Juga, metrik dari pipa dapat dengan mudah diekspor dan kemudian digunakan untuk demonstrasi kepada pengguna bisnis cakupan persentase kasus uji yang langsung terikat ke kode sumber.

Yang paling penting adalah segera memulai. Nanti unit test akan mulai dikembangkan, semakin mengganggu bagi pengembang untuk menambahkannya dalam sprint.

• Ini akan membutuhkan upaya yang signifikan untuk mengembangkan pengujian unit ke belakang untuk kode yang sudah ada. Beberapa bagian dari kode mungkin dibuat oleh pengembang lain dan pengetahuan pasti tentang cara kerjanya di setiap bagian kode tidak terlalu jelas bagi pengembang saat ini. Dalam beberapa kasus, penambahan unit test ke kode yang dimodifikasi akan memakan waktu lebih lama daripada mengembangkan perubahan fitur untuk sprint (yang pasti tidak ada yang dihitung selama perencanaan sprint).

#2. Lakukan rutinitas untuk menjalankan semua bagian Pengujian Unit di lingkungan Pengembangan

Bahkan sebelum membuat pull request untuk menggabungkan kode baru ke dalam cabang Master, ini akan menjadi aktivitas standar untuk menguji kode fitur dan kode pengujian unit di lingkungan dev. Dengan melakukan ini akan dipastikan bahwa:

• Kode pengujian unit sebenarnya berfungsi untuk setiap bagian (pada akhirnya itu hanyalah kode lain yang harus diverifikasi). Langkah ini sangat sering dilewati sama sekali. Entah bagaimana diasumsikan bahwa jika pengujian unit tetap terhubung ke pipa DevOps, pada akhirnya akan dieksekusi dan diuji di suatu tempat secara default. Namun, ini tidak lain adalah mendorong masalah ke aktivitas sprint tingkat atas, di mana tim biasanya memiliki lebih sedikit waktu dan lebih banyak tekanan untuk menyelesaikan setiap cerita yang dilakukan.
• Kode fitur baru diuji oleh pengembang untuk fungsionalitas dasar. Jelas, dari pengujian ini tidak dapat diharapkan bahwa fungsionalitas bisnis akan sepenuhnya diverifikasi, tetapi setidaknya pengujian ini akan mengonfirmasi perilaku kode sesuai dengan yang diinginkan pengembang (mengabaikan, untuk saat ini, fakta bahwa logika bisnis dapat dipahami secara tidak benar saat mengembangkan).

#3. Harapkan eksekusi pengujian unit setelah kode bergabung ke cabang master

Memiliki kode fungsional di cabang lokal adalah satu hal (di mana tidak seorang pun kecuali pemilik cabang sedang mengembangkan fitur baru), tetapi memiliki kode yang sama berfungsi setelah permintaan tarik dan bergabung ke dalam cabang master adalah hal yang sama sekali berbeda.

Cabang master berisi perubahan dari anggota tim Scrum lainnya, dan bahkan jika konflik diselesaikan dan semuanya terlihat baik-baik saja, kode setelah penggabungan dan penyelesaian konflik pada dasarnya masih merupakan bagian kode yang belum diuji, dan berisiko untuk mengirimkannya lebih jauh tanpa memverifikasi terlebih dahulu itu masih berfungsi dengan baik.

Jadi yang terbukti efektif di sini hanyalah meminta untuk mengeksekusi pengujian unit yang sama – yang sudah dilakukan sebelumnya di lingkungan dev – juga di lingkungan, yang dibangun dari versi kode cabang master.

Bagi para pengembang, ini mungkin merupakan satu langkah tambahan yang perlu mereka sertakan ke dalam hidup mereka, tetapi itu tidak terlalu sulit karena, dalam hal ini, tidak ada hal baru yang harus ditemukan - jalankan kembali apa yang sudah dilakukan sekali.

Sekarang, langkah ini dapat dilewati dalam satu kasus tertentu:

• Pengujian unit otomatis dalam jaringan pipa DevOps sangat komprehensif sehingga sudah mencakup seluruh pengujian manual yang dilakukan selain itu.

Meskipun mencapai keadaan ini pasti bisa dilakukan, saya tidak pernah mengalami keadaan seperti itu dalam kehidupan nyata. Mungkin akan terlalu memakan waktu bagi pengembang untuk membuat pengujian Unit otomatis yang sangat mendetail. Sangat tidak dapat diterima bagi pemilik produk untuk membiarkan tim mendedikasikan begitu banyak waktu untuk aktivitas ini, karena hal itu akan berdampak eksplisit pada jumlah cerita yang disampaikan dalam sprint.

Namun, preferensi untuk konten sprint tidak boleh menjadi alasan untuk tidak melakukan pengujian unit, atau bahkan meminimalkannya. Dengan melakukan ini, tim akan mengonversi lagi ke keadaan seperti itu kode kurang memiliki terlalu banyak cakupan pengujian unit, dan kemudian untuk mengejar ketinggalan, mungkin sudah terlambat (sekali lagi, upaya yang lebih tinggi untuk penyelesaian pengujian unit daripada yang sebenarnya perubahan kode untuk sprint).

Untuk semua alasan itu, saya akan merekomendasikan eksekusi ulang unit test pada versi kode master tanpa ragu-ragu. Ini adalah upaya yang sangat rendah dibandingkan dengan nilai apa yang akan dihasilkannya.

Ini akan melakukan pemeriksaan akhir untuk kesiapan cabang master untuk fase pengujian rilis. Juga, ini akan membantu untuk menemukan sebagian besar bug teknis (misalnya bug yang mencegah kode sumber berhasil dieksekusi hingga akhir yang sukses), meninggalkan fase berikutnya untuk berkonsentrasi hanya pada verifikasi fungsionalitas bisnis.

Persiapkan untuk Pengujian Fungsional

Semua kegiatan pengujian sebelumnya akan mengarah pada satu kesimpulan spesifik – kode cabang master bebas dari bug teknis dan dapat dieksekusi tanpa masalah untuk aliran fungsional end-to-end.

Ini adalah fase yang dapat dengan mudah dilakukan hanya oleh satu orang, dan orang ini bahkan tidak perlu memiliki latar belakang teknis.

Sebenarnya, jauh lebih baik jika ini dijalankan oleh seseorang yang terputus dari pengembang tetapi dengan kesadaran fungsional tentang seperti apa perilaku kode yang diharapkan oleh pengguna bisnis. Ada dua kegiatan utama yang harus diselesaikan:

#1. Cerita sprint baru menargetkan tes fungsional

Setiap sprint idealnya membawa beberapa fungsi baru (peningkatan tujuan sprint) yang sebelumnya tidak ada, dan karenanya harus diverifikasi. Penting untuk memastikan perangkat lunak baru berfungsi sedemikian rupa sehingga pengguna bisnis senang memilikinya sekarang, karena mereka jelas menantikannya minimal sprint terakhir :).

Ini adalah pengalaman yang menyedihkan ketika fungsionalitas (panjang) yang dijanjikan akhirnya diumumkan untuk dirilis, hanya untuk mengetahui di hari lain itu sebenarnya tidak berfungsi dengan baik.

Oleh karena itu, menguji fungsionalitas sprint baru dengan benar sangatlah penting. Untuk menyukseskan ini, praktik yang baik adalah mengumpulkan kasus pengujian penting terlebih dahulu dan dari pemangku kepentingan terkait (baik dari pemilik produk atau bahkan dari pengguna akhir) dan membuat daftar semua kasus pengujian yang diperlukan untuk konten di dalamnya. sprint.

Ini mungkin terlihat luar biasa pada pandangan pertama, tetapi dari pengalaman saya, sekali lagi ini dapat dikelola sepenuhnya oleh satu orang. Karena sprint sebagian besar cukup singkat (seperti periode dua minggu), hampir tidak pernah terlalu banyak konten baru, karena sprint juga berisi aktivitas tambahan seperti cerita hutang teknis, dokumentasi, cerita desain/spike, dll.

Test case kemudian dijalankan dengan tujuan memverifikasi fungsionalitas yang diinginkan terutama. Jika ada masalah dengan hasilnya, hanya pengembang yang relevan yang didekati (orang yang memiliki perubahan terkait cacat khusus ini) untuk menyelesaikan masalah dengan cepat.

Dengan cara ini, pengembang akan menghabiskan waktu minimum terkait dengan pengujian fungsional dan masih dapat berkonsentrasi pada aktivitas yang paling mereka sukai.

#2. Eksekusi kasus uji regresi

Bagian lain dari pengujian fungsional adalah untuk memastikan semua yang bekerja sampai sekarang juga akan berfungsi setelah rilis berikutnya. Inilah gunanya tes regresi.

Uji kasus untuk uji regresi adalah yang terbaik jika dipertahankan secara teratur dan ditinjau kembali sebelum setiap rilis. Berdasarkan spesifikasi proyek konkret, yang terbaik adalah membuatnya tetap sederhana namun mencakup sebagian besar fungsi paling inti dan aliran end-to-end penting yang berjalan melalui keseluruhan sistem.

Biasanya, setiap sistem memiliki proses yang menyentuh banyak area berbeda, itu adalah kandidat terbaik untuk kasus uji regresi.

Dalam beberapa kasus, tes regresi bahkan secara implisit juga mencakup fitur-fitur baru dalam sprint, misalnya, jika cerita baru dalam sprint mengubah beberapa bagian tertentu dari alur yang ada.

Jadi dalam kebanyakan kasus, sama sekali tidak terlalu rumit untuk menyelesaikan tes regresi bersamaan dengan tes fungsionalitas cerita sprint baru, terutama jika ini dilakukan secara teratur sebelum setiap rilis produksi, dan periodisitas rilis produksi tidak terlalu kecil.

Bersikeras melaksanakan tes Jaminan Kualitas sebelum setiap rilis produksi

Tes Quality Assurance (QA) adalah langkah terakhir sebelum dirilis ke produksi, dan sering kali tes ini dilewati karena dianggap tidak penting. Apalagi jika tim scrum dikelola secara agresif untuk konten baru.

Bahkan pengguna bisnis akan mengatakan bahwa mereka tertarik pada fitur-fitur baru dan tidak begitu banyak mempertahankan fungsionalitas atau menjaga jumlah cacat tetap rendah. Tetapi sekali lagi – seiring waktu, ini adalah alasan utama mengapa tim pengembang pada akhirnya harus melambat, dan kemudian pengguna bisnis tidak akan mendapatkan apa yang mereka minta.

Tes QA harus dilakukan hanya oleh orang-orang di luar tim Scrum, idealnya oleh pengguna bisnis itu sendiri dalam lingkungan khusus, yang sedekat mungkin dengan produksi di masa mendatang. Alternatifnya, pemilik produk dapat menggantikan pengguna akhir di sini.

Bagaimanapun, ini harus menjadi tes fungsional yang bersih dari perspektif pengguna akhir, tanpa koneksi apa pun ke tim dev Scrum. Ini akan menyajikan satu pandangan terakhir dari produk dan digunakan dengan cara yang mungkin tidak diantisipasi oleh tim scrum (sama sekali bukan kasus yang ideal, tetapi itu pasti bisa terjadi). Masih ada waktu untuk koreksi menit terakhir.

Alternatifnya, mungkin menjadi jelas bahwa ekspektasi tidak dipahami dengan baik oleh tim scrum, dan dalam kasus seperti itu, setidaknya kami dapat menyetujui rencana tindak lanjut, masih jauh sebelum rilis produksi yang sebenarnya. Ini, sekali lagi bukan kasus yang ideal, tetapi masih jauh lebih baik seperti mengakui kegagalan setelah melaporkan rilis produksi yang sukses.

Ke mana harus pergi selanjutnya dari sini?

Menerapkan praktik tersebut ke pekerjaan scrum harian dapat secara serius membawa Anda ke kebiasaan rilis sprint yang lebih stabil dan dapat diprediksi, tanpa menunda rilis produksi atau menghabiskan seluruh sprint hanya untuk mempersiapkan rilis berikutnya, atau bahkan tanpa memaksa semua orang di tim scrum untuk melakukan sesuatu yang tidak mereka lakukan. Saya tidak terlalu suka atau tidak tahu bagaimana melakukannya secara efektif untuk sebagian besar sprint.

Tapi tentunya Anda tidak perlu berhenti di sini.

Inklusi tes kinerja adalah salah satu topik untuk disebutkan di sini. Itu sering diabaikan atau dianggap tidak perlu, tergores di putaran pertama "optimalisasi aktivitas scrum". Namun saya selalu ragu tentang bagaimana seseorang dapat mengharapkan sistem produksi berkembang dari waktu ke waktu jika kinerjanya tidak diperiksa secara teratur.

Naik satu tingkat juga berarti pengenalan tes otomatis.

Saya telah membahas satu grup pengujian otomatis (pengujian unit dalam saluran pipa). Namun, Anda dapat mengembangkan pengujian regresi ujung ke ujung yang sepenuhnya otomatis dan dijalankan sendiri setelah setiap penerapan ke lingkungan pengujian. Ini akan lebih membebaskan tim scrum pengembangan, tetapi membutuhkan tim khusus untuk mengembangkan dan memelihara pengujian otomatis semacam itu. Ini akan menjadi pekerjaan konstan, karena setiap kali kode produksi berubah, beberapa pengujian otomatis yang ada bisa menjadi tidak valid, sehingga harus diperbarui untuk terus bekerja di saluran pipa. Ini adalah upaya yang hanya sedikit orang yang mau membayar, namun keuntungan bagi tim dev scrum akan sangat besar.

Itu adalah topik yang menjangkau jauh di atas ruang lingkup artikel ini dan mencari tahu jadwal dan waktu yang tepat untuk setiap jenis tes yang disebutkan di sini – sehingga Anda dapat membuatnya dalam jendela sprint. Saya akan senang menyelam di lain waktu!