Get best of the week

Cara meningkatkan kinerja tim tangkas melalui pengujian

Pengembangan lincah ditujukan untuk menghadirkan fitur-fitur baru dengan cepat dan dengan frekuensi yang tepat, memastikan aliran perubahan yang konstan. Pendekatan yang fleksibel memungkinkan tim untuk menjaga kecepatan tinggi, tetapi karena ini, kualitas kode dan stabilitas produk sering menderita. Bagaimana mengatasi masalah ini tanpa mengarahkan tim ke dalam kerangka kerja yang ketat dan tanpa merampas kelebihan metode tangkas? Bantuan datang dari penguji. Nama saya Denis Dubovoi, saya mengepalai departemen pengujian di Big Data Direktorat X5 Retail Group, dan dalam artikel ini saya akan memberi tahu Anda bagaimana penampilan penguji membantu meningkatkan kualitas kerja pengembang kami.



Membuat aturan melalui pengujian


Tim lincah sering mengabaikan kualitas. Ini sebagian disebabkan oleh fakta bahwa metodologi pengujian tradisional tidak cocok dengan konteks "fleksibel", sebagian karena prioritas kecepatan di atas kualitas. Tugas utama tim tangkas adalah dengan cepat mengimplementasikan fungsi-fungsi yang dibutuhkan pelanggan bisnis. Ini terutama benar pada tahap pembentukan suatu produk, ketika fungsinya ditentukan secara harfiah oleh coba-coba, dan pengembang perlu dengan cepat membangun kembali produk untuk permintaan saat ini. Dalam situasi seperti itu, tim sering kali memutuskan seperti ini: kami akan memanggil tester nanti, ketika kami mengerjakan MVP / versi kerja pertama / kami mempelajari Zen - karena tidak mengerti bagaimana mengatur pengujian yang fleksibel. Hasilnya sering kali gangguan pada waktu pengiriman, kesalahan pada demo dan, yang terburuk, di lingkungan PROM.

Dalam kasus kami, situasinya sangat mirip: Departemen Pengembangan Produk Big Data X5 Grup Ritel telah ada selama 2 tahun, dan pada awalnya kualitas produk dipelihara hanya oleh pengembang sendiri - tidak ada peran spesialis QA khusus, dan departemen pengujian dan penguji pertama dalam produk muncul hanya setahun yang lalu, ketika produk sudah mulai.

Saat ini, sudah ada 15 orang di departemen pengujian: 11 penguji menemani produk dalam tim, dua orang mengembangkan arah pengujian beban, dan dua lainnya - arah otomatisasi pengujian. Dalam banyak tim produk, penguji telah menjadi katalisator untuk perubahan penting: kedatangan mereka memperlancar proses pengembangan dan meningkatkan stabilitas pelepasan. Untuk melakukan ini, kami menghubungkan penguji ke tim yang sudah bekerja sesuai dengan skema berikut:

1. Selami prosesnya


Pada tahap pertama, kita perlu memahami bagaimana tim bekerja sekarang, bagaimana peran didistribusikan di dalamnya, dan bagaimana informasi dipertukarkan. Penguji mulai membantu dengan pengujian, lebih dalam bentuk "kontrol kualitas", secara bersamaan mengevaluasi kematangan tim dan proses dalam tim - untuk ini ada "peta panas" kecil kematangan, contoh yang dapat dilihat di bawah ini. Di dalamnya Anda dapat melihat bagaimana berbagai arah dikembangkan (pengembangan, pengujian, DG, DevOps, dukungan) di setiap produk kami.


Peta Panas Jatuh Tempo

Penguji mengumpulkan penilaian kematangan proses bersama-sama dengan pengembang, mengevaluasi serangkaian praktik teknologi dan metodologi yang digunakan oleh tim. Sebagai hasilnya, kita dapat melihat pada peta panas apa dan di daerah mana dimungkinkan untuk meningkatkan - misalnya, untuk mengembangkan praktik pengujian Unit dalam pengembangan atau untuk mengotomatisasi pemeriksaan API dalam pengujian - untuk setiap tahap kehidupan produk (prototipe, pilot, industri), serangkaian praktiknya sendiri direkomendasikan.

2. Kami membuat rekomendasi untuk perbaikan




Setelah mengetahui bagaimana tim hidup, Anda dapat memikirkan rekomendasi pertama untuk meningkatkan pekerjaannya. Di sini kami mematuhi logika berikut: penguji bukanlah fungsi khusus yang bertanggung jawab untuk area tertentu, kami adalah bagian dari tim dan dapat mempengaruhi keseluruhan proses. Untuk memfasilitasi peluncuran perbaikan, kami mulai dengan hal-hal dasar:

  • . , : , , , .. , , ! ;)
  • (, user stories) . , , , , . « » : , pdf ? , !
  • Definition of Ready ( ) Definition of Done ( ) .
  • Kami memperbaiki tahap sprint dan salah satu poin penting - titik "pembekuan kode".

Kami melihat ke tahap sebelum pengujian dan sedikit ke dalam pengujian itu sendiri, tetapi ada juga bagian teknis dengan mempertahankan bangku tes dan bekerja dengan data uji dan bagian industri dengan dukungan produk. Penguji entah bagaimana terlibat pada semua tahap ini - kami mencoba untuk mengangkat spesialis T-Shape yang melihat seluruh proses produksi, dan bukan hanya fungsi langsung mereka.

3. Kami menyajikan perbaikan kami kepada para pemimpin tim dan pemangku kepentingan, dengan fokus pada masalah apa yang akan dipecahkan oleh perbaikan ini


