Get best of the week

Bagaimana mengatur pengujian untuk mempercepat dan menstabilkan rilis produk. Bagian 1

Jika kerja tim tidak disetujui, benturan akan terus-menerus terjadi antara peserta proses individu dan seluruh tim, dan produk perusahaan atau layanan mikro dalam produk yang sama akan saling mengganggu menggunakan sumber daya dan infrastruktur bersama. Hasilnya adalah kerusakan permanen, konflik dan perlambatan. Rilis cepat dan dapat diprediksi dalam kondisi seperti itu tidak akan mungkin tercapai.

Nama saya Victoria Dezhkina, saya terlibat dalam pengujian di Departemen pengembangan dan pemeliharaan produk big data X5 Retail Group. Saya akan memberi tahu Anda bagaimana kami mengubah proses pengujian di salah satu tim produk kami untuk mempercepat persiapan rilis hampir setengahnya dan mengurangi tim stres. Sekarang kami memperkenalkan pendekatan ini untuk menguji produk-produk lain dari perusahaan.



Direktorat Big Data X5 Grup Ritel saat ini sedang mengembangkan 13 produk, 4 di antaranya berada di departemen monetisasi, di mana produk berorientasi ke pasar luar negeri, dan kesalahan apa pun, apakah itu cacat dalam suatu produk atau fitur yang dirilis terlambat, memiliki efek ekonomi dan menyebabkan kehilangan pelanggan . Bahkan, ini adalah tim internal yang menghasilkan di pasar luar negeri dan bermain dengan aturan bisnis kecil dalam perusahaan besar.

Semua produk kami sangat bervariasi dalam sasarannya dan karenanya memerlukan pendekatan berbeda untuk pengembangan dan pengujian, tetapi mereka memiliki banyak kesamaan: mereka menggunakan infrastruktur yang sama (Kubernetes, Greenplum, server uji), dan pengembang dari tim produk yang berbeda kadang-kadang saling menggantikan untuk sementara waktu liburan.

Dalam situasi seperti itu, peran perjanjian meningkat tajam: jika satu bagian dari tim tidak tahu apa yang dilakukan pihak lain, dan masing-masing tim memiliki aturannya sendiri, masalah pasti akan muncul.

Misalnya, dua produk menggunakan infrastruktur pengujian beban yang sama, dan keduanya perlu melakukan pengujian. Tanpa memberitahukan satu sama lain, mereka melakukan ini pada saat yang sama, sebagai hasilnya, mereka mendapatkan hasil yang salah, karena DBMS telah "meletakkan", dan karena siapa tidak jelas. Mereka ingin menghemat waktu dalam negosiasi, sebagai akibatnya, mereka kehilangan banyak waktu tanpa hasil.
Kehilangan data tidak dikecualikan. Misalkan salah satu produk menempati server uji gratis tanpa memperingatkan siapa pun tentangnya. Secara resmi, perangkat keras dianggap gratis, sehingga produk lain masuk ke sana dan secara tidak sengaja menghapus semua data uji yang pertama. Ini, tentu saja, bukan data pengguna, tetapi hanya tes, tetapi masih merupakan kasus yang tidak menyenangkan.

Mungkin tidak ada cukup banyak pekerja jika pekerjaan itu tidak direncanakan sebelumnya. Misalnya, sekarang pengujian stres di Direktorat kami berfungsi dalam format layanan, yaitu, kami memilih spesialis yang sesuai untuk tim berdasarkan permintaan. Jika beberapa tim, tanpa peringatan sebelumnya, datang untuk meminta pengujian beban dalam satu hari, mungkin tidak ada cukup penguji sama sekali.

Tampaknya jalan keluar yang paling mudah dalam situasi seperti ini adalah dengan menetapkan aturan yang seragam untuk interaksi untuk semua produk. Tetapi masalahnya adalah bahwa semua produk berbeda. Beberapa dari mereka ditujukan untuk pengguna internal, yaitu, spesialis dari departemen lain perusahaan, misalnya, layanan untuk menentukan harga atau mempelajari permintaan. Bagian lain dikembangkan untuk pengguna eksternal - misalnya, untuk pemasok. Produk-produk ini memiliki logika arsitektur dan kriteria kualitas yang sangat berbeda.

