Halo semua! Nama saya Yulia dan saya seorang penguji. Tahun lalu aku bercerita padamu Bagodelnya - sebuah acara yang diadakan di perusahaan kami untuk membersihkan bug backlog. Ini adalah opsi yang sepenuhnya layak untuk menguranginya secara signifikan (dari 10 menjadi 50% di tim berbeda) hanya dalam satu hari.

Hari ini saya ingin memberi tahu Anda tentang format Bagodelny musim semi kami - BUgHunting (BUH). Kali ini kami tidak memperbaiki bug lama, tetapi mencari bug baru dan mengusulkan ide untuk fitur. Di bawah potongan terdapat banyak detail tentang penyelenggaraan acara tersebut, hasil kami, dan umpan balik dari para peserta.

Setelah memikirkan dan menuliskan peraturan, kami mengirimkan undangan ke semua saluran di perusahaan Slack, yang tidak memuat batasan apa pun:

Hasilnya, sekitar 30 orang mendaftar - baik pengembang maupun spesialis non-teknis. Kami mengalokasikan satu hari kerja penuh untuk acara tersebut, memesan ruang pertemuan besar, dan mengatur makan siang di kantin kantor.

Kenapa?

Tampaknya setiap tim menguji fungsinya. Pengguna melaporkan bug kepada kami. Kenapa malah mengadakan acara seperti itu?

Kami memiliki beberapa tujuan.

1. Perkenalkan orang-orang lebih dekat dengan proyek/produk terkait.
   Sekarang di perusahaan kami setiap orang bekerja dalam tim - unit yang terpisah. Ini adalah tim proyek yang mengerjakan bagian fungsinya masing-masing dan tidak selalu sepenuhnya menyadari apa yang terjadi di proyek lain.
2. Perkenalkan saja rekan-rekan Anda satu sama lain.
   Kami memiliki hampir 800 karyawan di kantor kami di Moskow; tidak semua rekan kerja saling mengenal secara langsung.
3. Meningkatkan kemampuan pengembang untuk menemukan bug pada produk mereka.
   Kami sekarang mempromosikan Agile Testing dan melatih orang-orang ke arah ini.
4. Libatkan lebih dari sekadar pakar teknis dalam pengujian.
   Selain departemen teknis, kami memiliki banyak kolega dari spesialisasi lain yang ingin berbicara lebih banyak tentang pengujian, tentang cara melaporkan bug dengan benar sehingga kami menerima lebih sedikit pesan seperti “Ahhh… tidak ada yang berhasil.”
5. Dan, tentu saja, temukan bug yang rumit dan tidak terlihat jelas.
   Saya ingin membantu tim menguji fitur-fitur baru dan memberi mereka kesempatan untuk melihat fungsionalitas yang diterapkan dari sudut yang berbeda.

Implementasi

Hari kami terdiri dari beberapa blok:

• arahan;
• kuliah singkat tentang pengujian, di mana kita hanya menyentuh poin-poin utama (tujuan dan prinsip pengujian, dll.);
• bagian tentang “aturan sopan santun” saat memperkenalkan bug (di sini prinsip-prinsipnya dijelaskan dengan baik);
• empat sesi pengujian untuk proyek dengan skenario tingkat tinggi yang dijelaskan; sebelum setiap sesi ada kuliah pengantar singkat tentang proyek dan pembagian ke dalam tim;
• survei singkat tentang acara tersebut;
• merangkum.

(Kami juga tidak melupakan jeda antara sesi dan makan siang).

Fundamental aturan

