Hej alla! Jag heter Yulia och jag är en testare. Förra året berättade jag om Bagodelnya - ett evenemang som hölls i vårt företag för att rensa ut buggstocken. Detta är ett helt genomförbart alternativ för att avsevärt minska den (från 10 till 50 % i olika team) på bara en dag.

Idag vill jag berätta om vårt vårens Bagodelny-format - BUgHunting (BUH). Den här gången fixade vi inte gamla buggar, utan letade efter nya och föreslog idéer till funktioner. Under snittet finns många detaljer om hur sådana evenemang organiseras, våra resultat och feedback från deltagarna.

Efter att ha tänkt igenom och skrivit ner regelverket skickade vi ut en inbjudan till alla kanaler i corporate Slack, som inte innehöll några restriktioner:

Som ett resultat skrev ett 30-tal personer upp sig – både utvecklare och icke-tekniska specialister. Vi avsatte en hel arbetsdag för evenemanget, bokade ett stort mötesrum och ordnade luncher i kontorets matsal.

Varför?

Det verkar som att varje lag testar sin funktionalitet. Användare rapporterar buggar till oss. Varför ens hålla ett sådant evenemang?

Vi hade flera mål.

Presentera killarna närmare relaterade projekt/produkter.
Nu i vårt företag arbetar alla i separata team - enheter. Det är projektteam som arbetar med sin egen del av funktionaliteten och som inte alltid är helt medvetna om vad som händer i andra projekt.
Presentera bara dina kollegor för varandra.
Vi har nästan 800 anställda på vårt kontor i Moskva, alla kollegor känner inte varandra från synen.
Förbättra utvecklarnas förmåga att hitta buggar i sina produkter.
Vi främjar nu Agile Testing och utbildar killar i denna riktning.
Involvera mer än bara tekniska specialister i testning.
Förutom den tekniska avdelningen har vi många kollegor från andra specialiteter som ville prata mer om testning, om hur man korrekt rapporterar en bugg så att vi får färre meddelanden som "Ahhh... ingenting fungerar."
Och, naturligtvis, hitta knepiga och otydliga buggar.
Jag ville hjälpa team att testa nya funktioner och ge dem möjlighet att se på den implementerade funktionaliteten från en annan vinkel.

genomförande

Vår dag bestod av flera block:

briefing;
en kort föreläsning om testning, där vi endast berörde huvudpunkterna (mål och principer för testning etc.);
avsnitt om "regler för gott uppförande" när man introducerar buggar (här principerna är väl beskrivna);
fyra testsessioner för projekt med beskrivna scenarier på hög nivå; före varje pass var det en kort introduktionsföreläsning om projektet och indelning i team;
kort undersökning om evenemanget;
sammanfatta.

(Vi glömde inte heller pauser mellan pass och lunch).

Grundläggande regler

Anmälan till evenemang är individuell, vilket löser problemet med att hela laget dränerar på grund av tröghet om en person bestämmer sig för att inte gå.
Deltagarna byter lag varje pass. Detta gör att deltagarna kan komma och gå när som helst, och du kan också träffa fler människor.
kommandon två personer före varje pass bildas slumpmässigt, detta gör den mer dynamisk och snabbare.
För introducerade buggar belönas du poäng (från 3 till 10) beroende på kritikalitet.
Inga poäng ges för dubbletter.
Buggar måste arkiveras av en gruppmedlem enligt alla interna standarder.
Funktionsförfrågningar skapas i en separat uppgift och deltar i en separat nominering.
Revisionsteamet övervakar efterlevnaden av alla regler.

Andra detaljer

Från början ville jag göra ett "avancerat" testevenemang, men... Ganska många killar från icke-produktteam anmälde sig (SMM, advokater, PR), vi var tvungna att avsevärt förenkla innehållet och ta bort komplexa/profilerade fall.
På grund av arbetet med enheter i Jira i olika projekt, enligt vårt flöde, skapade vi speciellt ett separat projekt där vi satte upp en mall för att introducera buggar.
För att räkna ut poäng planerade de att använda en leaderboard som uppdaterades via webhooks, men något gick fel och till slut fick uträkningen göras manuellt.

Alla stöter på problem när de organiserar evenemang och för att göra det lite lättare för dig kommer jag att beskriva våra problem som du kan undvika.

En av talarna blev plötsligt sjuk och var tvungen att hitta en ny.
Jag hade en enorm tur att jag hittade en ersättare från samma lag klockan 9). Men det är bättre att inte lita på tur och ha en reserv. Eller var beredd att själv lämna den nödvändiga rapporten.

Vi hade inte tid att rulla ut funktionaliteten, vi var tvungna att byta block.
För att undvika att slänga ett helt kvarter är det bättre att ha en reservplan.

Några testanvändare tappade, vi var tvungna att snabbt återskapa nya.
Korskontrollera testanvändare i förväg eller kunna göra dem snabbt.

