Kamusta kayong lahat! Ang pangalan ko ay Yulia at ako ay isang tester. Noong nakaraang taon sinabi ko sa iyo ang tungkol sa Bagodelnya - isang kaganapan na ginanap sa aming kumpanya upang linisin ang backlog ng bug. Ito ay isang ganap na mabubuhay na opsyon upang makabuluhang bawasan ito (iba't ibang mga koponan mula 10 hanggang 50%) sa isang araw lamang.

Ngayon gusto kong sabihin sa iyo ang tungkol sa aming spring Bagodelny format - BUgHunting (BUH). Sa pagkakataong ito, hindi namin inayos ang mga lumang bug, ngunit naghanap kami ng mga bago at iminungkahing ideya para sa mga feature. Sa ibaba ng cut ay maraming mga detalye tungkol sa organisasyon ng mga naturang kaganapan, ang aming mga resulta at feedback mula sa mga kalahok.

Matapos maisip at isulat ang mga regulasyon, nagpadala kami ng imbitasyon sa lahat ng channel sa corporate Slack, na walang anumang mga paghihigpit:

Bilang resulta, humigit-kumulang 30 tao ang nag-sign up - parehong mga developer at hindi teknikal na mga espesyalista. Naglaan kami ng isang buong araw ng trabaho para sa kaganapan, nag-book ng malaking meeting room, at nag-ayos ng mga tanghalian sa canteen ng opisina.

Bakit?

Tila sinusuri ng bawat koponan ang paggana nito. Ang mga user ay nag-uulat ng mga bug sa amin. Bakit pa nagdaos ng ganitong kaganapan?

Nagkaroon kami ng ilang layunin.

1. Ipakilala ang mga lalaki na mas malapit sa mga kaugnay na proyekto/produkto.
   Ngayon sa aming kumpanya lahat ay nagtatrabaho sa magkakahiwalay na mga koponan - mga yunit. Ito ang mga team ng proyekto na gumagawa sa sarili nilang bahagi ng functionality at hindi palaging lubos na nakakaalam kung ano ang nangyayari sa ibang mga proyekto.
2. Ipakilala lang ang iyong mga kasamahan sa isa't isa.
   Mayroon kaming halos 800 empleyado sa aming tanggapan sa Moscow; hindi lahat ng mga kasamahan ay kilala ang isa't isa sa pamamagitan ng paningin.
3. Pahusayin ang kakayahan ng mga developer na makahanap ng mga bug sa kanilang mga produkto.
   Pino-promote namin ngayon ang Agile Testing at pagsasanay sa mga lalaki sa direksyong ito.
4. Isali ang higit pa sa mga teknikal na espesyalista sa pagsubok.
   Bilang karagdagan sa teknikal na departamento, marami kaming kasamahan mula sa iba pang mga specialty na gustong magsalita nang higit pa tungkol sa pagsubok, tungkol sa kung paano maayos na mag-ulat ng bug upang mas kaunting mensahe ang aming matanggap tulad ng "Ahhh... walang gumagana."
5. At, siyempre, maghanap ng mga nakakalito at hindi halatang mga bug.
   Gusto kong tulungan ang mga team na subukan ang mga bagong feature at bigyan sila ng pagkakataong tingnan ang ipinatupad na functionality mula sa ibang anggulo.

Pagpapatupad

Ang aming araw ay binubuo ng ilang mga bloke:

• briefing;
• isang maikling panayam tungkol sa pagsubok, kung saan ang mga pangunahing punto lamang ang aming binanggit (mga layunin at prinsipyo ng pagsubok, atbp.);
• seksyon sa "mga tuntunin ng mabuting asal" kapag nagpapakilala ng mga bug (dito ang mga prinsipyo ay mahusay na inilarawan);
• apat na sesyon ng pagsubok para sa mga proyektong may mataas na antas na inilarawang mga sitwasyon; bago ang bawat sesyon ay mayroong maikling panimulang panayam sa proyekto at paghahati sa mga pangkat;
• maikling survey sa kaganapan;
• pagbubuod.

(Hindi rin namin nakalimutan ang tungkol sa mga pahinga sa pagitan ng mga sesyon at tanghalian).

Pangunahing panuntunan

• Ang pagpaparehistro para sa mga kaganapan ay indibidwal, na lumulutas sa problema ng buong koponan na nag-draining dahil sa pagkawalang-galaw kung ang isang tao ay nagpasya na hindi pumunta.
• Ang mga kalahok ay nagbabago ng mga koponan bawat sesyon. Nagbibigay-daan ito sa mga kalahok na pumunta at pumunta anumang oras, at makakakilala ka rin ng mas maraming tao.
• Mga Koponan dalawang tao bago ang bawat sesyon ay nabuo nang random, ginagawa nitong mas dynamic at mas mabilis.
• Para sa mga ipinakilalang bug ikaw ay iginawad puntos (mula 3 hanggang 10) depende sa pagiging kritikal.
• Walang ibibigay na puntos para sa mga duplicate.
• Ang mga bug ay dapat isampa ng isang miyembro ng koponan ayon sa lahat ng panloob na pamantayan.
• Ang mga kahilingan sa tampok ay ginawa sa isang hiwalay na gawain at lumahok sa isang hiwalay na nominasyon.
• Sinusubaybayan ng audit team ang pagsunod sa lahat ng panuntunan.

Iba pang mga detalye

• Sa una, gusto kong gumawa ng isang "advanced" na kaganapan sa pagsubok, ngunit... Napakaraming lalaki mula sa mga pangkat na hindi produkto ang nag-sign up (SMM, abogado, PR), kailangan naming gawing simple ang content at alisin ang mga kumplikadong/profile na kaso.
• Dahil sa gawain ng mga unit sa Jira sa iba't ibang proyekto, ayon sa aming daloy, espesyal kaming gumawa ng hiwalay na proyekto kung saan nag-set up kami ng template para sa pagpasok ng mga bug.
• Upang kalkulahin ang mga puntos, binalak nilang gumamit ng leaderboard na na-update sa pamamagitan ng webhooks, ngunit may nangyaring mali at sa huli ang pagkalkula ay kailangang gawin nang manu-mano.

Lahat ay nagkakaproblema kapag nag-o-organize ng mga event, at para maging mas madali para sa iyo, ilalarawan ko ang aming mga problema na maaari mong iwasan.

Ang isa sa mga nagsasalita ay biglang nagkasakit at kailangang maghanap ng bago.
Napakaswerte ko na nakahanap ako ng kapalit mula sa parehong koponan noong 9 am). Ngunit mas mabuting huwag umasa sa suwerte at magkaroon ng ekstra. O maging handa na magbigay ng kinakailangang ulat sa iyong sarili.

