Dag Allemaal! Mijn naam is Yulia en ik ben een tester. Vorig jaar vertelde ik je erover bagodelnya - een evenement in ons bedrijf om de achterstand in bugs weg te werken. Dit is een volledig haalbare optie om dit in slechts één dag aanzienlijk te verminderen (van 10 naar 50% in verschillende teams).

Vandaag wil ik je vertellen over ons lente-Bagodelny-format - BUgHunting (BUH). Deze keer hebben we geen oude bugs opgelost, maar naar nieuwe gezocht en ideeën voor functies voorgesteld. Onder de afbeelding vindt u veel details over de organisatie van dergelijke evenementen, onze resultaten en feedback van deelnemers.

Nadat we de regelgeving hadden doordacht en opgeschreven, stuurden we een uitnodiging naar alle kanalen in Corporate Slack, die geen beperkingen bevatte:

Als gevolg hiervan hebben ongeveer 30 mensen zich aangemeld - zowel ontwikkelaars als niet-technische specialisten. We hebben een hele werkdag uitgetrokken voor het evenement, een grote vergaderruimte geboekt en lunches georganiseerd in de kantoorkantine.

Waarom?

Het lijkt erop dat elk team zijn functionaliteit test. Gebruikers melden bugs aan ons. Waarom überhaupt zo’n evenement organiseren?

We hadden meerdere doelen.

1. Introduceer de jongens dichter bij gerelateerde projecten/producten.
   Nu werkt iedereen in ons bedrijf in afzonderlijke teams - eenheden. Dit zijn projectteams die aan hun eigen deel van de functionaliteit werken en niet altijd volledig op de hoogte zijn van wat er in andere projecten gebeurt.
2. Stel uw collega's gewoon aan elkaar voor.
   We hebben bijna 800 medewerkers in ons kantoor in Moskou; niet alle collega's kennen elkaar van gezicht.
3. Verbeter het vermogen van ontwikkelaars om bugs in hun producten te vinden.
   We promoten nu Agile Testen en trainen jongens in deze richting.
4. Betrek meer dan alleen technische specialisten bij het testen.
   Naast de technische afdeling hebben we veel collega’s van andere specialismen die graag meer willen praten over testen, over hoe je een bug goed kunt melden zodat we minder berichten krijgen als “Ahhh... niets werkt.”
5. En natuurlijk vind je lastige en niet voor de hand liggende bugs.
   Ik wilde teams helpen met het testen van nieuwe features en hen de kans geven om vanuit een andere invalshoek naar de geïmplementeerde functionaliteit te kijken.

uitvoering

Onze dag bestond uit verschillende blokken:

• briefing;
• een korte lezing over testen, waarin we alleen de hoofdpunten bespraken (doelen en principes van testen, etc.);
• sectie over “regels voor goede manieren” bij het introduceren van bugs (hier de principes zijn goed beschreven);
• vier testsessies voor projecten met op hoog niveau beschreven scenario's; vóór elke sessie was er een korte introductielezing over het project en de indeling in teams;
• korte enquête over het evenement;
• samenvatten.

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

Fundamentele regels

• Registratie voor evenementen is individueel, waarmee het probleem wordt opgelost dat het hele team leegloopt vanwege traagheid als één persoon besluit niet te gaan.
• Deelnemers wisselen elke sessie van team. Hierdoor kunnen deelnemers op elk moment komen en gaan en kun je ook meer mensen ontmoeten.
• Команды twee personen vóór elke sessie worden willekeurig gevormd, dit maakt het dynamischer en sneller.
• Voor geïntroduceerde bugs wordt u beloond punten (van 3 tot 10), afhankelijk van de mate van kritiek.
• Er worden geen punten toegekend voor duplicaten.
• Bugs moeten door een teamlid worden ingediend volgens alle interne normen.
• Functieverzoeken worden in een aparte taak aangemaakt en nemen deel aan een aparte nominatie.
• Het auditteam houdt toezicht op de naleving van alle regels.

Andere details

• Aanvankelijk wilde ik een “geavanceerd” testevenement doen, maar... Er hebben zich heel wat jongens van niet-productteams aangemeld (SMM, advocaten, PR), we moesten de inhoud sterk vereenvoudigen en complexe/profielzaken verwijderen.
• Vanwege het werk van eenheden in Jira in verschillende projecten hebben we, volgens onze stroom, speciaal een apart project gemaakt waarin we een sjabloon hebben opgezet voor het introduceren van bugs.
• Om punten te berekenen waren ze van plan een leaderboard te gebruiken dat via webhooks werd bijgewerkt, maar er ging iets mis en uiteindelijk moest de berekening handmatig worden gedaan.

Iedereen komt problemen tegen bij het organiseren van evenementen, en om het je wat makkelijker te maken, zal ik onze problemen beschrijven die je kunt vermijden.

Eén van de sprekers werd plotseling ziek en moest op zoek naar een nieuwe.
Ik had enorm geluk dat ik om 9 uur een vervanger van hetzelfde team vond). Maar het is beter om niet op geluk te vertrouwen en een reserve te hebben. Of wees bereid om zelf het nodige rapport uit te brengen.

We hadden geen tijd om de functionaliteit uit te rollen, we moesten de blokken verwisselen.
Om te voorkomen dat je een heel blok weggooit, is het beter om een ​​back-upplan te hebben.

Sommige testgebruikers stopten, we moesten snel nieuwe aanmaken.
Voer vooraf een kruiscontrole uit van testgebruikers of zorg ervoor dat u deze snel kunt uitvoeren.

