Hej alle! Mit navn er Yulia og jeg er tester. Sidste år fortalte jeg dig om bagodelnya - en begivenhed afholdt i vores virksomhed for at rydde ud i bug-backlog. Dette er en fuldstændig levedygtig mulighed for at reducere det markant (forskellige hold fra 10 til 50%) på bare én dag.

I dag vil jeg fortælle dig om vores forårs Bagodelny-format - BUgHunting (BUH). Denne gang rettede vi ikke gamle fejl, men ledte efter nye og foreslog ideer til funktioner. Under snittet er der mange detaljer om tilrettelæggelsen af ​​sådanne arrangementer, vores resultater og feedback fra deltagerne.

Efter at have gennemtænkt og nedskrevet reglerne sendte vi en invitation ud til alle kanaler i corporate Slack, som ikke indeholdt nogen begrænsninger:

Det resulterede i, at omkring 30 personer tilmeldte sig - både udviklere og ikke-tekniske specialister. Vi afsatte en hel arbejdsdag til arrangementet, bestilte et stort mødelokale og arrangerede frokoster i kontorets kantine.

Hvorfor?

Det ser ud til, at hvert hold tester dets funktionalitet. Brugere rapporterer fejl til os. Hvorfor overhovedet holde sådan et arrangement?

Vi havde flere mål.

1. Introducer fyrene tættere på relaterede projekter/produkter.
   Nu i vores virksomhed arbejder alle i separate teams - enheder. Det er projekthold, der arbejder på deres egen del af funktionaliteten og ikke altid er helt klar over, hvad der sker i andre projekter.
2. Bare introducer dine kolleger for hinanden.
   Vi har næsten 800 ansatte på vores kontor i Moskva; ikke alle kolleger kender hinanden af ​​syne.
3. Forbedre udviklernes evne til at finde fejl i deres produkter.
   Vi promoverer nu Agile Testing og træner fyre i denne retning.
4. Involver mere end blot tekniske specialister i test.
   Udover den tekniske afdeling har vi mange kolleger fra andre specialer, som gerne ville snakke mere om test, om hvordan man korrekt rapporterer en fejl, så vi modtager færre beskeder som "Ahhh... intet virker."
5. Og, selvfølgelig, find vanskelige og uoplagte fejl.
   Jeg ville hjælpe teams 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;
• et kort foredrag om test, hvor vi kun berørte hovedpunkterne (mål og principper for test osv.);
• afsnit om "regler for god opførsel" ved indførelse af fejl (her principperne er godt beskrevet);
• fire testsessioner for projekter med beskrevne scenarier på højt niveau; før hver session var der et kort introduktionsforedrag om projektet og opdeling i teams;
• kort undersøgelse om begivenheden;
• opsummerende.

(Vi glemte heller ikke pauser mellem sessioner og frokost).

Grundlæggende regler

• Tilmelding til arrangementer er individuel, som løser problemet med, at hele holdet dræner på grund af inerti, hvis én person beslutter sig for ikke at gå.
• Deltagerne skifter hold hver session. Dette giver deltagerne mulighed for at komme og gå til enhver tid, og du kan også møde flere mennesker.
• Команды to personer før hver session dannes tilfældigt, dette gør det mere dynamisk og hurtigere.
• For introducerede fejl bliver du tildelt point (fra 3 til 10) afhængig af kritikalitet.
• Der gives ingen point for dubletter.
• Fejl skal indgives af et teammedlem i henhold til alle interne standarder.
• Feature requests oprettes i en separat opgave og deltager i en separat nominering.
• Revisionsteamet overvåger overholdelse af alle regler.

Andre detaljer

• I starten ville jeg lave en "avanceret" testbegivenhed, men... Rigtig mange fyre fra ikke-produkthold tilmeldte sig (SMM, advokater, PR), vi var nødt til i høj grad at forenkle indholdet og fjerne komplekse/profilsager.
• På grund af arbejdet fra enheder i Jira i forskellige projekter, i henhold til vores flow, har vi specielt lavet et separat projekt, hvor vi opsætter en skabelon til at introducere fejl.
• Til at beregne point planlagde de at bruge et leaderboard, der blev opdateret via webhooks, men noget gik galt, og i sidste ende skulle udregningen foretages manuelt.

Alle kommer i problemer, når de arrangerer arrangementer, og for at gøre det lidt nemmere for dig, vil jeg beskrive vores problemer, som du kan undgå.

En af talerne blev pludselig syg og måtte finde en ny.
Jeg var vildt heldig, at jeg fandt en afløser fra samme hold kl. 9). Men det er bedre ikke at stole på held og have en ekstra. Eller vær klar til selv at give den nødvendige rapport.

Vi havde ikke tid til at rulle funktionaliteten ud, vi var nødt til at bytte blokkene.
For at undgå at smide en hel blok væk, er det bedre at have en backup-plan.

Nogle testbrugere faldt, vi var nødt til hurtigt at genskabe nye.
Krydstjek testbrugere på forhånd eller være i stand til at gøre dem hurtigt.

