Halo semuanya! Nama saya Julia dan saya seorang tester. Tahun lalu saya bercerita tentang Bagelnya - sebuah acara yang diadakan di perusahaan kami untuk membersihkan tumpukan bug. Ini adalah opsi yang sangat layak untuk menguranginya secara signifikan (dalam tim yang berbeda dari 10 hingga 50%) hanya dalam satu hari.

Hari ini saya ingin memberi tahu Anda tentang format musim semi dari Toko Koper kami - BUgHunting (BUH). Kali ini kami tidak memperbaiki bug lama, tetapi mencari bug baru dan menawarkan fitur. Di bawah potongan banyak detail tentang organisasi acara seperti itu, hasil kami dan umpan balik dari para peserta.

Setelah memikirkan dan menetapkan aturan, kami mengirim undangan ke semua saluran di Slack perusahaan, di mana tidak ada batasan:

Hasilnya, sekitar 30 orang mendaftar - baik pengembang maupun spesialis non-teknis. Mereka mengalokasikan seluruh hari kerja untuk acara tersebut, memesan ruang rapat besar, dan mengatur makan malam di kantin kantor.

Mengapa

Tampaknya setiap tim sedang menguji fungsinya. Pengguna akan melaporkan bug kepada kami. Mengapa bahkan mengadakan acara seperti itu?

Kami memiliki beberapa tujuan.

1. Perkenalkan orang-orang lebih dekat ke proyek / produk terkait .
   Sekarang di perusahaan kami semua orang bekerja dalam tim yang terpisah - unit. Ini adalah tim desain yang melihat bagian mereka dari fungsi dan tidak selalu sepenuhnya menyadari apa yang terjadi di proyek lain.
2. Cukup perkenalkan kolega satu sama lain .
   Kami memiliki hampir 800 karyawan di kantor Moskwa, tidak semua rekan kerja mengenal satu sama lain secara langsung.
3. Tingkatkan keterampilan mencari bug di antara pengembang di produk mereka .
   Kami saat ini sedang mempromosikan Agile Testing dan memompa orang-orang ke arah ini.
4. Libatkan tidak hanya pakar teknis dalam pengujian .
   Selain departemen teknis, kami memiliki banyak kolega dari spesialisasi lain yang ingin berbicara lebih banyak tentang pengujian, tentang cara melaporkan dengan benar, sehingga kami menerima lebih sedikit pesan dalam format "Ahhh ... tidak ada yang berhasil".
5. Yah, tentu saja, temukan bug yang rumit dan tidak terlihat .
   Saya ingin membantu tim menguji fitur baru dan memberikan kesempatan untuk melihat fungsionalitas yang diimplementasikan dari sudut yang berbeda.

Implementasi

Hari kami terdiri dari beberapa blok:

• pengarahan;
• Ceramah singkat tentang pengujian, di mana kami hanya menyentuh pada poin utama (tujuan dan prinsip pengujian, dll.);
• bagian tentang "perilaku yang baik" ketika melembagakan serangga (prinsip-prinsipnya dijelaskan dengan baik di sini );
• empat sesi pengujian untuk proyek dengan skrip tingkat tinggi; sebelum setiap sesi ada kuliah pengantar singkat tentang proyek dan distribusi ke tim;
• survei singkat acara;
• meringkas.

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

Aturan dasar

• Pendaftaran untuk acara adalah perorangan , yang memecahkan masalah mengeringkan inersia seluruh tim jika satu orang memutuskan untuk tidak pergi.
• Setiap sesi, para peserta mengubah tim . Hal ini memungkinkan peserta untuk pergi dan datang kapan saja, dan Anda juga dapat berkenalan dengan banyak orang.
• Tim yang terdiri dari dua orang sebelum setiap sesi dibentuk secara acak , sehingga menjadi lebih dinamis dan lebih cepat.
• Poin diberikan untuk bug yang rusak (dari 3 hingga 10) tergantung pada tingkat kekritisannya .
• Tidak ada poin yang diberikan untuk ganda.
• Bug harus dimulai oleh anggota tim sesuai dengan semua standar internal.
• Exclusiveekvesta memulai tugas yang terpisah dan berpartisipasi dalam nominasi yang terpisah.
• Kepatuhan terhadap semua aturan dipantau oleh tim audit.

Detail lainnya

• Awalnya, saya ingin melakukan acara tes "lanjutan", tetapi karena cukup banyak orang dari tim non-produktif (SMM, pengacara, PR) mendaftar, saya harus sangat menyederhanakan konten dan menghapus kasus rumit / khusus.
• Karena pekerjaan unit di Jira dalam proyek yang berbeda, menurut aliran kami, kami secara khusus membuat proyek terpisah di mana kami menyiapkan templat untuk membuat bug.
• Untuk penilaian, kami berencana untuk menggunakan leaderboard, yang diperbarui melalui webhooks, tetapi ada yang salah dan akibatnya, perhitungan harus dilakukan secara manual.

Saat mengatur acara, semua orang berlari menyapu dan untuk membuatnya sedikit lebih mudah, saya akan menjelaskan masalah kami yang dapat Anda hindari.

Salah satu pembicara tiba-tiba jatuh sakit dan harus mencari yang baru .
Saya sangat beruntung bahwa saya menemukan pengganti dari tim yang sama pada jam 9 pagi). Tetapi lebih baik tidak mengandalkan keberuntungan dan memiliki cadangan. Atau diri Anda siap untuk memberi tahu laporan yang diinginkan.

Kami tidak berhasil meluncurkan fungsionalitas, kami harus menukar blok .
Agar tidak membuang seluruh blok, lebih baik memiliki rencana cadangan.