Prosesnya akan lebih mudah jika Anda meminta dukungan tim. Penting untuk "menjual" ide Anda, untuk menunjukkan untung apa yang akan dihasilkan dari perubahan yang Anda usulkan. Misalnya, kriteria penerimaan yang kami sebutkan di atas mungkin terlihat seperti pekerjaan tambahan untuk analis, tetapi ketika tim memahami penghematan waktu yang akan diterimanya - dan ini dari jam ke hari, yang mungkin diperlukan untuk memperbaiki tugas - dibutuhkan peningkatan yang jauh lebih mudah.

Dalam beberapa kasus, Anda dapat bertindak melalui pemilik produk. Misalnya, produk tidak memiliki pemantauan (misalnya, teknis, dengan log dan grafik yang indah) dan tidak ada waktu untuk mengkonfigurasi, karena ini bukan tugas produk. Dalam hal ini, Anda dapat menghubungi produk dan menjelaskan dengan tepat manfaat apa yang akan diterima dari pemantauan (itu tidak akan menjadi lebih stabil segera, tetapi kecepatan lokalisasi masalah akan meningkat), dan memintanya untuk mengalokasikan sumber daya untuk ini.
Sejalan dengan standarisasi kerja dalam tim produk, pendekatan pengujian sedang dikembangkan untuk memastikan kualitas produk, misalnya, mengevaluasi dan menyiapkan volume data uji yang diperlukan, mengembangkan model uji, membentuk poin untuk otomatisasi masa depan, dll.

Selalu ada kemungkinan bahwa tim tidak akan menerima perubahan yang diajukan, tidak peduli seberapa masuk akal mereka bagi Anda. Dalam setiap kasus individu, penting untuk merumuskan pendekatan Anda sendiri dan mencari cara persuasi individu. Produknya sangat berbeda, dan pendekatan yang bekerja di satu produk tidak bekerja sama sekali di yang lain.

Banyak tim yakin bahwa mereka dapat mengatur pekerjaan mereka sendiri, dan kadang-kadang ini benar. Ada beberapa kasus ketika partisipasi kami datang untuk merekomendasikan poin-poin utama verifikasi, dan kemudian tim dengan sempurna mengimplementasikan segala sesuatu di tingkat kode, dan kami hanya tinggal di dekatnya, selalu siap membantu. Tetapi lebih sering terjadi secara berbeda: karyawan kami datang ke tim, dan para pengembang dengan bercanda mulai “menangis” dari cacat yang ditemukan oleh tester, bersukacita bahwa cacat itu ditemukan sebelum demo atau rilis industri.

Apa yang berubah


Perubahan dalam tim produk berjalan secara berbeda dan memengaruhi berbagai aspek proses. Di salah satu tim, pengujian pada awalnya menjadi hambatan: butuh waktu, dan tidak semua orang mengerti apa yang terjadi pada tahap ini. Sebagai percobaan, kami menghubungkan pengembang ke menjalankan tes, sebagai akibatnya mereka dapat mengalami pekerjaan penguji dan bahkan melihat produk secara keseluruhan - misalnya, bukan fungsi terpisah untuk membangun laporan, tetapi seluruh jalan dari otorisasi pengguna dalam produk dan melakukan operasi bisnis hingga akhir - pembongkaran melaporkan. Jadi kami memperkuat keterlibatan seluruh tim, menjadikan proses pengujian transparan dan menunjukkan pentingnya tindakan ini, dan praktik yang dijelaskan di atas menjadi teratur.

Di produk lain, siklus rilis telah berubah dengan bantuan kami. Awalnya, diatur bahwa hasil sprint masuk ke pengujian pada hari Jumat sore, dan pada hari Senin produk sudah mencapai pelanggan. Akhir Jumat dan hanya awal Senin tetap untuk menguji dan memperbaiki kesalahan kritis, dan sebagai hasilnya, versi baru sering keluar "mentah" atau pengembang harus segera memperbaiki bug pada akhir pekan. Setelah beberapa shift pengiriman yang sulit, tim masih menunda pengiriman sprint hingga Rabu (tidak mengurangi panjang sprint, tetapi hanya mengubah jadwal dua hari). Sekarang tim memiliki waktu untuk memeriksa dan memperbaiki pengiriman dalam suasana yang santai.



Keputusan akhir, apakah akan berubah atau tidak, tetap berada di tangan tim: dialah yang bertanggung jawab atas produk dan hasilnya, itulah sebabnya ia memilih opsi yang paling nyaman untuk dirinya sendiri. Tujuan dari pekerjaan kami bukan untuk memaksakan pendekatan kami pada programmer, tetapi untuk memberikan informasi maksimal tentang kemungkinan risiko dan menawarkan peningkatan dan tindakan yang cocok untuk produk.

Apa yang berhasil dilakukan oleh departemen pengujian kami selama setahun terakhir:

  • Pengujian fungsional reguler telah muncul di 7 produk dari Big Data Department X5 Retail Group, 2 di antaranya telah mencapai rilis stabil di PROM tanpa komentar kritis. Mengadakan pengujian beban reguler 3 produk.
  • 15 – 1 15 :-) !

    – ( , Agile), , , , , – .

Perubahan selalu rumit, tetapi diperlukan jika kita melakukan root untuk produk kita. Dan pengujilah yang dapat memberikan kontribusi signifikan untuk memastikan kualitas produk.
Dalam artikel berikut, saya dan rekan kerja saya akan berbicara tentang bagaimana kami menguji produk tertentu, tentang memilih strategi pengujian, tentang alat (misalnya, edisi Allure Enterprise - alat yang mudah untuk mengelola pengujian, pelaporan dan bahkan mengelola autotests), dan bagaimana menerapkan tes otomatis di pipeline dan opsi pengembangan apa yang kami lihat (Test Driven Development, jika Anda memikirkannya, ini hanya salah satu opsi yang mungkin).

More articles:


All Articles