Get best of the week

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

Penguji memiliki banyak peluang untuk meningkatkan kualitas produk dan membuat tim bekerja lebih nyaman. Hal utama adalah mendiskusikan perubahan apa pun dengan tim dan hanya menerapkan apa yang nyaman dan bermanfaat bagi semua orang.

Nama saya Victoria Dezhkina, saya bertanggung jawab untuk menguji sejumlah produk di Direktorat Data Besar X5 Retail Group. Pada bagian terakhir artikel, saya mulai berbicara tentang bagaimana kami mengubah proses dalam tim produk "Sistem otomasi untuk pengadaan jaringan ritel." Rilis produk terus tertunda selama beberapa hari dan seringkali keluar mentah. Kami mengubah perhitungan kode dan urutan perencanaan tugas, yang memungkinkan kami untuk mempersingkat siklus rilis beberapa hari, tetapi kami masih harus mengerjakan format optimal untuk menetapkan dan menerima tugas, menetapkan titik uji dalam siklus rilis dan belajar bagaimana memprioritaskan masalah untuk memperbaiki cacat.



Format formulasi dan penerimaan tugas dan cacat


Metode pengaturan tugas sangat menentukan seberapa cepat dan benar tugas itu akan selesai. Anda dapat menggambarkan tugas dengan berbagai cara, misalnya, menggunakan cerita pengguna yang mencerminkan kebutuhan pengguna akhir sistem. Kedengarannya seperti ini: "pengguna ingin menerima laporan dengan menekan tombol hijau."

Kerugian dari pendekatan ini adalah bahwa ia tidak menjelaskan apa yang akan "di bawah tenda" dari keputusan ini. Kisah pengguna membuat pengembang terlalu banyak kebebasan, dan terkadang menjadi masalah: tim mulai menemukan kembali roda atau melihat sesuatu yang terlalu melelahkan. Dan mengingat bahwa dalam kondisi perkembangan yang cepat hampir tidak pernah ada cukup waktu untuk dokumentasi lengkap, dengan pendekatan ini Anda mendapatkan kode samar yang sangat menyulitkan integrasi pengembang baru ke dalam produk.

Kami membahas beberapa opsi desain untuk tugas dan cacat dan memilih pendekatan "hibrid": use case + subtugas teknis. Pelanggan bisnis menulis use case, yaitu, menjelaskan opsi untuk menggunakan fungsionalitas baru, dan analis dengan tester, berdasarkan hal ini, secara teknis adalah sub-tugas untuk pengembang. Dalam deskripsi tugas di Jira, kami menambahkan kasus penggunaan dari mana ia dibuat, atau kasus uji yang memungkinkan Anda untuk mereproduksi kesalahan, sementara nama dan deskripsi tugas utama tetap "dapat dibaca oleh manusia".

Mari kita lihat, misalnya, apa yang ada di dalam cacat dengan nama "Pengguna tidak mengerti bagaimana kesalahan yang terjadi ketika memilih tingkat pembelian" ditangani. Deskripsi tugas berisi:

  • suatu kasus di mana Anda dapat mereproduksi kesalahan;
  • hasil nyata dan yang diharapkan;
  • subtugas untuk backend dan frontend dengan instruksi yang jelas bagi pengembang untuk memperbaikinya. "Backend: untuk API ini, berikan jawaban yang sesuai ke frontend" + sebuah matriks opsi yang menunjukkan jawaban apa yang harus ada di setiap situasi yang mungkin. "Frontend: untuk API ini, tergantung pada respons dari belakang, terbitkan teks kesalahan yang sesuai" + matriks opsi.

Ketika pengembang menyelesaikan subtugasnya, ia hanya menutupnya. Jika semua subtugas ditutup, cacat dikembalikan ke pengujian ulang. Jika masalah tambahan terdeteksi, subtugas yang sesuai dibuat lagi. Aturan

terkait untuk deskripsi cacat diperoleh :

  1. Buat tugas dengan deskripsi masalah fungsional, kasus untuk mereproduksi kesalahan, dan tautan ke riwayat, selama verifikasi yang ditemukan cacat.
  2. . : , , API , use case . , , API, , , , , , .

