Hallo alle sammen! Jeg heter Julia, og jeg er en tester. I fjor fortalte jeg dere om Bagodilnyu — et arrangement holdt i bedriften vår for å rydde opp i feiletterslepet. Det er et levedyktig alternativ for å redusere det betydelig (i forskjellige team fra 10 til 50 %) på bare én dag.

I dag vil jeg fortelle dere om vårens Bugdelnya-format – BUgHunting (BUH). Denne gangen fikset vi ikke gamle feil, men lette etter nye og foreslo ideer til funksjoner. Under finner du mange detaljer om organiseringen av slike arrangementer, resultatene våre og tilbakemeldinger fra deltakerne.

Etter å ha tenkt gjennom og skrevet ned reglene, sendte vi ut en invitasjon til alle kanaler i bedriftens Slack, som ikke hadde noen begrensninger:

Til slutt meldte rundt 30 personer seg på – både utviklere og ikke-tekniske spesialister. Arrangementet tok en hel arbeidsdag, et stort konferanserom ble booket, og lunsjer ble organisert i kontorets kantine.

Hvorfor?

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

Vi hadde flere mål.

1. Introduser barna nærmere for relaterte prosjekter/produkter.
   Nå jobber alle i vårt selskap i separate team – enheter. Dette er prosjektgrupper som sager sin del av funksjonaliteten og ikke alltid er fullt klar over hva som skjer i andre prosjekter.
2. Bare introduser kollegene for hverandre.
   Vi har nesten 800 ansatte på Moskva-kontoret, men ikke alle kollegene kjenner hverandre av syne.
3. Forbedre utviklernes ferdigheter i å finne feil i produktene deres.
   Vi promoterer for tiden smidig testing og trener opp folkene våre 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 gjerne vil fortelle oss mer om testing, om hvordan man rapporterer feil på riktig måte, slik at vi mottar færre meldinger i formatet «Aaaa ... ingenting fungerer».
5. Og selvfølgelig finne vanskelige og ikke-åpenbare feil.
   Jeg ville 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;
• et kort foredrag om testing, der vi kun berørte hovedpunktene (mål og prinsipper for testing, osv.);
• avsnitt om «regler for god skikk» når du lager feil (her prinsippene er godt beskrevet);
• fire testøkter på prosjekter med overordnede scenarier; før hver økt var det en kort introduksjonsforelesning om prosjektet og fordeling i team;
• en kort undersøkelse om arrangementet;
• oppsummering.

(Vi glemte heller ikke pausene mellom øktene og lunsjen).

Grunnleggende regler

• Påmelding til arrangementer er individuell, som løser problemet med at hele teamet tappes på grunn av treghet hvis én person bestemmer seg for ikke å dra.
• Hver økt bytter deltakerne lag.Dette gjør at deltakerne kan komme og gå når som helst, og det lar deg også møte mange mennesker.
• kommandoer to personer før hver økt genereres tilfeldig, på denne måten blir det mer dynamisk og raskere.
• For feilene som introduseres, vil du bli belønnet poeng (fra 3 til 10) avhengig av kritiskhet.
• Det gis ingen poeng for double.
• Feil må rapporteres av et teammedlem i henhold til alle interne standarder.
• Funksjonsforespørsler opprettes i en egen oppgave og deltar i en egen nominasjon.
• Revisjonsteamet overvåker at alle regler overholdes.

Andre detaljer

• I utgangspunktet ønsket vi å lage et «avansert» testarrangement, men siden ganske mange fra ikke-produktteam (SMM, advokater, PR) meldte seg på, måtte vi forenkle innholdet betraktelig og fjerne komplekse/spesialiserte saker.
• På grunn av arbeidet til enheter i Jira i forskjellige prosjekter i henhold til deres flyter, opprettet vi spesifikt et eget prosjekt der vi satte opp en mal for å lage feil.
• For å beregne poengene planla vi å bruke en poengtavle som ble oppdatert via webhooks, men noe gikk galt, og til slutt måtte beregningen gjøres manuelt.

