Hallo iedereen! Mijn naam is Julia en ik ben tester. Vorig jaar vertelde ik jullie over Bugfest — een evenement dat we bij ons bedrijf organiseren om de backlog van bugs op te schonen. Dit is een heel haalbare manier om deze aanzienlijk te verminderen (in verschillende teams van 10 tot 50%) in slechts één dag.

Vandaag wil ik jullie vertellen over onze lente-editie van Bugfest — BUgHunting (BUH). Deze keer hebben we niet gewerkt aan oude bugs, maar zochten we nieuwe en deden we voorstellen voor functies. Onder de knop vind je veel details over de organisatie van zulke evenementen, onze resultaten en feedback van deelnemers.

Nadat we het reglement hadden doordacht en op papier gezet, hebben we een uitnodiging verstuurd via alle kanalen in onze bedrijfsslack, waarin geen beperkingen waren:

Uiteindelijk hebben zich ongeveer 30 mensen aangemeld — zowel ontwikkelaars als niet-technische specialisten. We hebben een hele werkdag voor het evenement gereserveerd, een grote vergaderruimte geboekt en de lunches geregeld via de kantoorrestaurant.

Waarom?

Het lijkt misschien zo dat elk team zijn eigen functionaliteit test. Gebruikers rapporteren bugs aan ons. Waarom zouden we zo'n evenement überhaupt organiseren?

We hadden meerdere doelen.

1. De jongens beter kennis laten maken met verwante projecten/producten.
   Momenteel werkt iedereen in ons bedrijf in afzonderlijke teams — units. Dit zijn projectgroepen die hun eigen functionaliteit ontwikkelen en niet altijd volledig op de hoogte zijn van wat er in andere projecten gebeurt.
2. Collega's gewoon met elkaar laten kennismaken.
   We hebben bijna 800 medewerkers in het kantoor in Moskou, niet alle collega's kennen elkaar persoonlijk.
3. De vaardigheden van het vinden van bugs bij ontwikkelaars in hun eigen producten verbeteren.
   We bevorderen momenteel Agile Testing en helpen de jongens om hierin te groeien.
4. Niet alleen technische specialisten bij het testen betrekken.
   Naast de technische afdeling hebben we veel collega's van andere specialiteiten die we graag meer willen vertellen over testen, en hoe ze bugs correct moeten rapporteren, zodat we minder berichten ontvangen in de trant van "Aaaah... niets werkt."
5. En natuurlijk, slimme en niet-evidente bugs vinden.
   We wilden de teams helpen met het testen van nieuwe functies en de mogelijkheid geven om naar de gerealiseerde functionaliteit vanuit een ander perspectief te kijken.

Implementatie

Onze dag bestond uit verschillende blokken:

• inleiding;
• korte lezing over testen, waarin we alleen de belangrijkste punten hebben besproken (doelen en principes van testen, enz.);
• sectie over de "regels van goed fatsoen" bij het aanmaken van bugs (here de principes zijn goed beschreven);
• vier testsessies voor projecten met hoog-niveau beschreven scenario's; voor elke sessie was er een korte inleidende lezing over het project en de teamindeling;
• korte enquête over het evenement;
• samenvatting.

(We hebben ook de pauzes tussen de sessies en de lunch niet vergeten).

Belangrijke regels

• Registratie voor evenementen is individueel, wat het probleem oplost van het weglopen van het hele team als één persoon besluit om niet te komen.
• Bij elke sessie wisselen de deelnemers van team. Dit stelt deelnemers in staat om op elk moment te komen en te gaan, en ze kunnen ook met veel meer mensen kennismaken.
• Teams van twee personen worden voor elke sessie op willekeurige wijze samengesteld, dit maakt het dynamischer en sneller.
• Voor aangemaakte bugs worden punten (van 3 tot 10) toegekend afhankelijk van de ernst.
• Voor dubbele punten worden geen punten toegekend.
• Bugs moeten door een teamlid worden aangemaakt volgens alle interne standaarden.
• Feature requests worden in een aparte taak aangemaakt en nemen deel aan een aparte nominatie.
• De auditteam houdt toezicht op de naleving van alle regels.

Andere details

• In eerste instantie wilden we een "geavanceerd" evenement over testen organiseren, maar omdat er voldoende mensen uit niet-productteams (SMM, juristen, PR) zich hadden aangemeld, moesten we de inhoud sterk vereenvoudigen en complexe/professionele casussen weglaten.
• Vanwege het werk van de eenheden in Jira in verschillende projecten met hun eigen flows, hebben we speciaal een apart project gemaakt waarin we een sjabloon voor het aanmaken van bugs hebben ingesteld.
• Voor het tellen van punten hadden we een leaderboard gepland dat via webhooks werd bijgewerkt, maar er ging iets mis en uiteindelijk moesten we de telling handmatig doen.

Iedereen die evenementen organiseert, loopt tegen problemen aan, en om het voor u iets makkelijker te maken, beschrijf ik onze problemen die u kunt vermijden.

Een van de sprekers werd plotseling ziek en we moesten een nieuwe zoeken..
Ik had het geluk dat ik om 9 uur 's ochtends een vervanger uit hetzelfde team vond). Maar vertrouw niet alleen op geluk en zorg voor een reserve. Of bereid u zelf voor om de benodigde presentatie te geven.

We hebben de functionaliteit niet op tijd uitgerold, we moesten de blokken omwisselen..
Om geen hele blokken weg te gooien, is het beter om een plan B te hebben.

