Sveiki visi! Mano vardas Julija ir aš esu testuotojas. Praėjusiais metais aš jums pasakojau apie bagodelnya - mūsų įmonėje surengtas renginys, skirtas pašalinti klaidų skaičių. Tai visiškai perspektyvus variantas, leidžiantis jį žymiai sumažinti (nuo 10 iki 50 % skirtingose ​​komandose) vos per vieną dieną.

Šiandien noriu papasakoti apie mūsų pavasario Bagodelny formatą – BUgHunting (BUH). Šį kartą netaisėme senų klaidų, o ieškojome naujų ir siūlėme idėjų funkcijoms. Žemiau yra daug informacijos apie tokių renginių organizavimą, mūsų rezultatus ir dalyvių atsiliepimus.

Apgalvoję ir surašę nuostatus, išsiuntėme kvietimą visiems įmonės Slack kanalams, kuriame nebuvo jokių apribojimų:

Dėl to užsiregistravo apie 30 žmonių – ir kūrėjų, ir ne techninių specialistų. Renginiui skyrėme visą darbo dieną, užsakėme didelę posėdžių salę, organizavome pietus biuro valgykloje.

Kodėl?

Atrodytų, kiekviena komanda išbando savo funkcionalumą. Vartotojai praneša mums apie klaidas. Kam išvis rengti tokį renginį?

Turėjome kelis tikslus.

1. Supažindinkite vaikinus iš arčiau su susijusiais projektais / produktais.
   Dabar mūsų įmonėje visi dirba atskirose komandose – padaliniuose. Tai yra projektų komandos, kurios dirba su savo funkcionalumo dalimi ir ne visada gerai žino, kas vyksta kituose projektuose.
2. Tiesiog supažindinkite savo kolegas vieni su kitais.
   Mūsų biure Maskvoje dirba beveik 800 darbuotojų, ne visi kolegos vieni kitus pažįsta iš matymo.
3. Pagerinkite kūrėjų gebėjimą aptikti savo produktų klaidas.
   Dabar reklamuojame Agile Testing ir mokome vaikinus šia kryptimi.
4. Į testavimą įtraukite ne tik techninius specialistus.
   Be techninio skyriaus, turime daug kolegų iš kitų specialybių, kurie norėjo daugiau pakalbėti apie testavimą, apie tai, kaip tinkamai pranešti apie klaidą, kad gautume mažiau tokių pranešimų kaip „Ahhh... niekas neveikia“.
5. Ir, žinoma, raskite sudėtingų ir neakivaizdžių klaidų.
   Norėjau padėti komandoms išbandyti naujas funkcijas ir suteikti galimybę pažvelgti į įdiegtas funkcijas kitu kampu.

Vykdymas

Mūsų diena susideda iš kelių blokų:

• instruktažas;
• trumpa paskaita apie testavimą, kurioje palietėme tik pagrindinius dalykus (testavimo tikslus ir principus ir kt.);
• skyrių apie „gerų manierų taisykles“ pristatant klaidas (čia principai yra gerai aprašyti);
• keturios testavimo sesijos projektams su aukšto lygio aprašytais scenarijais; prieš kiekvieną užsiėmimą vyko trumpa įvadinė paskaita apie projektą ir pasiskirstymą į komandas;
• trumpa apklausa apie renginį;
• apibendrinant.

(Nepamiršome ir pertraukų tarp užsiėmimų ir pietų).

Pagrindinės taisyklės

• Registracija į renginius yra individuali, kuris išsprendžia visos komandos išsekimo dėl inercijos problemą, jei vienas žmogus nusprendžia neiti.
• Dalyviai keičia komandas kiekvieną užsiėmimą. Tai leidžia dalyviams ateiti ir išeiti bet kuriuo metu, taip pat galite sutikti daugiau žmonių.
• Komandos du žmonės prieš kiekvieną užsiėmimą susidaro atsitiktinai, tai daro jį dinamiškesnį ir greitesnį.
• Už įvestas klaidas esate apdovanoti balų (nuo 3 iki 10), priklausomai nuo kritiškumo.
• Už dublikatus taškai neskiriami.
• Klaidas turi pateikti komandos narys pagal visus vidinius standartus.
• Funkcijos užklausos sukuriamos atskiroje užduotyje ir dalyvauja atskiroje nominacijoje.
• Audito grupė stebi, kaip laikomasi visų taisyklių.