• Pendaftaran untuk acara bersifat individual, yang memecahkan masalah terkurasnya seluruh tim karena kelembaman jika satu orang memutuskan untuk tidak pergi.
• Peserta berganti tim setiap sesi. Hal ini memungkinkan peserta untuk datang dan pergi kapan saja, dan Anda juga dapat bertemu lebih banyak orang.
• Tim dua orang sebelum setiap sesi terbentuk secara acak, ini membuatnya lebih dinamis dan lebih cepat.
• Untuk bug yang diperkenalkan, Anda diberikan hadiah poin (dari 3 hingga 10) tergantung pada kekritisannya.
• Tidak ada poin yang diberikan untuk duplikat.
• Bug harus diajukan oleh anggota tim sesuai dengan semua standar internal.
• Permintaan fitur dibuat dalam tugas terpisah dan berpartisipasi dalam nominasi terpisah.
• Tim audit memantau kepatuhan terhadap semua aturan.

Detail lainnya

• Awalnya, saya ingin melakukan acara pengujian "lanjutan", tapi... Cukup banyak orang dari tim non-produk yang mendaftar (SMM, pengacara, PR), kami harus menyederhanakan konten dan menghapus kasus yang rumit/profil.
• Karena pekerjaan unit di Jira dalam proyek yang berbeda, menurut alur kami, kami secara khusus membuat proyek terpisah di mana kami menyiapkan templat untuk memperkenalkan bug.
• Untuk menghitung poin, mereka berencana menggunakan leaderboard yang diupdate melalui webhook, namun terjadi error dan pada akhirnya penghitungan harus dilakukan secara manual.

Setiap orang mengalami masalah saat mengatur acara, dan untuk memudahkan Anda, saya akan menjelaskan masalah yang dapat Anda hindari.

Salah satu pembicara tiba-tiba jatuh sakit dan harus mencari yang baru.
Saya sangat beruntung menemukan pengganti dari tim yang sama pada jam 9 pagi). Namun lebih baik tidak mengandalkan keberuntungan dan memiliki cadangan. Atau bersiaplah untuk memberikan sendiri laporan yang diperlukan.

Kami tidak punya waktu untuk meluncurkan fungsinya, kami harus menukar bloknya.
Untuk menghindari membuang seluruh blok, lebih baik memiliki rencana cadangan.

Beberapa pengguna uji dihentikan, kami harus segera membuat ulang pengguna baru.
Periksa ulang pengguna tes terlebih dahulu atau dapat melakukannya dengan cepat.

Hampir tidak ada orang yang formatnya disederhanakan datang.
Tidak perlu menyeret siapa pun dengan paksa. Rendahkan dirimu.
Ada opsi untuk menentukan secara ketat format acara: “amatir”/”lanjutan”, atau menyiapkan dua opsi sekaligus dan memutuskan mana yang akan diadakan setelah acara berlangsung.

Poin organisasi yang berguna:

• pesan pertemuan terlebih dahulu;
• atur meja, jangan lupakan kabel ekstensi dan pelindung lonjakan arus (pengisian daya laptop/ponsel mungkin tidak cukup untuk sepanjang hari);
• mengotomatiskan proses penilaian;
• menyiapkan tabel peringkat;
• membuat selebaran kertas dengan login dan kata sandi pengguna uji, instruksi untuk bekerja dengan Jira, skrip;
• Jangan lupa untuk mengirimkan pengingat seminggu sebelum acara, dan juga menunjukkan apa yang perlu Anda bawa (laptop/perangkat);
• beri tahu kolega Anda tentang acara tersebut saat demo, saat makan siang, sambil minum kopi;
• setuju dengan pengembang untuk tidak memperbarui atau meluncurkan apa pun pada hari ini;
• menyiapkan pembicara;
• bernegosiasi dengan pemilik fitur dan menulis lebih banyak skenario untuk pengujian;
• memesan suguhan (kue/permen) untuk makanan ringan;
• jangan lupa beritahu kami tentang hasil acaranya.

Temuan

Sepanjang hari, mereka berhasil menguji 4 proyek dan membuat 192 bug (134 di antaranya unik) dan 7 masalah dengan permintaan fitur. Tentu saja pemilik proyek sudah mengetahui beberapa bug ini. Namun ada juga penemuan yang tidak terduga.

Semua peserta mendapat hadiah manis.

Dan pemenangnya adalah termos, lencana, kaus.