Een deel van de testgebruikers is afgevallen, we moesten snel nieuwe aanmaken..
Controleer de testgebruikers van tevoren of zorg ervoor dat je ze snel kunt aanmaken.

Bijna niemand van de jongens voor wie we het formaat vereenvoudigden, is gekomen..
Je moet niemand tegen zijn wil meeslepen. Accepteer het.
Er is een optie om het formaat van het evenement streng vast te leggen: 'amateur'/'gevorderd', of om direct twee versies voor te bereiden en dan te beslissen welke uit te voeren.

Nuttige organisatorische punten:

• boekeer de vergaderzaal van tevoren;
• zet de tafels klaar, vergeet niet om verlengkabels en stekkerdozen mee te nemen (de batterijen van laptops/telefoons zijn mogelijk niet de hele dag voldoende);
• automatiseer het puntentellingproces;
• bereid ranglijsten voor;
• maak papieren hand-outs met inloggegevens en wachtwoorden van de testgebruikers, instructies voor het werken met Jira, scenario's;
• vergeet niet een week voor het evenement herinneringen te versturen en vermeld extra wat je mee moet nemen (laptops/apparaten);
• vertel je collega's over het evenement tijdens de demo, bij de lunch, bij een kopje koffie;
• maak afspraken met de DevOps dat er op die dag niets geüpdatet of uitgerold wordt;
• bereid sprekers voor;
• maak afspraken met de feature-eigenaren en schrijf meer scenario's voor het testen;
• bestel lekkernijen (koekjes/snoepjes) voor snacks;
• vergeet niet om het evenementresultaat te delen.

Resultaten

Op één dag hebben de jongens 4 projecten getest en 192 bugs aangemaakt (waarvan 134 uniek) en 7 taken met feature-verzoeken. Natuurlijk wisten de eigenaren van sommige van deze bugs al. Maar er waren ook onverwachte ontdekkingen.

Alle deelnemers kregen zoete prijzen.

En de winnaars - thermosflessen, badges, hoodies.

Wat interessant was:

• de format van strikte sessies, waarbij de tijd beperkt is en je niet veel tijd kunt besteden aan nadenken, was verrassend voor de deelnemers;
• het was mogelijk om de desktop, mobiele versie en apps te testen;
• we hebben meteen veel projecten bekeken, er was geen tijd om te vervelen;
• we hebben verschillende collega's ontmoet en hun benaderingen voor het aanmaken van bugs gezien;
• we hebben de pijn van testers goed aanvoelen.

Wat kan verbeterd worden:

• minder projecten doen en de sessietijd verhogen tot 1,5 uur;
• cadeaus/souvenirs al vroeg (soms duurt goedkeuring/betaling een maand);
• ontspannen en accepteren dat dingen niet volgens plan gaan en er overmacht zal zijn.

Feedback

Anna Bystrikova, systeembeheerder: «Bug-hunt was voor mij erg leerzaam. Ik leerde het testproces kennen en voelde de 'pijn' van testers.
In het begin van het testproces, als een gemiddelde gebruiker, controleer je de belangrijkste punten: werkt de knop, gaat het naar de pagina, is de lay-out niet verschoven. Maar later begrijp je dat je creatiever moet denken en probeert de applicatie 'te breken'. Testers hebben een moeilijke taak; het is niet voldoende om het hele interface door te klikken; je moet proberen outside the box te denken en uiterst oplettend te zijn.
Ik heb alleen maar positieve indrukken overgehouden; zelfs nu, enige tijd na het evenement, zie ik hoe er gewerkt wordt aan de door mij gevonden fouten. Het is geweldig om je betrokken te voelen bij het verbeteren van het product ^_^.»

Dmitry Seleznev, front-end ontwikkelaar: «Testen in competitieve modus motiveert sterk om meer bugs te vinden). Ik denk dat iedereen zou moeten proberen deel te nemen aan bug-hunting. Exploratief testen stelt je in staat om die gevallen te vinden die niet in het testplan zijn beschreven. Bovendien kunnen mensen die het project niet kennen, feedback geven over de gebruiksvriendelijkheid van de service.»

Antonina Tachuk, senior redacteur: «Ik vond het leuk om mezelf in de rol van tester uit te proberen. Het is een heel andere werkwijze. Je probeert het systeem te breken in plaats van ermee samen te werken. We hadden altijd de mogelijkheid om collega's iets over het testen te vragen. Ik leerde meer over het prioriteren van bugs (bijvoorbeeld, ik ben gewend om grammaticale fouten in teksten te zoeken, maar de 'waarde' van zo'n bug is heel laag; en omgekeerd, iets dat me onbelangrijk leek, bleek uiteindelijk een kritische bug te zijn die meteen werd gerepareerd).
Tijdens het evenement gaven de jongens een samenvatting van de testtheorie. Dit was nuttig voor niet-technische specialisten. En een paar dagen later merkte ik dat ik ondersteuning zocht voor een andere website volgens het 'wat-waar-wanneer' principe en gedetailleerd mijn verwachtingen van de website en de realiteit beschreef.

Conclusie

Als je het leven van het team wat wilt opfrissen, kijk dan met een frisse blik naar de functionaliteit, organiseer dan een mini «Eet je eigen hondenvoer», dan kun je zo'n evenement proberen te organiseren, en daarna kunnen we het samen bespreken.

Iedereen alle goeds en minder bugs!

Bron: habr.com