Beberapa pengguna tes turun, saya harus dengan cepat membuat yang baru .
Periksa kembali pengguna uji di muka atau miliki peluang untuk membuatnya dengan cepat.

Hampir tidak ada orang yang formatnya disederhanakan datang .
Anda tidak perlu menyeret siapa pun dengan paksa. Merendahkan dirimu.
Ada opsi untuk secara tegas menentukan format acara: "amatir" / "lanjutan", atau untuk menyiapkan dua opsi sekaligus dan memutuskan apa yang harus dilakukan.

Poin organisasi yang berguna:

• memesan ruang rapat terlebih dahulu;
• mengatur meja, jangan lupa tentang kabel ekstensi dan pelindung lonjakan arus (pengisian laptop / telepon sepanjang hari mungkin tidak cukup);
• Mengotomatiskan proses penilaian;
• menyiapkan tabel peringkat;
• membuat makalah kertas dengan login dan kata sandi pengguna tes, instruksi untuk bekerja dengan Jira, skrip;
• Jangan lupa untuk mengirim pengingat seminggu sebelum acara, tunjukkan juga apa yang perlu Anda bawa (laptop / perangkat);
• beri tahu kolega tentang acara di demo, saat makan malam, sambil minum kopi;
• setuju dengan devops untuk tidak memperbarui atau meluncurkan apa pun pada hari ini;
• menyiapkan pembicara;
• setuju dengan pemilik fitur dan menulis lebih banyak skrip untuk pengujian;
• memesan makanan ringan (kue / permen) untuk makanan ringan;
• Jangan lupa membicarakan hasil acara.

Hasil

Sepanjang hari, mereka berhasil menguji 4 proyek dan mendapatkan 192 bug (134 di antaranya unik) dan 7 tugas dengan permintaan fitur. Tentu saja, pemilik proyek sudah tahu tentang beberapa bug ini. Tetapi ada penemuan tak terduga.

Semua peserta menerima hadiah manis.

Dan pemenangnya adalah thermose, badge, sweatshirts.

Apa yang ternyata menarik:

• format sesi yang sulit tidak terduga untuk para peserta, ketika waktu terbatas dan Anda tidak dapat menghabiskan banyak waktu untuk memikirkannya;
• Saya berhasil menguji desktop, versi seluler, dan aplikasi;
• melihat banyak proyek sekaligus, tidak ada waktu untuk bosan;
• bertemu dengan kolega yang berbeda, melihat pendekatan mereka terhadap pembentukan bug;
• merasakan sakitnya penguji.

Apa yang bisa ditingkatkan:

• melakukan lebih sedikit proyek dan menambah waktu sesi menjadi 1,5 jam;
• menyiapkan hadiah / suvenir jauh di muka (kadang-kadang koordinasi / pembayaran berlangsung selama sebulan);
• bersantai dan menerima kenyataan bahwa ada sesuatu yang salah dan akan ada force majeure.

Ulasan

Anna Bystrikova, administrator sistem: “Toko bagasi sangat informatif bagi saya. Saya belajar proses pengujian, merasakan semua "rasa sakit" para penguji.
Pada awalnya, selama proses pengujian, sebagai perkiraan pengguna, Anda memeriksa poin utama: apakah tombol menyodok, pergi ke halaman, apakah tata letak pindah. Tetapi kemudian Anda memahami bahwa Anda perlu berpikir lebih tidak standar dan mencoba untuk "merusak" aplikasi. Penguji memiliki pekerjaan yang sulit, sedikit untuk "menembus" seluruh antarmuka, Anda perlu mencoba berpikir di luar kotak dan menjadi sangat perhatian.
Hanya tayangan positif yang tersisa, bahkan sekarang, beberapa saat setelah acara, saya melihat bagaimana pekerjaan dilakukan pada bug yang saya temukan. Sangat keren merasa terlibat dalam meningkatkan produk ^ _ ^. "

Dmitry Seleznev, pengembang front-end : "Pengujian dalam mode kompetitif sangat memotivasi menemukan lebih banyak bug). Menurut saya, semua orang perlu mencoba untuk berpartisipasi dalam Baghanting. Pengujian penelitian memungkinkan Anda menemukan kasus-kasus yang tidak dijelaskan dalam rencana pengujian. Selain itu, orang yang tidak tahu proyek dapat memberikan umpan balik tentang kenyamanan layanan. "

Antonina Tatchuk, editor senior : “Saya suka mencoba sendiri sebagai penguji. Ini adalah gaya kerja yang sangat berbeda. Anda mencoba merusak sistem, bukan berteman dengannya. Kami selalu memiliki kesempatan untuk bertanya kepada rekan kerja kami tentang pengujian. Saya belajar lebih banyak tentang memprioritaskan bug (misalnya, saya terbiasa mencari kesalahan tata bahasa dalam teks, tetapi "bobot" bug semacam itu sangat kecil; dan sebaliknya, sesuatu yang menurut saya tidak terlalu penting ternyata adalah bug kritis yang segera diperbaiki )
Di acara tersebut, para lelaki memberi tekanan dari teori pengujian. Ini berguna bagi para profesional non-teknis. Beberapa hari kemudian saya mendapati diri saya berpikir bahwa saya menulis dalam mendukung situs lain menggunakan formula "apa-dimana-kapan" dan menjelaskan secara rinci harapan saya dari situs dan kenyataan.

Kesimpulan

Jika Anda ingin mendiversifikasi kehidupan tim, lihat dengan fungsionalitas yang baru, atur mini "Makan makanan anjing Anda sendiri" , maka Anda dapat mencoba mengadakan acara seperti itu, dan kemudian kita dapat membahasnya bersama.

Semua bug baik dan kurang!