Helló mindenkinek! A nevem Júlia, és tesztelő vagyok. Tavaly meséltem nektek a Hibavadászról — egy eseményről, amelyet a cégünknél tartunk a hibák backlogjának tisztítására. Ez egy teljesen életképes módja annak, hogy jelentősen csökkentsük azt (különböző csapatokban 10-50%-kal) mindössze egy nap alatt.

Ma mesélni szeretnék nektek a tavaszi formátumunkról, a BUgHuntingról (BUH). Ezúttal nem a régi hibákat rögzítettük, hanem újakat kerestünk és ötleteket ajánlottunk a funkciókhoz. A továbbiakban sok részlet található az ilyen események megszervezéséről, az eredményeinkről és a résztvevők visszajelzéseiről.

Miután átgondoltuk és megírtuk a szabályokat, elküldtük a meghívót minden csatornára a vállalati Slack-en, amelyben nem voltak korlátozások:

Végül körülbelül 30 ember jelentkezett — fejlesztők és nem technikai szakemberek is. Az eseményre egy teljes munkanapot szántunk, lefoglaltunk egy nagy tárgyalót, és az ebédeket az iroda étkezdéjében szerveztük.

Miért?

Úgy tűnik, hogy minden csapat teszteli a saját funkcionalitását. A felhasználók jelentik nekünk a hibákat. Miért is lenne szükség egy ilyen esemény megtartására?

Több célunk is volt.

1. Megismertetni a srácokat a szomszédos projektek/termékekkel közelebbről.
   Jelenleg a cégünknél mindenki külön csapatokban dolgozik — egységekben. Ezek projektcsoportok, amelyek a saját funkcionalitásuk részét fejlesztik, és nem mindig vannak teljesen tisztában azzal, hogy mi történik más projekteken.
2. Egyszerűen csak megismertetni egymást a kollégákkal.
   Körülbelül 800 alkalmazottunk van a moszkvai irodában, nem minden kolléga ismeri egymást arcról.
3. Fejleszteni a hibafelismerési készséget a fejlesztőkben a saját termékeikben.
   Jelenleg az Agile Testinget népszerűsítjük, és fejlesztjük a srácokat ebben az irányban.
4. Tesztelésbe bevonni nemcsak technikai szakembereket.
   A technikai részlegen kívül sok más szakterületünk is van, akikkel szeretnénk többet beszélni a tesztelésről, arról, hogyan lehet jól hibajelentést tenni, hogy kevesebb „Aaaa… semmi sem működik” üzenetet kapjunk.
5. Nos, és persze, találni a rejtett és nem nyilvánvaló hibákat.
   Szerettük volna segíteni a csapatoknak az új funkciók tesztelésében, és lehetőséget adni, hogy más szögből is megnézzék a megvalósított funkcionalitást.

Megvalósítás

A napunk több blokkra oszlott:

• briefing;
• Rövid előadás a tesztelésről, amelyben csak a legfontosabb pontokat érintettük (a tesztelés céljai és elvei stb.);
• szakasz a „jó modorról” a hibák bejelentésekor (itt jól leírt elvekről);
• négy tesztelési ülés projekteken, magasan szintű forgatókönyvekkel; minden ülés előtt rövid bevezető előadás volt a projektről és a csapatok elosztása;
• rövid kérdőív az eseménnyel kapcsolatban;
• a következtetések levonása.

(A szünetekről a ülések között és az ebédről sem feledkeztünk meg).

Alapvető szabályok