Wala kaming oras upang ilunsad ang pag-andar, kailangan naming magpalit ng mga bloke.
Upang maiwasan ang pagtatapon ng isang buong bloke, mas mahusay na magkaroon ng backup na plano.

Ang ilang mga gumagamit ng pagsubok ay bumaba, kailangan naming mabilis na muling lumikha ng mga bago.
I-cross-check ang mga user ng pagsubok nang maaga o magagawa sila nang mabilis.

Halos wala sa mga lalaki kung saan pinasimple ang format ang dumating.
Hindi na kailangang kaladkarin ang sinuman sa pamamagitan ng puwersa. Magpakumbaba.
Mayroong isang opsyon na mahigpit na magreseta ng format ng kaganapan: "amateur"/"advanced", o maghanda ng dalawang opsyon nang sabay-sabay at magpasya kung alin ang hahawakan pagkatapos ng katotohanan.

Mga kapaki-pakinabang na punto ng organisasyon:

• mag-book ng isang pulong nang maaga;
• ayusin ang mga talahanayan, huwag kalimutan ang tungkol sa mga extension cord at surge protector (maaaring hindi sapat ang pagsingil sa mga laptop/telepono para sa buong araw);
• i-automate ang proseso ng pagmamarka;
• maghanda ng mga talahanayan ng ranggo;
• gumawa ng mga handout ng papel na may mga pag-login at password ng mga gumagamit ng pagsubok, mga tagubilin para sa pagtatrabaho sa Jira, mga script;
• Huwag kalimutang magpadala ng mga paalala isang linggo bago ang kaganapan, at ipahiwatig din kung ano ang kailangan mong dalhin sa iyo (mga laptop/device);
• sabihin sa iyong mga kasamahan ang tungkol sa kaganapan sa isang demo, sa mga tanghalian, sa isang tasa ng kape;
• sumang-ayon sa mga devops na hindi mag-update o maglunsad ng anumang bagay sa araw na ito;
• maghanda ng mga tagapagsalita;
• makipag-ayos sa mga may-ari ng tampok at magsulat ng higit pang mga senaryo para sa pagsubok;
• mag-order ng mga treat (cookies/candies) para sa meryenda;
• huwag kalimutang sabihin sa amin ang tungkol sa mga resulta ng kaganapan.

Natuklasan

Sa buong araw, nagawa ng mga lalaki na subukan ang 4 na proyekto at lumikha ng 192 bug (134 sa mga ito ay natatangi) at 7 isyu sa mga kahilingan sa tampok. Siyempre, alam na ng mga may-ari ng proyekto ang tungkol sa ilan sa mga bug na ito. Ngunit mayroon ding mga hindi inaasahang paghahanap.

