Hei alle sammen! Mitt navn er Yulia og jeg er en tester. I fjor fortalte jeg deg om bagodelnya - et arrangement som ble holdt i selskapet vårt for å rydde opp i etterslepet. Dette er et helt levedyktig alternativ for å redusere det betydelig (fra 10 til 50 % i forskjellige team) på bare én dag.

I dag vil jeg fortelle deg om vårens Bagodelny-format - BUgHunting (BUH). Denne gangen fikset vi ikke gamle feil, men så etter nye og foreslo ideer til funksjoner. Under kuttet er det mange detaljer om organiseringen av slike arrangementer, våre resultater og tilbakemeldinger fra deltakerne.

Etter å ha tenkt gjennom og skrevet ned regelverket sendte vi ut en invitasjon til alle kanaler i corporate Slack, som ikke inneholdt noen restriksjoner:

Det førte til at rundt 30 personer meldte seg på – både utviklere og ikke-tekniske spesialister. Vi bevilget en hel arbeidsdag til arrangementet, bestilte et stort møterom og organiserte lunsjer i kontorkantina.

Hvorfor?

Det ser ut til at hvert lag tester funksjonaliteten. Brukere rapporterer feil til oss. Hvorfor i det hele tatt holde et slikt arrangement?

Vi hadde flere mål.

1. Introduser gutta nærmere relaterte prosjekter/produkter.
   Nå i vårt selskap jobber alle i separate team - enheter. Dette er prosjektteam som jobber med sin egen del av funksjonaliteten og ikke alltid er helt klar over hva som skjer i andre prosjekter.
2. Bare introduser kollegene dine for hverandre.
   Vi har nesten 800 ansatte på vårt Moskva-kontor; ikke alle kolleger kjenner hverandre fra synet.
3. Forbedre utviklernes evne til å finne feil i produktene deres.
   Vi promoterer nå Agile Testing og trener gutter i denne retningen.
4. Involver mer enn bare tekniske spesialister i testing.
   I tillegg til den tekniske avdelingen har vi mange kolleger fra andre spesialiteter som ønsket å snakke mer om testing, om hvordan man kan rapportere en feil på riktig måte slik at vi får færre meldinger som "Ahhh... ingenting fungerer."
5. Og, selvfølgelig, finne vanskelige og uopplagte feil.
   Jeg ønsket å hjelpe team med å teste nye funksjoner og gi dem muligheten til å se på den implementerte funksjonaliteten fra en annen vinkel.

implementering

Dagen vår besto av flere blokker:

• orientering;
• en kort forelesning om testing, der vi bare berørte hovedpunktene (mål og prinsipper for testing, etc.);
• seksjon om "regler for god oppførsel" når du introduserer feil (her prinsippene er godt beskrevet);
• fire testøkter for prosjekter med beskrevne scenarier på høyt nivå; før hver økt var det en kort innføringsforelesning om prosjektet og inndeling i team;
• kort undersøkelse om arrangementet;
• oppsummering.

(Vi glemte heller ikke pauser mellom økter og lunsj).

Grunnleggende regler

• Påmelding til arrangementer er individuell, som løser problemet med at hele laget tappes på grunn av treghet hvis en person bestemmer seg for ikke å gå.
• Deltakerne bytter lag hver økt. Dette gjør at deltakerne kan komme og gå når som helst, og du kan også møte flere mennesker.
• kommandoer to personer før hver økt dannes tilfeldig, dette gjør den mer dynamisk og raskere.
• For introduserte feil blir du tildelt poeng (fra 3 til 10) avhengig av kritikalitet.
• Det gis ingen poeng for duplikater.
• Feil må arkiveres av et teammedlem i henhold til alle interne standarder.
• Feature-ønsker opprettes i en egen oppgave og deltar i en egen nominasjon.
• Revisjonsteamet overvåker overholdelse av alle regler.

Andre detaljer

• I utgangspunktet ønsket jeg å gjøre en "avansert" testbegivenhet, men... Ganske mange karer fra ikke-produktteam meldte seg på (SMM, advokater, PR), vi måtte forenkle innholdet og fjerne komplekse/profilsaker.
• På grunn av arbeidet til enheter i Jira i forskjellige prosjekter, i henhold til flyten vår, laget vi spesielt et eget prosjekt der vi satte opp en mal for å introdusere feil.
• For å beregne poeng planla de å bruke en ledertavle som ble oppdatert via webhooks, men noe gikk galt og til slutt måtte utregningen gjøres manuelt.

Alle får problemer når de organiserer arrangementer, og for å gjøre det litt enklere for deg vil jeg beskrive våre problemer som du kan unngå.

En av høyttalerne ble plutselig syk og måtte finne en ny.
Jeg var veldig heldig at jeg fant en erstatter fra det samme laget klokken 9). Men det er bedre å ikke stole på flaks og ha en reserve. Eller vær klar til å gi den nødvendige rapporten selv.

Vi hadde ikke tid til å rulle ut funksjonaliteten, vi måtte bytte blokkene.
For å unngå å kaste bort en hel blokk, er det bedre å ha en backup-plan.