• A rendezvényekre történő regisztráció egyéni, ami megoldja a problémát, hogy az egész csapat inercia alapján elmenjen, ha valaki úgy dönt, hogy nem megy.
• Minden ülésnél a résztvevők csapatot váltanak. Ez lehetővé teszi a résztvevők számára, hogy bármikor jöhessenek-elhessenek, és így sok emberrel megismerkedhessenek.
• Csapatok két ember ülésenként véletlenszerű módon alakulnak, így dinamikusabb és gyorsabb a folyamat.
• A bejegyzett hibákért pontokat adunk (3-tól 10-ig) a kritikuság függvényében.
• A duplikált hibákért pontokat nem adunk.
• A hibákat a csapat tagja kell, hogy regisztrálja, a belső szabványok szerint.
• A funkciókéréseket külön feladatként regisztráljuk, és külön jelölésben vesznek részt.
• A szabályok betartását az audit csapat figyeli.

További részletek

• Kezdetben egy „fejlettebb” tesztelési eseményt szerettem volna, de mivel sok srác jelentkezett nem termékeny csapatokból (SMM, jogászok, PR), a tartalmat jelentősen egyszerűsíteni kellett, és bonyolult/professzionális eseteket el kellett távolítani.
• A Jira egységek különböző projektekben végzett munkája miatt külön projektet hoztunk létre, ahol beállítottunk egy sablont a hibák bejelentésére.
• A pontok számításához eredetileg egy rangsort terveztünk, amelyet webhúzásokon keresztül frissítettek, de valami nem működött, így végül manuálisan kellett számolni.

Mindenki, aki rendezvényeket szervez, belefut a buktatókba, és hogy kicsit könnyebb legyen, leírom azokat a problémáinkat, amelyeket elkerülhettek.

Az egyik előadó hirtelen megbetegedett, és új embert kellett keresni..
Nekem hihetetlenül szerencsém volt, hogy reggel 9-kor találtam egy helyettesítőt ugyanabból a csapatból). De a szerencsére ne bízz, és legyen egy tartalék. Vagy magadnak kell készen állnod arra, hogy a szükséges előadást tartsd.

Nem tudtuk kiadni a funkciót, ezért a blokkokat kellett átrendeznünk..
Ahelyett, hogy az egész blokkot kidobnád, jobb, ha van egy tartalék terved.

Néhány tesztfelhasználó eltűnt, gyorsan újakat kellett létrehozni..
Ellenőrizd előre a tesztfelhasználókat, vagy legyen lehetőséged gyorsan újakat készíteni.

Majdnem senki sem jött el azok közül a srácok közül, akiket a könnyített formátum miatt hívtunk..
Senkit sem kell erőltetni. Fogadd el.
Lehetőség van a rendezvény formátumának szigorú megfogalmazására: "amatőr" / "haladó", vagy készíthetsz két változatot, és a tények alapján dönthetsz, hogy melyiket valósítod meg.

Hasznos szervezési szempontok:

• foglalj tárgyalót előre;
• rendezd el az asztalokat, ne felejtsd el az hosszabbítókat és a hálózati szűrőket (a laptopok / telefonok napi töltésére nem biztos, hogy elegendő lesz);
• automatizáld a pontszámok számítási folyamatát;
• készítsd el a ranglistákat;
• készíts papíralapú kiosztót a tesztfelhasználók belépési adataival, útmutatóval a Jira használatához, forgatókönyvekkel;
• ne felejtsd el egy héttel az esemény előtt elküldeni az emlékeztetőket, további információként add meg, hogy mit kell hozniuk magukkal (laptopok / eszközök);
• beszélj a kollégáknak az eseményről a bemutatókon, ebédnél, egy csésze kávé mellett;
• egyeztess a devops csapattal, hogy semmit ne frissítsenek vagy indítsanak ezen a napon;
• készülj fel az előadókra;
• egyeztess a funkciók tulajdonosaival, és dolgozz ki minél több tesztelési forgatókönyvet;
• rendelj finomságokat (sütiket / cukorkákat) a falatozáshoz;
• ne felejtsd el beszámolni az esemény eredményeiről.

Eredmények

Egy nap alatt a csapat 4 projektet tesztelt, és 192 hibát talált (ebből 134 egyedi) és 7 feladatot a funkciókérésekkel. Persze, a projektek tulajdonosai már tudtak néhány hibáról. De voltak meglepő felfedezések is.