Produk pada berbagai tahap kesiapan juga tidak menerima pendekatan yang sama: pada tahap awal ketika produk menguji ide, prioritasnya adalah memahami fungsionalitas bagi pengguna dan tidak adanya ancaman terhadap keamanan perusahaan. Ketika suatu produk datang untuk mendukung, persyaratan lain menjadi yang utama: kenyamanan pengguna, stabilitas fungsi yang ada, kecepatan respons terhadap cacat, dan kepatuhan penuh terhadap kebijakan keamanan perusahaan.

Dua faktor ini - kerja bersama di wilayah yang sama dan fitur produk yang unik - menetapkan tugas bagi kami : untuk mengembangkan aturan yang memungkinkan tim tidak saling mengganggu, tetapi pada saat yang sama tidak akan mengikat penguji dan pengembang tangan dan kakidan mereka tidak akan mengurangi pengembangan produk yang berbeda menjadi satu templat, meretas semua keunggulan tangkas dan pendekatan produk sejak awal.

Saya akan mengatakan beberapa kata tentang mengapa penguji memainkan peran utama dalam menciptakan standar untuk interaksi dalam tim produk. Faktanya adalah, karena spesifik pekerjaan kami, kami melihat keseluruhan produk, sementara pengembang biasanya fokus pada satu area kecil. Kami adalah orang pertama yang melihat masalah dan menawarkan solusi untuk mereka, tetapi solusi terakhir dikerjakan bersama dengan pengembang.

Kami sudah menulis bagaimana kerja kolektif ini berlangsung : pada tahap awal, kami harus membuat satu kamus tunggal agar tidak bingung dalam hal istilah. Tapi ini baru permulaan. Selanjutnya, kita harus menyepakati massa nuansa yang sangat berbeda.

Saya akan memberi tahu Anda bagaimana ini terjadi pada contoh salah satu produk kami - sistem otomasi pengadaan untuk jaringan distribusi. Tugasnya adalah untuk memastikan operasi semua proses dari saat toko memiliki kebutuhan untuk barang-barang tertentu sampai saat dia menerimanya.

Proses apa yang telah berubah dalam produk kami


Ketika kami tiba di produk, rilis akan dirilis setiap 2 minggu, tetapi mereka hampir selalu terlambat selama beberapa hari, dan hari rilis selalu berarti bahwa kami pasti akan tetap bekerja dan sampai yang terakhir kami akan menstabilkan versi yang ada. Itu perlu untuk mengubah sesuatu.

Penting untuk dicatat bahwa perubahan adalah penyebab umum. Apa pun inisiator, penguji, atau pengembang itu sendiri, tidak dapat melakukannya tanpa persetujuan seluruh tim dan sekutu yang kuat. Setiap perubahan perlu didiskusikan oleh seluruh tim untuk mengumpulkan ide sebanyak mungkin dan tidak melewatkan risiko yang mungkin terjadi. Pengiriman dan manajer produk dari produk kami dan sebelum saya secara sistematis bekerja untuk meningkatkan proses dari sisi teknis dan produk. Setelah datang ke tim, saya memeriksa proses dari sisi pengujian, dan bersama-sama kami memikirkan "strategi perubahan" yang disepakati. Poin pertama di dalamnya adalah perubahan tata letak kode.

Tata Letak Kode


Prosedur perhitungan adalah salah satu "rasa sakit" utama pengembangan tim, dan ada masalah yang sangat berbeda di sini. Misalnya, tim hanya memiliki satu cabang dengan kode, dan koreksi kesalahan tidak berhenti di situ. Atau ada beberapa cabang, tetapi tugas dengan fungsionalitas yang tumpang tindih dapat muncul pada lingkungan pengujian pada saat yang sama, sebagai akibatnya, penguji tidak akan dapat melokalisasi cacat atau memeriksa beberapa fungsi baru yang diblokir oleh cacat salah satu tugas. Dan tentang pengembang putus asa yang tidak menganggapnya sebagai sesuatu yang buruk dengan cepat memperbaiki hal-hal kecil pada prod tanpa memperingatkan orang lain, saya biasanya tidak akan mengatakan apa-apa.