Kitos detalės

• Iš pradžių norėjau atlikti „išplėstinį“ testavimo renginį, bet... Prisiregistravo gana daug vaikinų iš ne produktų komandų (SMM, teisininkai, viešieji ryšiai), teko labai supaprastinti turinį ir pašalinti sudėtingas/profilines bylas.
• Dėl padalinių darbo Jira įvairiuose projektuose, pagal mūsų srautą, mes specialiai sukūrėme atskirą projektą, kuriame sukūrėme klaidų įvedimo šabloną.
• Taškams skaičiuoti jie planavo naudoti lyderių lentelę, kuri buvo atnaujinta per webhooks, tačiau kažkas nutiko ne taip ir galiausiai teko skaičiuoti rankiniu būdu.

Organizuodami renginius visi susiduria su problemomis, o kad jums būtų šiek tiek lengviau, aprašysiu mūsų problemas, kurių galite išvengti.

Vienas iš garsiakalbių staiga susirgo ir turėjo susirasti naują.
Man nepaprastai pasisekė, kad 9 valandą ryto radau pakaitalą iš tos pačios komandos). Tačiau geriau nepasikliauti sėkme ir turėti atsargų. Arba būkite pasirengę patys pateikti reikiamą ataskaitą.

Neturėjome laiko įdiegti funkcionalumo, turėjome keisti blokus.
Kad neišmestumėte viso bloko, geriau turėti atsarginį planą.

Kai kurių bandomųjų vartotojų sumažėjo, teko greitai iš naujo sukurti naujus.
Iš anksto patikrinkite bandomuosius naudotojus arba galėsite juos atlikti greitai.

Beveik niekas iš vaikinų, kuriems buvo supaprastintas formatas, neatėjo.
Nereikia nieko tempti jėga. Nusižemink.
Yra galimybė griežtai nurodyti renginio formatą: „mėgėjiškas“/„pažengęs“, arba ruošti du variantus iš karto ir nuspręsti, kurį rengti po fakto.

Naudingi organizaciniai punktai:

• iš anksto užsisakykite susitikimą;
• sutvarkykite stalus, nepamirškite ilgintuvų ir apsaugos nuo viršįtampių (nešiojamųjų kompiuterių/telefonų įkrovimo gali neužtekti visai dienai);
• automatizuoti balų skaičiavimo procesą;
• parengti reitingų lenteles;
• padaryti popierinę dalomąją medžiagą su bandomųjų vartotojų prisijungimais ir slaptažodžiais, darbo su Jira instrukcijomis, scenarijais;
• Nepamirškite likus savaitei iki renginio išsiųsti priminimų, taip pat nurodykite, ką turite pasiimti su savimi (nešiojamuosius kompiuterius / įrenginius);
• papasakokite kolegoms apie renginį demonstracijoje, pietų metu, prie kavos puodelio;
• susitarti su devokais šią dieną nieko neatnaujinti ir neleisti;
• paruošti garsiakalbius;
• derėtis su funkcijų savininkais ir parašyti daugiau scenarijų testavimui;
• Užsisakykite skanėstų (sausainių/saldainių) užkandžiams;
• nepamirškite mums papasakoti apie renginio rezultatus.

rezultatai

Per visą dieną vaikinai spėjo išbandyti 4 projektus ir sukurti 192 klaidas (134 iš jų unikalios) ir 7 problemas su funkcijų užklausomis. Žinoma, projekto savininkai jau žinojo apie kai kurias iš šių klaidų. Tačiau buvo ir netikėtų radinių.