Minden résztvevő édes jutalmakat kapott.

A győztesek termoszt, kitűzőket és pulóvereket nyertek.

Ami érdekes volt:

• a résztvevők számára meglepő volt a szigorú ülések formátuma, amikor az idő korlátozott, és nem lehet sok időt eltölteni a gondolkodással;
• sikerült tesztelni az asztali, a mobil verziót és az alkalmazásokat;
• sok projektre néztünk rá egyszerre, nem volt idő unatkozni;
• megismertük a különböző kollégákat, megnéztük, hogy miként közelítik meg a hibák bejegyzését;
• átéreztük a tesztelők fájdalmát.

Amit lehetne javítani:

• kevesebb projektet csinálni és növelni az ülések időtartamát 1,5 órára;
• ajándékok/szuvenírek készítése erősen előre (néha az egyeztetés/fizetés egy hónapig is elhúzódhat);
• relaxálni és elfogadni, hogy valami nem a tervek szerint alakul, és előfordulhatnak vis maior helyzetek.

Vélemények

Anna Bystrikova, rendszergazda: „A Buggyűjtő számomra nagyon tanulságos volt. Megismertem a tesztelési folyamatot, és éreztem a tesztelők minden „fájdalmát”.
Kezdetben a tesztelési folyamat során, mint átlagos felhasználó, ellenőrzöd az alapvető dolgokat: működik-e a gomb, átvezet-e az oldalra, nem csúszott-e el a dizájn. De később rájössz, hogy szokatlanul kell gondolkodni és megpróbálni „megtörni” az alkalmazást. A tesztelők munkája nem egyszerű, nem elég csak „kipróbálni” az egész felületet, igyekezni kell kreatívan gondolkodni és rendkívül figyelmesnek lenni.
A benyomásaim csak pozitívak maradtak, még most is, egy idő után az esemény után, látom, hogyan dolgoznak a nálam talált hibákon. Nagyszerű érzés részt venni a termék fejlesztésében ^_^”.

Dmitrij Szeleznyev, frontend fejlesztő: „A versenyszerű tesztelés nagyon motivál arra, hogy minél több hibát találj). Szerintem mindenkinek érdemes lenne részt venni a Bugvadászatban. A felfedező tesztelés lehetővé teszi olyan esetek megtalálását, amelyeket nem írtunk le a tesztelési tervben. Plusz azok az emberek, akik nem ismerik a projektet, visszajelzést adhatnak a szolgáltatás használhatóságáról.”

Antonina Tatchuk, vezető szerkesztő: „Tetszett, hogy kipróbáltam magam tesztelőként. Ez egy teljesen más munka stílus. Megpróbálod megtörni a rendszert, nem pedig együttműködni vele. Mindig volt lehetőségünk kérdezni a kollégáktól a teszteléssel kapcsolatban. Többet tudtam meg a hibák priorizálásáról (például hozzászoktam a szövegek grammatikai hibáira figyelni, de ilyen hiba „súlya” nagyon kicsi; és fordítva, ami számomra nem tűnt túl fontosnak, végül kritikus hibának bizonyult, amelyet azonnal javítottak).
Az eseményen a fiúk összefoglalót adtak a tesztelés elméletéről. Ez hasznos volt nem technikai szakemberek számára. Pár nappal később azon kaptam magam, hogy egy másik weboldal támogatásának írásakor a „mit-hol-mikor” képlettel dolgozom, és részletesen leírom az elvárásaimat a weboldaltól és a valóságtól.”

Zárás

Ha szeretné színesebbé tenni a csapat életét, friss szemmel tekinteni a funkcionalitásra, akkor mini „Egyél a saját kutyaeledelodból“, akkor kipróbálhatsz egy ilyen eseményt, utána pedig közösen megbeszélhetjük.

Mindenkinek jót és kevesebb hibát kívánok!

Forrás: habr.com