Untuk menghindari semua ini, kami perlu menentukan jumlah cabang dan lingkungan, serta menyetujui prosedur untuk memasukkan kode ke dalam pengujian.

Cara termudah adalah dengan membagi proses menjadi dua cabang dengan kode "bersih" dan "kotor". Tetapi kami harus memenuhi banyak persyaratan:

  • « », « »
  • ,
  • .

Kami menghabiskan 2 jam membahas skema kerja baru dan sampai pada hal berikut: kami memulai tiga cabang, dua di antaranya (rilis dan master) akan dengan kode bersih. Dalam "master" adalah versi produk saat ini, dalam "rilis" - fitur yang siap diluncurkan. Di Dev, pengujian berlangsung, berikut adalah tugas yang siap untuk pengujian, pengembangan berlangsung secara lokal. Peluncuran ke setiap cabang terjadi sesuai dengan penguji. Ini dia:



Apa yang diberikan kepada kami dalam hal pengujian:

  • Waktu pengujian untuk setiap tugas secara individual berkurang sebesar 20%. Tidak perlu lagi memulai pemeriksaan lagi, jika tugas baru diluncurkan ke tes tanpa peringatan, tugas baru tidak menghalangi pemeriksaan yang sudah dilakukan, dan waktu untuk lokalisasi cacat dipercepat.
  • Pada hari yang direncanakan untuk memperbaiki rilis, 1-2 tugas tetap tidak diperiksa bukannya 4 (yaitu, waktu untuk memeriksa mereka dibelah dua).
  • Waktu untuk pengujian integrasi dan pengujian kandidat rilis telah dikurangi dari 6 jam menjadi 2 (menghitung pengujian ulang).
  • Jumlah cacat yang ditemukan pada tahap rilis telah menurun. Sebelumnya, pada versi rilis pertama, kami menemukan lebih dari 10, tetapi sekarang tidak lebih dari 4. Waktu pengujian ulang telah berkurang 2 jam.
  • Ada peluang untuk melanjutkan pengembangan secara paralel dengan pengujian.

Total waktu yang kami habiskan untuk pengujian, menunda peluncuran produk, dikurangi 8 jam. Hanya 2 jam mendiskusikan skema baru untuk bekerja dengan tim - dan berhasil menyelamatkan seluruh hari kerja, yang biasanya dihabiskan setiap dua minggu. Tidak buruk?

Tapi masalahnya tetap ada.

  • , .
  • - , , .
  • .
  • , .

Intinya: kami terus bekerja pada hari rilis.

Kami berkumpul lagi. Sebagian dari masalah diselesaikan dengan menyempurnakan proses pengembangan dan menambahkan CI:



Kami menyiapkan peluncuran otomatis ke semua lingkungan selama hampir sebulan, tetapi ini memberikan percepatan waktu hampir 2 hari kerja. Tim telah bergerak ke arah ini untuk waktu yang lama, manajer distribusi dan pengembang sendiri terlibat dalam hal ini, tetapi sejauh ini mereka belum berhasil mencapai dua hal: sehingga peluncuran ke semua lingkungan adalah seragam dan pada saat yang sama kontrol versi dipertahankan. Peluncuran otomatis melanggar prinsip utama pengujian "pada waktu tertentu, tester harus tahu apa yang ada di setiap lingkungan", atau memperlambat pengembang yang tidak dapat menyelesaikan pengembangan tugas tanpa izin untuk meluncurkan pengujian.

Ini adalah dilema yang sulit. Abaikan prinsip pertama dan alih-alih mempercepat, Anda mendapatkan penurunan tajam dalam prediktabilitas rilis dan tugas yang salah kempes. Misalnya, jika cacat diperbaiki sudah dalam hubungannya dengan "tugas bersih", maka ketika meluncurkan tugas tetap, itu pasti akan menangkap yang rusak. Oleh karena itu, Anda harus menunggu koreksi kerusakan pada tugas terkait, menunda tanggal rilis, atau memperbaiki kembali cacat yang sudah diperbaiki.