Visi dalyviai buvo apdovanoti saldžiais prizais.

O laimėtojai – termosai, ženkliukai, megztiniai.

Kas pasirodė įdomu:

• dalyviams netikėtas buvo sunkių užsiėmimų formatas, kai laikas ribotas ir negalima daug laiko skirti mąstymui;
• pavyko išbandyti darbalaukį, mobiliąją versiją ir programas;
• žiūrėjome daug projektų vienu metu, nebuvo kada nuobodžiauti;
• susitiko su įvairiais kolegomis, pažvelgė į jų požiūrį į klaidų įvedimą;
• pajuto visą bandytojų skausmą.

Ką galima patobulinti:

• atlikti mažiau projektų ir padidinti sesijos laiką iki 1,5 valandos;
• dovanas/suvenyrus ruošti daug iš anksto (kartais patvirtinimas/apmokėjimas užtrunka mėnesį);
• atsipalaiduoti ir susitaikyti su tuo, kad kažkas vyks ne pagal planą ir bus force majeure.

Atsiliepimai

Anna Bystrikova, sistemos administratorė: „Imaldos namas man yra labai edukacinis. Išmokau testavimo procesą ir pajutau visą testuotojų „skausmą“.
Iš pradžių testavimo proceso metu, kaip pavyzdingas vartotojas, tikrinate pagrindinius dalykus: ar mygtukas paspaudžia, ar jis patenka į puslapį, ar išdėstymas nepasislinko. Tačiau vėliau supranti, kad reikia daugiau mąstyti už langelio ribų ir bandyti „sulaužyti“ programą. Testuotojai turi sunkų darbą; neužtenka „pakišti“ per visą sąsają; reikia stengtis mąstyti ne tik iš lauko pusės ir būti itin dėmesingiems.
Įspūdžiai buvo tik teigiami, net ir dabar, praėjus šiek tiek laiko po renginio, matau, kaip dirbama su mano rastomis klaidomis. Puiku jaustis dalyvaujančiam tobulinant produktą ^_^.

Dmitrijus Seleznevas, front-end kūrėjas: „Testavimas konkurenciniu režimu labai motyvuoja mus rasti daugiau klaidų). Man atrodo, kad Baghuntinge turėtų pabandyti dalyvauti visi. Tiriamasis testavimas leidžia rasti tuos atvejus, kurie nėra aprašyti bandymų plane. Be to, žmonės, kurie nežino projekto, gali pateikti atsiliepimų apie paslaugos patogumą.

Antonina Tatchuk, vyresnioji redaktorė: „Man patiko išbandyti save kaip bandytoją. Tai visiškai kitoks darbo stilius. Jūs bandote sugriauti sistemą, o ne su ja susidraugauti. Visada turėjome galimybę ko nors paklausti savo kolegų apie testavimą. Sužinojau daugiau apie klaidų suskirstymą į prioritetus (pavyzdžiui, esu įpratęs tekstuose ieškoti gramatinių klaidų, bet tokios klaidos „svoris“ yra labai mažas; ir atvirkščiai, tai, kas man atrodė nelabai svarbu, baigėsi kritinė klaida, kuri buvo nedelsiant ištaisyta).
Renginyje vaikinai apibendrino testavimo teoriją. Tai buvo naudinga netechniniams žmonėms. Ir po kelių dienų pagavau save galvojantį, kad rašau palaikydamas kitą svetainę, naudodamas formulę „kas-kur-kada“ ir išsamiai aprašydamas savo lūkesčius iš svetainės ir tikrovės.

išvada

Jei norite paįvairinti savo komandos gyvenimą, naujai pažvelkite į funkcionalumą, pasirūpinkite mini „Valgyk savo šunų maistą“, tuomet galite pabandyti surengti tokį renginį, o tada galėsime kartu aptarti.

Viso geriausio ir mažiau klaidų!

Šaltinis: www.habr.com