Hi almal! My naam is Julia en ek is 'n toetser. Verlede jaar het ek jou vertel van sakhuis — 'n geleentheid wat in ons maatskappy gehou is om die foutagterstand skoon te maak. Dit is 'n lewensvatbare opsie om dit aansienlik te verminder (in verskillende spanne van 10 tot 50%) in net een dag.

Vandag wil ek jou vertel van ons lente-sakhuisformaat - BUgHunting (BUH). Hierdie keer het ons nie ou foute reggemaak nie, maar nuwes gesoek en idees vir kenmerke aangebied. Onder die snit is daar baie besonderhede oor die organisasie van sulke geleenthede, ons resultate en terugvoer van die deelnemers.

Nadat ons die regulasies besin en voorgeskryf het, het ons 'n uitnodiging aan alle kanale in die korporatiewe Slack gestuur, waarin daar geen beperkings was nie:

Gevolglik het sowat 30 mense ingeskryf – beide ontwikkelaars en nie-tegniese spesialiste. ’n Hele werksdag is vir die geleentheid toegeken, ’n groot vergaderlokaal is bespreek en middagetes is op die basis van die kantoorkantien gereël.

Зачем?

Dit wil voorkom asof elke span sy funksionaliteit toets. Gebruikers rapporteer foute aan ons. Hoekom selfs so 'n geleentheid hou?

Ons het verskeie doelwitte gehad.

1. Stel kinders nader aan verwante projekte/produkte bekend.
   Nou in ons maatskappy werk almal in aparte spanne - eenhede. Dit is projekspanne wat aan hul eie deel van die funksionaliteit werk en nie altyd ten volle bewus is van wat in ander projekte gebeur nie.
2. Net om kollegas aan mekaar voor te stel.
   Ons het byna 800 werknemers in die Moskou-kantoor, nie alle kollegas ken mekaar van sig nie.
3. Verbeter die vaardigheid om foute onder ontwikkelaars in hul produkte te vind.
   Ons bevorder nou Agile Testing en pomp ouens in hierdie rigting.
4. Betrek nie net tegniese spesialiste by toetsing nie.
   Benewens die tegniese afdeling het ons baie kollegas van ander spesialiteite wat meer wou praat oor toetsing, oor hoe om foute behoorlik reg te maak sodat ons minder “Ahhh ... niks werk”-boodskappe kry.
5. En natuurlik om moeilike en nie-ooglopende foute te vind.
   Ek wou spanne help om nuwe kenmerke te toets en hulle die geleentheid te gee om vanuit 'n ander hoek na die geïmplementeerde funksionaliteit te kyk.

Implementering

Ons dag het uit verskeie blokke bestaan:

• inligtingsessie;
• 'n kort lesing oor toetsing, waarin ons slegs die hoofpunte (doelwitte en beginsels van toetsing, ens.) aangeroer het;
• afdeling oor die "etiketreëls" wanneer foute bekendgestel word (hier beginsels is goed beskryf.
• vier toetssessies oor projekte met hoëvlak beskryfde scenario's; voor elke sessie was daar 'n kort inleidende lesing oor die projek en verspreiding aan spanne;
• kort opname oor die geleentheid;
• opsomming.

(Ons het ook nie van pouses tussen sessies en middagete vergeet nie).

Basiese reëls

• Registrasie vir individuele geleenthede, wat die probleem oplos om die hele span deur traagheid te dreineer as een persoon besluit om nie te gaan nie.
• Deelnemers wissel elke sessie van span. Dit laat deelnemers toe om enige tyd te vertrek en te kom, en jy kan ook 'n groot aantal mense leer ken.
• Команды twee mense voor elke sessie lukraak gevorm, so dit blyk meer dinamies en vinniger.
• Vir wond word goggas gehef punte (van 3 tot 10) afhangende van kritiek.
• Dubbelspel word nie punte toegeken nie.
• Foute moet deur 'n spanlid geliasseer word volgens alle interne standaarde.
• Kenmerkversoeke word in 'n aparte taak geskep en neem deel aan 'n aparte nominasie.
• Die ouditspan monitor die nakoming van alle reëls.

Ander besonderhede

• Aanvanklik wou ek 'n "gevorderde" toetsgeleentheid maak, maar sedertdien nogal baie ouens van nie-produkspanne het ingeskryf (SMM, prokureurs, PR), ons moes die inhoud baie vereenvoudig en komplekse/profielsake verwyder.
• As gevolg van die werk van eenhede in Jira in verskillende projekte volgens ons vloei, het ons spesiaal 'n aparte projek gemaak waarin ons 'n sjabloon vir die bekendstelling van foute opgestel het.
• Om die punte te bereken, het ons beplan om 'n ranglys te gebruik wat via webhooks opgedateer is, maar iets het verkeerd geloop en gevolglik moes die berekening met die hand gedoen word.

Almal loop in 'n hark wanneer hulle geleenthede organiseer, en om dit 'n bietjie makliker te maak vir jou, sal ek ons ​​probleme beskryf wat jy kan vermy.

Een van die sprekers het skielik siek geword en moes ’n nuwe een soek.
Ek was baie gelukkig dat ek om 9:XNUMX 'n plaasvervanger van dieselfde span gekry het). Maar dit is beter om nie op geluk staat te maak en 'n spaargeld te hê nie. Of wees bereid om die verslag te gee wat jy nodig het.

Ons het nie tyd gehad om die funksionaliteit uit te voer nie, ons moes die blokke plek-plek verander.
Om nie die hele blok uit te gooi nie, is dit beter om 'n rugsteunplan te hê.

Deel van die toetsgebruikers het gedaal, ek moes vinnig nuwes herskep.
Kontroleer toetsgebruikers vooraf of het die vermoë om dit vinnig te maak.

Byna nie een van die ouens vir wie die formaat vereenvoudig is, het gekom nie.
Dit is nie nodig om iemand te dwing nie. Verneder jouself.
Daar is 'n opsie om die formaat van die geleentheid streng voor te skryf: "amateur" / "gevorderd", of twee opsies gelyktydig voor te berei en in werklikheid te besluit watter een om te hou.

Nuttige organisatoriese punte:

• bespreek vooraf 'n vergadering;
• reël tafels, moenie van verlengkoorde en stroombeskermers vergeet nie (die laai van skootrekenaars / fone vir die hele dag is dalk nie genoeg nie);
• outomatiseer die punteleerproses;
• graderingstabelle voorberei;
• maak papieruitdeelstukke met aanmeldings en wagwoorde van toetsgebruikers, instruksies om met Jira te werk, skrifte;
• moenie vergeet om 'n week voor die geleentheid aanmanings uit te stuur nie, dui ook aan wat jy moet saamneem (skootrekenaars/toestelle);
• vertel kollegas van die geleentheid by 'n demonstrasie, by middagetes, oor 'n koppie koffie;
• stem saam met die devops om niks op daardie dag op te dateer of uit te voer nie;
• berei sprekers voor;
• onderhandel met kenmerkeienaars en skryf meer scenario's vir toetsing;
• bestel versnaperinge (koekies / lekkers) vir versnaperinge;
• moenie vergeet om ons te vertel van die resultate van die geleentheid nie.

Bevindinge

Gedurende die hele dag het die ouens daarin geslaag om 4 projekte te toets en 192 foute te skep (waarvan 134 uniek is) en 7 take met kenmerkversoeke. Natuurlik het projekeienaars reeds van sommige van hierdie foute geweet. Maar daar was ook onverwagte bevindings.

Alle deelnemers het lieflike pryse ontvang.

En die wenners is termosse, kentekens, sweatshirts.

Wat interessant uitgedraai het:

• die formaat van moeilike sessies was onverwags vir die deelnemers, wanneer tyd beperk is en jy nie baie tyd kan spandeer om te dink nie;
• daarin geslaag om die lessenaar, mobiele weergawe en toepassings te toets;
• ons het na baie projekte gelyk gekyk, daar was nie tyd om verveeld te raak nie;
• met verskillende kollegas kennis gemaak, na hul benaderings gekyk wanneer goggas bekendgestel word;
• al die pyn van die toetsers gevoel.

Wat kan verbeter word:

• doen minder projekte en verhoog sessietyd tot 1,5 uur;
• berei geskenke/aandenkings vroegtydig voor (soms word goedkeuring/betaling vir 'n maand verleng);
• ontspan en kom ooreen met die feit dat iets nie volgens plan sal verloop nie en daar force majeure sal wees.

resensies

Anna Bystrikova, stelseladministrateur: “Die sakhuis is vir my baie leersaam. Ek het die toetsproses geleer, al die "pyn" van die toetsers gevoel.
Aanvanklik, in die toetsproses, as 'n voorbeeldige gebruiker, gaan jy die hoofpunte na: of die knoppie ingedruk is, of dit na die bladsy gaan, of die uitleg uitgeskuif het. Maar later besef jy dat jy meer buite die boks moet dink en die toepassing probeer “breek”. Toetsers het 'n moeilike werk, dit is nie genoeg om deur die hele koppelvlak te "poke" nie, jy moet probeer om buite die boks te dink en uiters oplettend te wees.
Die indrukke was net positief, selfs nou, 'n rukkie na die geleentheid, sien ek hoe daar gewerk word aan die goggas wat ek gevind het. Dit is gaaf om te voel dat jy deel is van die verbetering van die produk ^_^."

Dmitry Seleznev, front-end ontwikkelaar: "Toets in mededingende modus is baie motiverend om meer foute te vind). Dit lyk vir my almal moet probeer om aan Baghunting deel te neem. Verkennende toetsing laat jou toe om daardie gevalle te vind wat nie in die toetsplan beskryf word nie. Boonop kan mense wat nie die projek ken nie terugvoer gee oor die gerief van die diens.”

Antonina Tatchuk, senior redakteur: “Ek het daarvan gehou om myself as 'n toetser te probeer. Dit is 'n heeltemal ander manier van werk. Jy probeer die stelsel breek, nie bevriend raak nie. Ons het altyd die geleentheid gehad om ons kollegas iets oor toetsing te vra. Ek het meer geleer oor die prioritisering van foute (ek het byvoorbeeld vroeër vir grammatikale foute in tekste gesoek, maar so 'n gogga het 'n baie klein “gewig”; en omgekeerd, iets wat vir my nie baie belangrik gelyk het nie, was 'n kritieke fout, wat onmiddellik reggestel is).
By die geleentheid het die ouens 'n opsomming van die teorie van toetsing gegee. Dit was nuttig vir nie-tegniese mense. En 'n paar dae later het ek myself gevang en gedink dat ek skryf ter ondersteuning van 'n ander webwerf deur die "wat-waar-wanneer"-formule te gebruik en my verwagtinge van die webwerf en die werklikheid in detail te beskryf.

Gevolgtrekking

As jy die lewe van die span wil diversifiseer, kyk opnuut na die funksionaliteit, rangskik mini "Eet jou eie hondekos", dan kan jy probeer om so 'n geleentheid te hou, en dan kan ons dit saam bespreek.

Alles van die beste en minder goggas!

Bron: will.com