Peluncuran otomatis bukan orang, Anda tidak akan setuju dengan itu. Oleh karena itu, kami memecahkan masalah dengan kesalahan yang tersisa dengan cara yang berbeda - pendekatan khusus untuk perencanaan, dan kemudian menambahkan pendirian lain.

Merencanakan pengembangan dan pengujian


Awalnya, ketika merencanakan, tim dan saya membahas apakah tugas itu jelas bagi pengembang, berapa lama waktu yang dibutuhkan dan apakah kami akan cocok dengan sprint. Penguji memperkirakan berapa lama pengujian akan berlangsung.

Pada saat yang sama, kami tidak membahas sama sekali kesalahan yang mungkin terjadi: kami tidak melihat mereka sebelumnya dan tidak memasukkannya dalam daftar tugas yang mungkin. Akibatnya, ketika kasus-kasus ini keluar selama proses pengujian, mereka ditambahkan sebagai tugas terpisah, mereka membutuhkan waktu untuk bekerja dan meningkatkan volume rilis, dan kadang-kadang mereka hanya ditemukan dalam kandidat rilis, pada tahap pengujian tugas bersama, menunda peluncuran tanpa batas waktu. Kami berkumpul untuk tiga - penguji, pengiriman dan produk, dan memikirkan skema interaksi baru.

Sekarang kami ucapkan semua kesalahan yang mungkin terjadi sebelum memulai pengembangan. Butuh waktu untuk menjadi siswa yang membosankan, yang pada tahap perencanaan menanyakan segalanya dan segalanya: “Apa yang akan terjadi jika layanan pihak ketiga jatuh?”, “Dan jika kita mendapatkan nol, tetapi bukan 0?”, “Bagaimana jika kita tidak mendapatkan semua data? "," Dan jika Pecheneg menyerang? " dan seterusnya, tetapi sekarang kami siap untuk semuanya.

Kami juga mulai berbicara tentang bagaimana kami akan mengimplementasikan tugas ini atau itu dan bagaimana kami akan mengujinya. Ini memungkinkan untuk mengurangi inisiatif (penemuan semua jenis sepeda, misalnya) dan memberi setiap anggota tim pemahaman tentang apa yang dilakukan rekan-rekannya. Omong-omong, ini memungkinkan kami untuk mengabaikan kriteria penerimaan (AC).

Untuk mencegah diskusi dalam format baru menjadi terlalu rumit, kami mulai melakukan ini bukan untuk 2 minggu sebelumnya, tetapi selama seminggu.

Tata letak kode baru dan penjadwalan tugas hanyalah langkah pertama. Pada bagian selanjutnya dari artikel, yang akan dirilis besok, saya akan berbicara secara rinci tentang bagaimana kami mengubah seluruh rangkaian proses dalam tim:

  • Format untuk mengatur dan menerima tugas dan cacat: mereka meninggalkan cerita pengguna untuk hybrid "use case + technical task" lebih nyaman bagi kami.
  • Momen pengujian: 5 poin ditetapkan dalam siklus rilis di mana penguji secara aktif mengontrol proses penciptaan produk.
  • Aturan interaksi koneksi "backend - testing - frontend": kami mengembangkan skema yang memungkinkan kami untuk memeriksa semua data yang dikirim antara backend dan frontend.
  • Akselerasi pekerjaan memperbaiki cacat: menetapkan aturan tentang cara memprioritaskan tugas debug agar tidak mengganggu pengembang sekali lagi.

Langkah-langkah ini memungkinkan kami untuk memperpendek siklus rilis dari 2,5 minggu menjadi 1. Peningkatan kecepatan mungkin tampak kecil, tetapi pencapaian utamanya adalah bahwa rilis kami menjadi lebih stabil dan dapat diprediksi - kami mendapat kesempatan untuk meluncurkan rilis "sesuai perintah": kami bisa bersama-sama setiap hari, mulai tugas dan pada malam hari semuanya akan siap dan debugged.

More articles:


All Articles