Bijna geen van de jongens voor wie het format vereenvoudigd was, kwam.
Het is niet nodig om iemand met geweld mee te slepen. Verneder jezelf.
Er is een optie om het format van het evenement strikt voor te schrijven: “amateur”/“geavanceerd”, of om twee opties tegelijk voor te bereiden en achteraf te beslissen welke je wilt houden.

Nuttige organisatorische punten:

• boek vooraf een bijeenkomst;
• tafels regelen, verlengsnoeren en overspanningsbeveiligingen niet vergeten (laptops/telefoons opladen is misschien niet genoeg voor de hele dag);
• automatiseer het scoreproces;
• rangschikkingstabellen voorbereiden;
• papieren hand-outs maken met logins en wachtwoorden van testgebruikers, instructies voor het werken met Jira, scripts;
• Vergeet niet een week voor het evenement herinneringen te versturen en geef ook aan wat je mee moet nemen (laptops/devices);
• vertel uw collega's over het evenement tijdens een demo, tijdens een lunch, bij een kop koffie;
• spreek af met de devops om op deze dag niets te updaten of uit te rollen;
• sprekers voorbereiden;
• onderhandelen met feature-eigenaren en meer scenario's schrijven om te testen;
• lekkernijen (koekjes/snoepjes) voor snacks bestellen;
• vergeet niet ons te vertellen over de resultaten van het evenement.

Bevindingen

In de loop van de hele dag slaagden de jongens erin om 4 projecten te testen en 192 bugs te creëren (waarvan 134 uniek) en 7 problemen met functieverzoeken. Natuurlijk waren de projecteigenaren al op de hoogte van enkele van deze bugs. Maar er waren ook onverwachte vondsten.

Alle deelnemers ontvingen leuke prijzen.

En de winnaars zijn thermosflessen, badges, sweatshirts.

Wat interessant bleek:

• de deelnemers vonden het format van zware sessies onverwacht, wanneer de tijd beperkt is en je niet veel tijd aan nadenken kunt besteden;
• erin geslaagd om de desktop-, mobiele versie en applicaties te testen;
• we keken naar veel projecten tegelijk, er was geen tijd om ons te vervelen;
• ontmoette verschillende collega's, bekeek hun aanpak bij het introduceren van bugs;
• voelde alle pijn van de testers.

Wat kan er verbeterd worden:

• doe minder projecten en verleng de sessietijd tot 1,5 uur;
• geschenken/souvenirs ruim van tevoren voorbereiden (soms duurt goedkeuring/betaling een maand);
• ontspan en accepteer dat iets niet volgens plan zal verlopen en dat er sprake zal zijn van overmacht.

beoordelingen

Anna Bystrikova, systeembeheerder: “Het armenhuis is voor mij heel leerzaam. Ik leerde het testproces kennen en voelde alle ‘pijn’ van de testers.
Tijdens het testproces controleer je als voorbeeldgebruiker eerst de belangrijkste punten: of de knop klikt, of deze naar de pagina gaat, of de lay-out is verplaatst. Maar later besef je dat je meer buiten de gebaande paden moet denken en moet proberen de applicatie te ‘breken’. Testers hebben een moeilijke taak; het is niet genoeg om de hele interface te ‘porren’; je moet proberen buiten de gebaande paden te denken en uiterst oplettend te zijn.
De indrukken waren alleen maar positief, zelfs nu, enige tijd na het evenement, zie ik hoe er gewerkt wordt aan de gevonden bugs. Het is geweldig om je betrokken te voelen bij het verbeteren van het product ^_^.”

Dmitry Seleznev, front-endontwikkelaar: “Testen in competitieve modus motiveert ons enorm om meer bugs te vinden). Het lijkt mij dat iedereen zou moeten proberen deel te nemen aan Baghunting. Met verkennend testen kunt u die gevallen vinden die niet in het testplan zijn beschreven. Bovendien kunnen mensen die het project niet kennen feedback geven over het gemak van de dienst.”

Antonina Tatchuk, hoofdredacteur: “Ik vond het leuk om mezelf als tester uit te proberen. Dit is een heel andere stijl van werken. Je probeert het systeem te doorbreken, er geen vriendschap mee te sluiten. Wij hadden altijd de mogelijkheid om onze collega’s iets te vragen over testen. Ik heb meer geleerd over het prioriteren van bugs (ik ben bijvoorbeeld gewend om naar grammaticale fouten in teksten te zoeken, maar het “gewicht” van zo’n bug is erg klein; en omgekeerd, iets dat voor mij niet erg belangrijk leek, werd uiteindelijk een kritieke bug, die onmiddellijk werd verholpen).
Tijdens het evenement gaven de jongens een samenvatting van de testtheorie. Dit was handig voor niet-technische mensen. En een paar dagen later betrapte ik mezelf erop dat ik dacht dat ik aan het schrijven was ter ondersteuning van een andere site, waarbij ik de ‘wat-waar-wanneer’-formule gebruikte en in detail mijn verwachtingen van de site en de realiteit beschreef.”

Conclusie

Als je het leven van je team wilt diversifiëren, kijk dan eens met een frisse blik naar de functionaliteit, regel een mini "Eet je eigen hondenvoer", dan kun je proberen zo’n evenement te organiseren, en dan kunnen we het samen bespreken.

Het allerbeste en minder bugs!

Bron: www.habr.com