Kami juga menolak untuk membentuk AC (kriteria penerimaan) pada produk kami, karena pada tahap perencanaan kami tidak hanya membahas apa yang kami kembangkan dan uji coba, tetapi juga bagaimana.

Apa yang diberikannya? Pendekatan ini memungkinkan kami setiap saat untuk memahami apa yang salah dengan fungsi pada bagian pengguna, pada tahap apa pekerjaan pada cacat dan, tergantung pada beban di bagian belakang dan depan, memprioritaskan subtugas untuk cacat yang sama dengan cara yang berbeda.

Akibatnya, bahkan sebelum dimulainya pengembangan, seluruh tim memahami bagian mana dari setiap tugas yang akan memengaruhi secara pribadi, dan pada akhirnya, setiap tugas berisi informasi: bagaimana itu dikembangkan, bagaimana itu diuji, apakah ada dokumentasi di dalamnya, dan juga apa yang diperbaiki di dalamnya selama proses pengembangan.

Pendekatan ini hanya digunakan pada produk kami, karena ternyata yang paling nyaman bagi kami. Produk lain dari Direktorat Data Besar X5 menggunakan skema mereka sendiri: misalnya, kisah Pengguna dengan AC.

Tampaknya pilihan kita tidak berkontribusi sama sekali untuk mempercepat pembangunan, karena itu membutuhkan lebih banyak langkah untuk memulai. Tapi ini tidak benar.

Kami mengatur proses sehingga pengujian dilakukan bersamaan dengan pengembangan. Berkat ini, pengembang tidak duduk diam sementara tester bekerja dan melokalisasi tugas sebanyak mungkin.Selain itu, kami selalu melihat pengembang spesifik mana yang mengerjakan tugas, bagaimana penerapannya - ini memungkinkan kami untuk memahami di masa depan pengembang mana yang akan mengatasi lebih cepat dengan masalah baru yang serupa. Logikanya sederhana: semakin sedikit pengembang melakukan hal-hal yang tidak terkait langsung dengan penulisan kode, semakin baik, dan lokalisasi cacat yang paling memungkinkan memungkinkan pemikiran yang lebih dalam tentang kemungkinan koneksi dan masalah yang disebabkan oleh kesalahan tertentu.

Pertanyaannya juga dapat muncul apakah aturan yang telah kami tetapkan dalam produk kami tidak mengganggu pembentukan pengujian seragam dan standar pengembangan di departemen. Sebenarnya tidak: aturan umum departemen menentukan apa tugas yang seharusnya berisi pada tahap perkembangan tertentu, dan kami mematuhi persyaratan ini, kami hanya mengerjakan tugas pada tahap sebelumnya.

Momen Uji


Kami sudah lama membahas pertanyaan tentang pada tahap apa melakukan pengujian. Pada awalnya ada ide untuk memeriksa setiap tugas individu di cabang lokal, tetapi dengan pendekatan ini tidak mungkin untuk memeriksa bagaimana tugas-tugas ini bekerja bersama, dan konflik mereka akan terungkap hanya pada tahap rilis yang dirakit, ketika sudah terlambat untuk mengubah apa pun.

Oleh karena itu, kami sepakat untuk menguji setiap tugas secara terpisah, tetapi di satu bangku tes. Pada awalnya kami ingin menjalankan beberapa tugas sekaligus, tetapi di atas sudah saya katakan risiko apa yang dibawa ide ini. Satu per satu jauh lebih cepat. Ini adalah efek yang diketahui: mengurangi jumlah tugas paralel tidak memperlambat, tetapi mempercepat proses. Di Kanban, misalnya, ada yang namanya batas WIP (WIP sedang berjalan), yang membatasi jumlah tugas yang dapat diselesaikan secara bersamaan oleh setiap peran.