Næsten ingen af ​​de fyre, for hvem formatet var forenklet, kom.
Der er ingen grund til at trække nogen med magt. Ydmyg dig selv.
Der er en mulighed for strengt at foreskrive arrangementets format: "amatør"/"avanceret", eller forberede to muligheder på én gang og beslutte, hvilken der skal afholdes efter kendsgerningen.

Nyttige organisatoriske punkter:

• book et møde på forhånd;
• arrangere borde, glem ikke forlængerledninger og overspændingsbeskyttere (opladning af bærbare computere/telefoner er muligvis ikke nok til hele dagen);
• automatisere scoringsprocessen;
• forberede rangeringstabeller;
• lave papiruddelinger med logins og adgangskoder for testbrugere, instruktioner til at arbejde med Jira, scripts;
• Glem ikke at udsende påmindelser en uge før arrangementet, og også angive, hvad du skal have med dig (bærbare computere/enheder);
• fortæl dine kolleger om arrangementet ved en demo, ved frokoster, over en kop kaffe;
• enig med devops om ikke at opdatere eller udrulle noget på denne dag;
• forberede højttalere;
• forhandle med funktionsejere og skrive flere scenarier til test;
• bestille godbidder (småkager/slik) til snacks;
• glem ikke at fortælle os om resultaterne af arrangementet.

Fund

I løbet af hele dagen lykkedes det fyrene at teste 4 projekter og skabe 192 fejl (134 af dem unikke) og 7 problemer med funktionsanmodninger. Selvfølgelig vidste projektejerne allerede om nogle af disse fejl. Men der var også uventede fund.

Alle deltagere fik søde præmier.

Og vinderne er termokander, badges, sweatshirts.

Hvad viste sig interessant:

• deltagerne fandt formatet af hårde sessioner uventet, når tiden er begrænset, og man ikke kan bruge meget tid på at tænke;
• lykkedes at teste desktop, mobilversion og applikationer;
• Vi så på mange projekter på én gang, der var ikke tid til at kede os;
• mødte forskellige kolleger, så på deres tilgange til at introducere fejl;
• følte al smerten fra testerne.

Hvad kan forbedres:

• lav færre projekter og øge sessionstiden til 1,5 time;
• forberede gaver/souvenirs meget i forvejen (nogle gange tager godkendelse/betaling en måned);
• slappe af og acceptere, at noget ikke vil gå efter planen, og der vil være force majeure.

anmeldelser

Anna Bystrikova, systemadministrator: ”Almuehuset er meget lærerigt for mig. Jeg lærte testprocessen og følte al testernes "smerte".
I første omgang, under testprocessen, tjekker du som eksemplarisk bruger hovedpunkterne: om knappen klikker, om den går til siden, om layoutet er flyttet ud. Men senere indser du, at du skal tænke mere ud af boksen og prøve at "bryde" ansøgningen. Testere har et vanskeligt job; det er ikke nok at "prikke" over hele grænsefladen; du skal prøve at tænke ud af boksen og være ekstremt opmærksom.
Indtrykkene var kun positive, selv nu, et stykke tid efter begivenheden, ser jeg, hvordan der arbejdes på de fejl, jeg fandt. Det er dejligt at føle sig involveret i at forbedre produktet ^_^."

Dmitry Seleznev, frontend-udvikler: "Test i konkurrencetilstand motiverer os i høj grad til at finde flere fejl). Det forekommer mig, at alle burde prøve at deltage i Baghunting. Udforskende test giver dig mulighed for at finde de tilfælde, der ikke er beskrevet i testplanen. Plus, folk, der ikke kender projektet, kan give feedback om bekvemmeligheden ved tjenesten."

Antonina Tatchuk, seniorredaktør: “Jeg kunne godt lide at prøve mig selv som tester. Dette er en helt anden arbejdsstil. Du prøver at bryde systemet, ikke blive venner med det. Vi havde altid mulighed for at spørge vores kollegaer om noget om test. Jeg lærte mere om prioritering af fejl (jeg er f.eks. vant til at lede efter grammatiske fejl i tekster, men "vægten" af en sådan fejl er meget lille; og omvendt, noget, der forekom ikke særlig vigtigt for mig, endte med at blive en kritisk fejl, som straks blev rettet).
Ved arrangementet gav fyrene et resumé af testteori. Dette var nyttigt for ikke-tekniske mennesker. Og et par dage senere tog jeg mig selv i at tro, at jeg skrev til støtte for et andet websted ved at bruge "hvad-hvor-når"-formlen og beskrev i detaljer mine forventninger til webstedet og virkeligheden."

Konklusion

Hvis du ønsker at diversificere dit holds liv, så tag et nyt kig på funktionaliteten, arrangere en mini "Spis din egen hundemad", så kan du prøve at holde sådan et arrangement, og så kan vi diskutere det sammen.

Alt det bedste og færre fejl!

Kilde: www.habr.com