Hej alle! Mit navn er Julia, og jeg er tester. Sidste Ă„r fortalte jeg jer om â et arrangement, vi afholder i vores virksomhed for at rydde op i bugs i backloggen. Det er en helt levedygtig mĂ„de at reducere den betydeligt (i forskellige teams fra 10 til 50%) pĂ„ blot Ă©n dag.
I dag vil jeg fortĂŠlle jer om vores forĂ„rsformat af Bug Hunt â BUgHunting (BUH). Denne gang fokuserede vi ikke pĂ„ gamle bugs, men ledte efter nye og foreslog idĂ©er til funktioner. Nedenfor finder I mange detaljer om organiseringen af sĂ„danne arrangementer, vores resultater og deltagernes feedback.
Vi udarbejdede og beskrev en regulering og sendte invitationen ud til alle kanaler i virksomhedens Slack, hvor der ikke var nogen begrĂŠnsninger:
I alt tilmeldte omkring 30 personer â bĂ„de udviklere og ikke-tekniske specialister. Der blev afsat en hel arbejdsdag til arrangementet, vi reserverede et stort mĂždelokale, og frokoster blev organiseret gennem kantinen pĂ„ kontoret.
Hvorfor?
Det kunne synes, at hvert team tester sin egen funktionalitet. Brugerne rapporterer bugs til os. Hvorfor overhovedet afholde et sÄdant arrangement?
Vi havde flere mÄl.
- At gĂžre folk bekendt med beslĂŠgtede projekter/produkter..
I Ăžjeblikket arbejder alle i vores virksomhed i separate teams â enheder. Det er projektgrupper, der udvikler deres del af funktionaliteten og ikke altid er fuldt opdaterede om, hvad der sker i andre projekter. - Bare at introducere kolleger for hinanden..
Vi har nÊsten 800 medarbejdere pÄ kontoret i Moskva, og ikke alle kolleger kender hinanden ansigt-til-ansigt. - At forbedre udviklernes evner til at finde bugs i deres produkter..
Vi promoverer i Ăžjeblikket Agile Testing og udvikler medarbejdernes fĂŠrdigheder i denne retning. - At involvere ikke kun tekniske specialister i testning..
Udover den tekniske afdeling har vi mange kolleger med andre specialiteter, som gerne vil vide mere om testning, og om, hvordan man korrekt rapporterer bugs, sÄ vi fÄr fÊrre beskeder som "Aaaah... ingenting virker". - Og selvfÞlgelig at finde snedige og uopdagede bugs..
Vi ville hjÊlpe teamene med at teste nye funktioner og give dem mulighed for at se pÄ den implementerede funktionalitet fra en anden vinkel.
Implementering
Vores dag bestod af flere blokke:
- briefing;
- en kort forelÊsning om testning, hvor vi kun berÞrte de grundlÊggende punkter (mÄl og principper for testning osv.);
- afsnit om 'gode manerer' ved indberetning af fejl ( principperne er godt beskrevet);
- fire testsessioner for projekter med overordnet beskrivelse af scener; fĂžr hver session var der en kort introduktion til projektet og teamfordeling;
- en kort spĂžrgeskema om eventet;
- afslutning.
(Vi glemte heller ikke pauserne mellem sessionerne og frokost).
Hovedregler
- Registreringen til arrangementer er individuel, hvilket lĂžser problemet med, at hele teamet fungerer efter inerti, hvis Ă©n person vĂŠlger ikke at deltage.
- Ved hver session skifter deltagerne team. Det giver deltagerne mulighed for at komme og gÄ nÄr som helst, og man kan ogsÄ mÞde mange flere mennesker.
- Kommandoer to personer fÞr hver session udvÊlges tilfÊldigt, sÄ det bliver mere dynamisk og hurtigere.
- For indberettede fejl tildeles der point (fra 3 til 10) afhĂŠngig af alvorligheden.
- Der tildeles ikke point for duplikater.
- Fejl skal indberettes af et teammedlem i henhold til alle interne standarder.
- Funktionsanmodninger indberettes som en separat opgave og deltager i en separat kategori.
- Teamet for audit overvÄger overholdelsen af alle regler.
Andre detaljer
- Oprindeligt ville vi lave et 'avanseret' testarrangement, men da der tilmeldte sig en del folk fra ikke-produkt teams (SMM, jurister, PR), mÄtte vi forenkle indholdet meget og fjerne komplekse/profilerede cases.
- PÄ grund af enhedernes arbejde i Jira pÄ forskellige projekter med egne workflows oprettede vi et separat projekt, hvor vi opsatte skabelon til indberetning af fejl.
- Vi planlagde at bruge et leaderboard til at tÊlle point, som blev opdateret via webhooks, men noget gik galt, og vi mÄtte til sidst tÊlle dem manuelt.
Alle, der organiserer arrangementer, stÞder pÄ problemer, og for at gÞre det lidt lettere for dig, vil jeg beskrive vores udfordringer, som du kan undgÄ.
En af talerne blev pludselig syg, og vi mÄtte finde en ny.
Jeg var utrolig heldig at finde en erstatning fra samme team kl. 9.) Men det er bedst ikke at stole pÄ heldet og have en backup. Eller at vÊre klar til selv at prÊsentere den nÞdvendige tale.
Vi nÄede ikke at udgive funktionaliteten, sÄ vi mÄtte bytte rundt pÄ blokke..
For ikke at skulle skille sig af med hele blokken, er det bedre at have en backup-plan.
En del af testbrugerne faldt fra, sÄ vi mÄtte hurtigt oprette nye..
Tjek testbrugerne pÄ forhÄnd, eller sÞrg for at kunne lave dem hurtigt.
NĂŠsten ingen af de fyre, som vi forenklede formatet for, mĂždte op..
Ingen skal tvangsmĂŠssigt trĂŠkkes med. Accepter det.
Der er mulighed for at fastlÊgge formatet for arrangementet: 'amatÞr'/'avanseret', eller forberede to versioner og sÄ efterfÞlgende beslutte, hvilken der skal gennemfÞres.
Nyttige organisatoriske punkter:
- book konferencelokalet pÄ forhÄnd;
- arranger bordene, glem ikke forlĂŠngerkabler og strĂžmfiltre (det kan vĂŠre, at opladning af laptops/telefoner ikke holder hele dagen);
- automatiser punktberegningen;
- forbered ranglister;
- lav papirudskrifter med loginoplysninger og adgangskoder til testbrugerne, instruktioner til arbejde med Jira, scenarier;
- glem ikke at sende pÄmindelser en uge fÞr arrangementet, angiv desuden, hvad der skal medbringes (laptops/enheder);
- fortĂŠl kolleger om arrangementet ved demoer, til frokost og over en kop kaffe;
- aftal med devops'ene, at der ikke mÄ opdateres eller implementeres noget den dag;
- forbered oplĂŠgsholdere;
- aftal med featureejerne og skriv flere testscenarier;
- bestil snacks (kager/slik) til mellemmÄltider;
- glem ikke at fortĂŠlle om resultaterne af arrangementet.
Resultater
PÄ en hel dag fik deltagerne testet 4 projekter og indsendt 192 bugs (heraf 134 unikke) og 7 opgaver med feature requests. SelvfÞlgelig vidste ejerne af nogle af disse bugs allerede om dem. Men der var ogsÄ nogle uventede opdagelser.
Alle deltagere fik sĂžde prĂŠmier.
Og vinderne â termokrus, pins, hoodies.
Det der viste sig at vĂŠre interessant:
- for deltagerne var det en overraskelse med det stramme sessionformat, hvor tiden er begrÊnset, og man ikke kan bruge meget tid pÄ overvejelser;
- det lykkedes at teste desktopversionen, mobilversionen og apps;
- vi sÄ mange projekter pÄ én gang, der var ikke tid til at kede sig;
- vi mÞdte forskellige kolleger og sÄ pÄ deres tilgang til at registrere bugs;
- vi oplevede hele smerten hos testere.
Hvad der kan forbedres:
- lav fĂŠrre projekter og Ăžg tiden for sessionen til 1,5 timer;
- forbered gaver/souvenirer meget i forvejen (nogle gange strÊkker godkendelse/betaling sig over en mÄned);
- slap af og accepter, at noget ikke gÄr efter planen, og der vil vÊre uforudsete hÊndelser.
Anmeldelser
Anna Bystrikova, systemadministrator: «Bugarena har vÊret meget lÊrerigt for mig. Jeg fik indsigt i testprocessen og kunne fÞle hele "smerten" hos testerne.
I starten af testprocessen, som en almindelig bruger, tjekker du de grundlÊggende punkter: virker knappen, gÄr det videre til siden, er layoutet ikke forskubbet. Men senere forstÄr man, at man skal tÊnke mere kreativt og forsÞge at "bryde" applikationen. Testerne har et svÊrt arbejde, det handler ikke kun om at "prÞve" hele brugerfladen, man skal strÊbe efter at tÊnke uden for boksen og vÊre ekstremt opmÊrksom.
Indtryk har kun vÊret positive, selv nu, efter noget tid efter arrangementet, kan jeg se, hvordan der arbejdes pÄ de fejl, jeg fandt. Det er fantastisk at fÞle sig involveret i forbedringen af produktet ^_^.»
Dmitry Seleznev, frontend-udvikler: «Testning i konkurrenceprÊget mode motiverer stÊrkt til at finde flere fejl). Jeg synes, alle skal prÞve at deltage i Bug Hunting. Exploratory testing gÞr det muligt at finde de cases, der ikke er beskrevet i testplanen. Desuden kan folk, der ikke kender projektet, give feedback pÄ servicen.
Antonina Tatyuk, seniorredaktÞr: «Jeg nÞd at prÞve mig selv som tester. Det er en helt anden arbejdsstil. Du forsÞger at bryde systemet i stedet for at venne dig til det. Vi har altid haft mulighed for at spÞrge kolleger om testning. Jeg lÊrte mere om prioritering af fejl (for eksempel er jeg vant til at spotte grammatiske fejl i tekster, men "vÊgten" af en sÄdan fejl er meget lille; og omvendt, noget der virkede mindre vigtigt, viste sig at vÊre en kritisk fejl, der straks blev rettet).
Under arrangementet gav drengene en opsummering af teorien om testning. Det var nyttigt for ikke-tekniske specialister. Og nogle dage senere indsÄ jeg, at jeg skrev til supporten pÄ en anden hjemmeside efter formularen "hvad-hvor-nÄr" og detaljeret beskrev mine forventninger til siden og virkeligheden.
Konklusion
Hvis du vil variere teamets liv, se pÄ funktionaliteten med friske Þjne, lave en mini «Spis dit eget hundefoder», sÄ kan du prÞve at gennemfÞre et sÄdant arrangement, og sÄ kan vi diskutere det sammen bagefter.
Ănsker alle det bedste og fĂŠrre fejl!
Kilde: habr.com