Sebagai hasilnya, kami menetapkan lima poin di mana penguji terlibat aktif dalam proses pengembangan:

  • Pada tahap dokumentasi. Kami memastikan bahwa tidak ada masalah yang bertentangan dengan logika dari apa yang telah dilakukan, kami memperbaiki detail pelaksanaan setiap tugas.
  • Pada tahap pengaturan masalah. Kami berbicara dengan analis semua kasus yang mungkin terkait dengan tugas dan memperhitungkannya saat membentuk tugas
  • Pada tahap perencanaan. Kami berbicara tentang bagaimana implementasi yang direncanakan dapat menghubungkan fungsi terkait dan masalah apa yang dapat terjadi. Kami berkoordinasi dengan produk ini semua cacat kritis dan melengkapi sprint.
  • Dalam persiapan untuk rilis. Kami secara iteratif memeriksa setiap tugas di bangku tes, dan pada hari sebelum rilis yang direncanakan kami mengumpulkan semua tugas bersama dan memeriksa satu bangku.
  • Setelah rilis. Kami memeriksa bagaimana rilis bekerja pada prod.

Pada awalnya, ketika kami memiliki rilis setiap 2 minggu, skema kerja terlihat seperti ini:



Sudah menjadi (rilis seminggu sekali):



Aturan untuk interaksi backend - testing - koneksi frontend


Ketika banyak data berbeda dikirim antara backend dan frontend di API, itu tidak selalu jelas mengapa mereka diperlukan dan bagaimana mereka berinteraksi. Karena itu, kerusakan dapat terjadi di ujung depan. Misalnya, nomor kalkulasi, kal permintaan, ditransfer dari belakang. Secara nominal, ini adalah satu parameter, tetapi delapan bidang lainnya harus "ditarik" ke backing untuk melakukan perhitungan bersama dengannya. Jika Anda tidak meneruskannya bersama dengan nomor penetapan biaya, operasi ini tidak akan dilakukan di ujung depan.

Untuk menghindari situasi seperti itu, kami mulai menggambarkan parameter yang diteruskan, menunjukkannya dalam komentar ke sub-tugas untuk mengembangkan API di Jira, yang menjelaskan data apa yang akan dipertukarkan bagian belakang dan depan. Kami mencoba menggambarkan semua API dalam kerangka Swagger, tetapi dengan bantuannya ketika secara otomatis menghasilkan dokumentasi, tidak mungkin mentransfer frontend, apa sebenarnya backend akan lakukan dengan parameter yang diteruskan. Oleh karena itu, kami sepakat bahwa jika kita berbicara tentang parameter yang tidak hanya ditulis di bagian belakang, tetapi menggunakan parameter lain, perlu dijelaskan tujuannya dalam tugas.

Kami juga mulai mengontrol penunjukan variabel sehingga dalam API yang sama semua bidang distandarisasi. Produk kami terdiri dari layanan microser, dan masing-masing dapat memiliki nama bidangnya sendiri. Dalam satu bidang dengan nama pemasok dapat menjadi pemasok, di bidang lain - supplierID, dengan nama ketiga, dll. Ketika mentransfer data ini ke salah satu komponen front-end, kesulitan mungkin dimulai, jadi kami memeriksa semua parameter dan mulai membakukan semua nama variabel. Untuk melakukan ini, kami mengumpulkan tabel ringkasan dari semua penunjukan saat ini, tabel dari semua komponen depan dan variabel yang digunakan oleh mereka (dengan mana pengembang front-end banyak membantu) dan membandingkannya. Sekarang semua API baru mendapatkan nama variabel standar, dan API lama diperbaiki ketika tugas muncul untuk penyelesaiannya.

Mempercepat Perbaikan Cacat


Pada tahap menetapkan tugas, pelanggan bisnis menentukan prioritas - dia tahu yang terbaik apa dan dalam urutan apa yang dibutuhkan untuk pengembangan produk. Tetapi setelah diluncurkan ke dev, ketika ada tugas untuk memperbaiki cacat, penguji melakukan prioritas mereka.

Terkadang ada kebutuhan untuk segera mengubah prioritas tugas-tugas ini - misalnya, kami menemukan cacat kecil di back-end, yang tanpanya tim front-end tidak dapat mulai memperbaiki.