Alle støter på trøbbel når de organiserer arrangementer, og for å gjøre det litt enklere for deg, vil jeg beskrive problemene våre som du kan unngå.

En av foredragsholderne ble plutselig syk, og vi måtte finne en ny..
Jeg var utrolig heldig som fant en erstatter fra samme team klokken 9. Men det er bedre å ikke stole på flaks og ha en reserve. Eller være klar til å gi den nødvendige rapporten selv.

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

Noen av testbrukerne falt fra, så vi måtte raskt gjenskape nye.
Dobbeltsjekk testbrukere på forhånd, eller ha muligheten til å gjøre det raskt.

Nesten ingen av gutta som formatet var forenklet for, kom.
Det er ikke nødvendig å dra noen med makt. Si opp.
Det er et alternativ å strengt foreskrive formatet for arrangementet: «amatør»/«avansert», eller å forberede to alternativer samtidig og deretter bestemme hvilket som skal holdes.

Nyttige organisatoriske punkter:

• bestill et møterom på forhånd;
• dekk bord, ikke glem skjøteledninger og strømuttak (lading av bærbare datamaskiner/telefoner er kanskje ikke nok for hele dagen);
• automatisere poenggivningsprosessen;
• utarbeide vurderingstabeller;
• lage papirark med brukernavn og passord for testbrukere, instruksjoner om hvordan man jobber med Jira og scenarioer;
• ikke glem å sende ut påminnelser en uke før arrangementet, og angi også hva du må ta med deg (bærbare datamaskiner/enheter);
• fortell kollegene dine om arrangementet på demonstrasjoner, lunsjer eller over en kopp kaffe;
• enig med DevOps om ikke å oppdatere eller rulle ut noe på denne dagen;
• forberede foredragsholdere;
• bli enig med funksjonseierne og skriv flere scenarioer for testing;
• bestill noen godbiter (kjeks/godteri) som snacks;
• Ikke glem å fortelle oss om resultatene av arrangementet.

Funn

I løpet av hele dagen klarte gutta å teste fire prosjekter og lage 4 feil (hvorav 192 var unike) og sju oppgaver med funksjonsforespørsler. Prosjekteierne visste selvfølgelig allerede om noen av disse feilene. Men det var også uventede funn.

Alle deltakerne fikk søte premier.

Og vinnerne vil motta termoser, merker og gensere.

Det som viste seg interessant:

• Deltakerne syntes formatet på de tøffe øktene var uventet, der tiden er begrenset og de ikke kan bruke mye tid på å tenke;
• klarte å teste desktop-, mobilversjonen og applikasjonene;
• vi så på mange prosjekter samtidig, det var ingen tid til å kjede seg;
• møtte forskjellige kolleger, så på deres tilnærminger til å introdusere feil;
• følte all smerten til testerne.

Hva kan forbedres:

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

anmeldelser

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

Dmitry Seleznev, frontend-utvikler: «Testing i konkurransemodus motiverer sterkt til å finne flere feil.» Jeg synes alle burde prøve å delta i Bughunting. Utforskende testing lar deg finne tilfeller som ikke er beskrevet i testplanen. I tillegg kan folk som ikke er kjent med prosjektet gi tilbakemelding om hvor praktisk tjenesten er.

Antonina Tatchuk, seniorredaktør«Jeg likte å prøve meg som tester. Det er en helt annen arbeidsstil. Man prøver å knekke systemet, ikke bli venn med det. Vi hadde alltid muligheten til å spørre kolleger om noe om testing. Jeg lærte mer om feilprioritering (for eksempel er jeg vant til å se etter grammatiske feil i tekster, men «vekten» av en slik feil er veldig liten; og omvendt, noe som virket lite viktig for meg viste seg å være en kritisk feil som ble fikset umiddelbart).»
På arrangementet ga gutta et sammendrag av testteori. Det var nyttig for ikke-tekniske spesialister. Og noen dager senere tok jeg meg selv i å tro 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 vil legge til litt variasjon i teamets hverdag, ta et nytt kikk på funksjonaliteten eller organisere et miniteam, "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