Yang ternyata menarik:

• para peserta merasa bahwa format sesi yang sulit tidak terduga, ketika waktu terbatas dan Anda tidak dapat menghabiskan banyak waktu untuk berpikir;
• berhasil menguji desktop, versi seluler, dan aplikasi;
• kami melihat banyak proyek sekaligus, tidak ada waktu untuk merasa bosan;
• bertemu rekan-rekan yang berbeda, melihat pendekatan mereka dalam memperkenalkan bug;
• merasakan semua kesakitan para penguji.

Apa yang dapat ditingkatkan:

• mengerjakan lebih sedikit proyek dan menambah waktu sesi menjadi 1,5 jam;
• menyiapkan hadiah/cinderamata jauh sebelumnya (terkadang persetujuan/pembayaran membutuhkan waktu satu bulan);
• santai saja dan terima bahwa sesuatu tidak akan berjalan sesuai rencana dan akan terjadi force majeure.

ulasan

Anna Bystrikova, administrator sistem: “Almshouse ini sangat mendidik bagi saya. Saya mempelajari proses pengujian dan merasakan semua “rasa sakit” para penguji.
Pada awalnya, selama proses pengujian, sebagai pengguna teladan, Anda memeriksa poin utama: apakah tombol diklik, apakah masuk ke halaman, apakah tata letak telah berpindah. Namun kemudian Anda menyadari bahwa Anda perlu berpikir lebih out of the box dan mencoba “merusak” aplikasi tersebut. Penguji memiliki pekerjaan yang sulit; “menyodok” seluruh antarmuka saja tidak cukup; Anda perlu mencoba berpikir out of the box dan sangat berhati-hati.
Kesannya hanya positif, bahkan sekarang, beberapa saat setelah kejadian, saya melihat bagaimana perbaikan bug yang saya temukan sedang dilakukan. Senang rasanya bisa terlibat dalam penyempurnaan produk ^_^.”

Dmitry Seleznev, pengembang front-end: “Pengujian dalam mode kompetitif sangat memotivasi kami untuk menemukan lebih banyak bug). Menurut saya, setiap orang harus mencoba berpartisipasi dalam Baghunting. Pengujian eksplorasi memungkinkan Anda menemukan kasus-kasus yang tidak dijelaskan dalam rencana pengujian. Ditambah lagi, orang-orang yang belum mengetahui proyek tersebut dapat memberikan masukan mengenai kenyamanan layanan.”

Antonina Tatchuk, editor senior: “Saya suka mencoba diri saya sendiri sebagai penguji. Ini adalah gaya kerja yang sangat berbeda. Anda mencoba merusak sistem, bukan berteman dengannya. Kami selalu mempunyai kesempatan untuk menanyakan sesuatu kepada kolega kami tentang pengujian. Saya belajar lebih banyak tentang memprioritaskan bug (misalnya, saya terbiasa mencari kesalahan tata bahasa dalam teks, tetapi “bobot” bug tersebut sangat kecil; dan sebaliknya, sesuatu yang tampaknya tidak terlalu penting bagi saya akhirnya menjadi bug kritis, yang segera diperbaiki).
Pada acara tersebut, para peserta memberikan rangkuman teori pengujian. Ini berguna bagi orang-orang non-teknis. Dan beberapa hari kemudian saya mendapati diri saya berpikir bahwa saya sedang menulis untuk mendukung situs lain menggunakan rumus “apa-di mana-kapan” dan menjelaskan secara rinci ekspektasi saya terhadap situs tersebut dan kenyataan.”

Kesimpulan

Jika Anda ingin mendiversifikasi kehidupan tim Anda, lihat fungsionalitasnya dengan segar, atur mini "Makan makanan anjingmu sendiri", lalu anda bisa mencoba mengadakan acara seperti itu, lalu kita bisa mendiskusikannya bersama.

Semua yang terbaik dan lebih sedikit bug!

Sumber: www.habr.com