Noen testbrukere droppet, vi måtte raskt gjenopprette nye.
Krysssjekk testbrukere på forhånd eller være i stand til å gjøre dem raskt.

Nesten ingen av gutta som formatet var forenklet for kom.
Det er ikke nødvendig å dra noen med makt. Ydmyk deg selv.
Det er et alternativ å strengt foreskrive formatet for arrangementet: "amatør"/"avansert", eller forberede to alternativer på en gang og bestemme hvilken du skal holde i ettertid.

Nyttige organisatoriske punkter:

• bestille et møte på forhånd;
• ordne bord, ikke glem skjøteledninger og overspenningsvern (lading av bærbare datamaskiner/telefoner er kanskje ikke nok for hele dagen);
• automatisere scoringsprosessen;
• utarbeide rangeringstabeller;
• lage papirutdelinger med pålogginger og passord for testbrukere, instruksjoner for arbeid med Jira, skript;
• Ikke glem å sende ut påminnelser en uke før arrangementet, og også angi hva du må ta med deg (bærbare datamaskiner/enheter);
• fortell kollegene dine om arrangementet på en demo, ved lunsjer, over en kopp kaffe;
• enig med devops om ikke å oppdatere eller rulle ut noe på denne dagen;
• forberede høyttalere;
• forhandle med funksjonseiere og skrive flere scenarier for testing;
• bestille godbiter (kaker/godterier) til snacks;
• ikke glem å fortelle oss om resultatene av arrangementet.

Funn

I løpet av hele dagen klarte gutta å teste 4 prosjekter og lage 192 feil (134 av dem unike) og 7 problemer med funksjonsforespørsler. Selvfølgelig visste prosjekteierne allerede om noen av disse feilene. Men det var også uventede funn.

Alle deltakerne fikk søte premier.

Og vinnerne er termoser, merker, gensere.

Det som viste seg interessant:

• deltakerne syntes formatet på tøffe økter var uventet, når tiden er begrenset og du ikke kan bruke mye tid på å tenke;
• klarte å teste skrivebordet, mobilversjonen og applikasjonene;
• vi så på mange prosjekter samtidig, det var ikke tid til å kjede oss;
• møtt forskjellige kolleger, sett på deres tilnærminger til å introdusere feil;
• kjente all smerten til testerne.

Hva kan forbedres:

• gjøre færre prosjekter og øke økttiden til 1,5 timer;
• forberede gaver/suvenirer mye på forhånd (noen ganger tar godkjenning/betaling en måned);
• slapp av og aksepter at noe ikke vil gå etter planen og det vil oppstå force majeure.

anmeldelser

Anna Bystrikova, systemadministrator: «Almuehuset er veldig lærerikt for meg. Jeg lærte testprosessen og kjente all "smerten" til testerne.
Først, under testprosessen, som en eksemplarisk bruker, sjekker du hovedpunktene: om knappen klikker, om den går til siden, om layouten har flyttet ut. Men senere innser du at du må tenke mer utenfor boksen og prøve å "bryte" applikasjonen. Testere har en vanskelig jobb; det er ikke nok å "pirke" over hele grensesnittet; du må prøve å tenke utenfor boksen og være ekstremt oppmerksom.
Inntrykkene var bare positive, selv nå, en tid etter arrangementet, ser jeg hvordan det jobbes med feilene jeg fant. Det er flott å føle seg involvert i å forbedre produktet ^_^."

Dmitry Seleznev, front-end-utvikler: "Testing i konkurransemodus motiverer oss sterkt til å finne flere feil). Det virker for meg som om alle burde prøve å delta i Baghunting. Utforskende testing lar deg finne de tilfellene som ikke er beskrevet i testplanen. I tillegg kan folk som ikke kjenner prosjektet gi tilbakemelding om tjenestens bekvemmelighet.»

Antonina Tatchuk, seniorredaktør: «Jeg likte å prøve meg som tester. Dette er en helt annen arbeidsstil. Du prøver å bryte systemet, ikke bli venner med det. Vi hadde alltid muligheten til å spørre kollegene våre om noe om testing. Jeg lærte mer om prioritering av feil (jeg er for eksempel vant til å lete etter grammatiske feil i tekster, men "vekten" av en slik feil er veldig liten; og omvendt, noe som virket lite viktig for meg endte opp med å bli en kritisk feil, som umiddelbart ble fikset).
På arrangementet ga gutta en oppsummering av testteori. Dette var nyttig for ikke-tekniske personer. Og noen dager senere tok jeg meg selv i å tenke at jeg skrev til støtte for et annet nettsted ved å bruke "hva-hvor-når"-formelen og beskrev i detalj mine forventninger til nettstedet og virkeligheten."

Konklusjon

Hvis du ønsker å diversifisere livet til laget ditt, ta en ny titt på funksjonalitet, ordne en mini "Spis din egen hundemat", så kan du prøve å holde et slikt arrangement, og så kan vi diskutere det sammen.

Alt det beste og mindre feil!

Kilde: www.habr.com