Nästan ingen av killarna som formatet var förenklat för kom.
Det finns ingen anledning att dra någon med våld. Ödmjuka dig själv.
Det finns ett alternativ att strikt föreskriva evenemangets format: "amatör"/"avancerad", eller förbereda två alternativ samtidigt och bestämma vilket som ska hållas i efterhand.

Användbara organisatoriska punkter:

boka ett möte i förväg;
ordna bord, glöm inte förlängningssladdar och överspänningsskydd (laddning av bärbara datorer/telefoner kanske inte räcker för hela dagen);
automatisera poängprocessen;
förbereda rankningstabeller;
göra pappersutdelningar med inloggningar och lösenord för testanvändare, instruktioner för att arbeta med Jira, skript;
Glöm inte att skicka ut påminnelser en vecka före evenemanget, och även ange vad du behöver ta med dig (bärbara datorer/enheter);
berätta för dina kollegor om evenemanget på en demo, vid luncher, över en kopp kaffe;
håller med devops att inte uppdatera eller rulla ut någonting denna dag;
förbereda högtalare;
förhandla med funktionsägare och skriv fler scenarier för testning;
beställa godsaker (kakor/godis) till mellanmål;
glöm inte att berätta om resultatet av evenemanget.

Resultat

Under hela dagen lyckades killarna testa 4 projekt och skapa 192 buggar (134 av dem unika) och 7 problem med funktionsförfrågningar. Naturligtvis visste projektägarna redan om några av dessa buggar. Men det gjordes också oväntade fynd.

Alla deltagare fick fina priser.

Och vinnarna är termosar, märken, tröjor.

Vad som blev intressant:

deltagarna tyckte att formatet för tuffa sessioner var oväntat, när tiden är begränsad och du inte kan lägga mycket tid på att tänka;
lyckades testa skrivbordet, mobilversionen och applikationerna;
vi tittade på många projekt samtidigt, det fanns ingen tid att bli uttråkad;
träffade olika kollegor, tittat på deras sätt att introducera buggar;
kände all smärta från testarna.

Vad kan förbättras:

göra färre projekt och öka sessionstiden till 1,5 timmar;
förbereda presenter/souvenirer långt i förväg (ibland tar godkännande/betalning en månad);
slappna av och acceptera att något inte kommer att gå enligt plan och det blir force majeure.

omdömen

Anna Bystrikova, systemadministratör: – Allmogestugan är väldigt lärorik för mig. Jag lärde mig testprocessen och kände all "smärta" hos testarna.
Till en början, under testprocessen, kontrollerar du som en exemplarisk användare huvudpunkterna: om knappen klickar, om den går till sidan, om layouten har flyttats ut. Men senare inser du att du måste tänka mer utanför ramarna och försöka "bryta" applikationen. Testare har ett svårt jobb; det räcker inte att "peta" över hela gränssnittet; du måste försöka tänka utanför ramarna och vara extremt uppmärksam.
Intrycken var bara positiva, även nu, en tid efter händelsen, ser jag hur man jobbar med de buggar jag hittade. Det är fantastiskt att känna sig delaktig i att förbättra produkten ^_^.”

Dmitry Seleznev, frontend-utvecklare: "Testa i konkurrensläge motiverar oss i hög grad att hitta fler buggar). Det verkar för mig att alla borde försöka delta i Baghunting. Utforskande testning gör att du kan hitta de fall som inte beskrivs i testplanen. Dessutom kan personer som inte känner till projektet ge feedback om tjänstens bekvämlighet."

Antonina Tatchuk, senior redaktör: ”Jag gillade att prova mig själv som testare. Det här är en helt annan arbetsstil. Du försöker bryta systemet, inte bli vän med det. Vi hade alltid möjlighet att fråga våra kollegor något om att testa. Jag lärde mig mer om att prioritera buggar (jag är till exempel van att leta efter grammatiska fel i texter, men "vikten" av en sådan bugg är väldigt liten; och vice versa, något som inte verkade särskilt viktigt för mig visade sig vara vara en kritisk bugg, som omedelbart åtgärdades).
På eventet gav killarna en sammanfattning av testteori. Detta var användbart för icke-tekniska personer. Och några dagar senare kom jag på mig själv med att tänka att jag skrev till stöd för en annan webbplats med hjälp av formeln "vad-var-när" och beskrev i detalj mina förväntningar från webbplatsen och verkligheten."

Slutsats

Om du vill diversifiera livet för ditt team, ta en ny titt på funktionalitet, arrangera en mini "Ät din egen hundmat", då kan du försöka hålla ett sådant evenemang, och så kan vi diskutera det tillsammans.

Allt det bästa och mindre buggar!

Källa: will.com

Bagelny: BUgHunting. Hur man hittar 200 buggar på en dag