Sebelumnya, dalam situasi seperti itu, kami segera pergi ke pengembang dan meminta mereka untuk mengubah prioritas tugas, tetapi ini mengalihkan perhatian mereka. Karena itu, kami sepakat bahwa kami akan menghubungi hanya pada waktu-waktu tertentu - setelah kode dibekukan, hingga 5 kali sehari. Apa yang diberikannya? Kami berhenti mengurangi produktivitas pengembang melalui panggilan tiba-tiba, menyingkirkan waktu henti, dan menambah waktu bagi analis untuk menyelesaikan tugas.

Selain itu, karena kenyataan bahwa tugas tidak lagi muncul secara spontan untuk pengembang, kami selalu tahu siapa yang memiliki jenis beban, yang dulu mengerjakan tugas dan akan dapat menanganinya lebih cepat. Sebagai hasilnya, kami mengerti jauh lebih baik apakah kami akan berhasil mempersiapkan rilis sesuai jadwal atau tidak.

Langkah-langkah ini, bersama dengan logika terpadu untuk meluncurkan kode pada dev, release dan prod, diperbolehkanmengurangi periode koreksi cacat dari 3 hari menjadi 3-4 jam.

hasil


Selama 9 bulan pekerjaan produk otomatisasi pengadaan kami, kami berhasil mempersingkat siklus rilis dari 2,5 minggu menjadi 1 minggu dengan kemungkinan peluncuran harian, yang secara signifikan meningkatkan stabilitas rilis.

Apa yang berubah:

  1. Kami menyingkirkan kebutuhan untuk memperbaiki cacat setelah pengembangan, karena kami membawa pekerjaan ini ke tahap mempersiapkan tugas secara maksimal.
  2. Mengurangi periode koreksi cacat dari 3 hari menjadi 3-4 jam.
  3. Kami mendapat kesempatan untuk meluncurkan rilis "sesuai perintah." Sekarang kita bisa berkemas setiap hari, menjalankan tugas, dan pada malam hari semuanya akan siap dan debugged.
  4. Kami meningkatkan transparansi proses untuk semua peserta dalam proses: sekarang semua pengembang dan penguji tim memahami apa yang terjadi saat ini, yang sibuk dengan tugas apa, berapa banyak waktu yang dibutuhkan untuk mengembangkan dan memperbaiki kesalahan, dll.

BONUS: adalah mungkin untuk mengurangi tingkat stres dalam tim (saya harap), dan berkat kerja tim yang terkoordinasi (berkat pengiriman), saya dapat dengan mudah pergi ke remote :-) Menerapkan

perbaikan ini, kami mematuhi beberapa aturan:

  • Penguji dan pengembang berada di kapal yang sama (ulangi seperti mantra!), Jadi hal pertama yang perlu dilakukan penguji adalah bergaul dengan tim dan mencari tahu apa yang paling membuatnya khawatir, minta dukungannya. Sekutu dan mitra saya dalam tim adalah manajer distribusi dan pengembang.
  • Tidak ada solusi ideal yang siap pakai, dan itu perlu dicari. Penguji tidak memaksakan aturannya pada siapa pun, ia beradaptasi dengan tim dan mengubah pendekatannya dengan itu, sambil tetap mengingat citra masa depan yang cerah dan dengan lembut memperkenalkan langkah-langkah untuk mencapainya)).
  • Pembatasan dan standardisasi yang terlalu parah bukanlah metode. Jika Anda berlebihan, tim dapat kehilangan fleksibilitas.

Aturan interaksi, yang membantu kami mempercepat pengembangan produk ini, tidak dapat ditransfer dalam bentuk murni ke produk lain dari Direktorat - mereka diatur secara berbeda, dan kebutuhan pengembang di sana berbeda. Tetapi prinsip membuat aturan-aturan ini akan sama: menetapkan urutan perhitungan kode, menemukan titik optimal untuk pengujian, mendokumentasikan kode dan API.

Sejalan dengan bekerja di dalam produk, kami mengembangkan aturan yang dirancang untuk memfasilitasi interaksi antara produk, dan kami akan menceritakan hal ini dalam materi berikut. Jadi di Direktorat Big Data, strategi untuk mengembangkan kualitas produk secara bertahap dibentuk.

More articles:


All Articles