Lahat ng kalahok ay tumanggap ng matatamis na papremyo.

At ang mga nanalo ay thermoses, badge, sweatshirts.

Ano ang naging kawili-wili:

• ang mga kalahok ay natagpuan ang format ng mahihirap na sesyon na hindi inaasahan, kapag ang oras ay limitado at hindi ka maaaring gumugol ng maraming oras sa pag-iisip;
• nagawang subukan ang desktop, mobile na bersyon at mga application;
• sabay-sabay kaming tumingin sa maraming proyekto, walang oras para magsawa;
• nakilala ang iba't ibang mga kasamahan, tumingin sa kanilang mga diskarte sa pagpapakilala ng mga bug;
• naramdaman ang lahat ng sakit ng mga sumusubok.

Ano ang maaaring mapabuti:

• gumawa ng mas kaunting mga proyekto at taasan ang oras ng session sa 1,5 oras;
• maghanda ng mga regalo/souvenir nang mas maaga (kung minsan ang pag-apruba/pagbayad ay tumatagal ng isang buwan);
• relax at tanggapin na may hindi mangyayari ayon sa plano at magkakaroon ng force majeure.

Mga review

Anna Bystrikova, tagapangasiwa ng system: “Napaka-educational sa akin ng almshouse. Natutunan ko ang proseso ng pagsubok at naramdaman ko ang lahat ng "sakit" ng mga tester.
Sa una, sa panahon ng proseso ng pagsubok, bilang isang huwarang user, sinusuri mo ang mga pangunahing punto: kung nag-click ang button, kung pupunta ito sa page, kung ang layout ay inilipat na. Ngunit sa paglaon ay napagtanto mo na kailangan mong mag-isip nang higit pa sa labas ng kahon at subukang "masira" ang aplikasyon. Ang mga tagasubok ay may mahirap na trabaho; hindi sapat na "sundutin" ang buong interface; kailangan mong subukang mag-isip sa labas ng kahon at maging lubhang matulungin.
Ang mga impression ay positibo lamang, kahit ngayon, ilang oras pagkatapos ng kaganapan, nakikita ko kung paano ginagawa ang trabaho sa mga bug na nakita ko. Napakagandang pakiramdam na kasangkot sa pagpapabuti ng produkto ^_^.”

Dmitry Seleznev, front-end developer: "Ang pagsubok sa competitive mode ay lubos na nag-uudyok sa amin na makahanap ng higit pang mga bug). Para sa akin, dapat subukan ng lahat na lumahok sa Baghunting. Nagbibigay-daan sa iyo ang Exploratory testing na mahanap ang mga kasong iyon na hindi inilarawan sa test plan. Dagdag pa, ang mga taong hindi alam ang proyekto ay maaaring magbigay ng feedback sa kaginhawahan ng serbisyo."

Antonina Tatchuk, senior editor: "Nagustuhan kong subukan ang aking sarili bilang isang tester. Ito ay isang ganap na naiibang istilo ng trabaho. Sinusubukan mong sirain ang sistema, hindi makipagkaibigan dito. Palagi kaming may pagkakataon na magtanong sa aming mga kasamahan tungkol sa pagsubok. Natutunan ko ang higit pa tungkol sa pagbibigay-priyoridad sa mga bug (halimbawa, sanay akong maghanap ng mga grammatical error sa mga teksto, ngunit ang "bigat" ng naturang bug ay napakaliit; at kabaliktaran, isang bagay na tila hindi masyadong mahalaga sa akin ay nauwi sa pagiging isang kritikal na bug, na agad na naayos ).
Sa kaganapan, ang mga lalaki ay nagbigay ng isang buod ng teorya ng pagsubok. Ito ay kapaki-pakinabang para sa mga hindi teknikal na tao. At pagkaraan ng ilang araw, naisip ko na nagsusulat ako bilang suporta sa isa pang site gamit ang formula na "ano-saan-kailan" at inilalarawan nang detalyado ang aking mga inaasahan mula sa site at katotohanan."

Konklusyon

Kung nais mong pag-iba-ibahin ang buhay ng iyong koponan, tingnan ang bagong pag-andar, ayusin ang isang mini "Kumain ka ng sarili mong pagkain ng aso", pagkatapos ay maaari mong subukang magsagawa ng ganoong kaganapan, at pagkatapos ay maaari nating talakayin ito nang magkasama.

Lahat ng pinakamahusay at mas kaunting mga bug!

Pinagmulan: www.habr.com