Sziasztok! A nevem Julia és tesztelő vagyok. Tavaly meséltem róla Bagodelnya - cégünkben megtartott rendezvény a hibalemaradás felszámolására. Ez egy teljesen életképes lehetőség annak jelentős csökkentésére (különböző csapatokban 10-ről 50%-ra) egyetlen nap alatt.

Ma a tavaszi Bagodelny formátumunkról szeretnék mesélni - BUgHunting (BUH). Ezúttal nem a régi hibákat javítottuk, hanem újakat kerestünk, és ötleteket adtunk a funkciókhoz. A vágás alatt számos részlet található az ilyen rendezvények megszervezéséről, eredményeinkről és a résztvevők visszajelzéseiről.

A szabályzatot átgondolva és leírva a vállalati Slack összes csatornájára kiküldtünk egy meghívót, amely nem tartalmazott megkötést:

Ennek eredményeként körülbelül 30 ember iratkozott fel - fejlesztők és nem műszaki szakemberek egyaránt. Egy egész munkanapot szántunk a rendezvényre, lefoglaltunk egy nagy tárgyalót, és ebédet szerveztünk az irodai menzán.

Miért?

Úgy tűnik, hogy minden csapat teszteli a működését. A felhasználók hibákat jelentenek nekünk. Miért is tartanak ilyen rendezvényt?

Több gólunk is volt.

1. Mutassa be a srácokat közelebbről a kapcsolódó projektekhez/termékekhez.
   Cégünkben most mindenki külön csapatokban - egységekben - dolgozik. Ezek olyan projektcsapatok, amelyek a funkcionalitás saját részén dolgoznak, és nincsenek mindig teljesen tisztában azzal, hogy mi történik más projektekben.
2. Csak mutasd be a kollégáidat egymásnak.
   Moszkvai irodánkban közel 800 alkalmazott dolgozik, nem minden kolléga ismeri egymást látásból.
3. Javítani kell a fejlesztők azon képességét, hogy hibákat találjanak termékeikben.
   Most népszerűsítjük az Agilis Tesztelést és a srácokat ebben az irányban.
4. A tesztelésbe nem csak műszaki szakembereket vonhat be.
   A műszaki osztályon kívül sok más szakterületről érkezett kollégánk is szeretne többet beszélni a tesztelésről, arról, hogyan kell helyesen jelenteni egy hibát, hogy kevesebb olyan üzenetet kapjunk, mint „Ahhh... semmi sem működik”.
5. És természetesen találhat trükkös és nyilvánvaló hibákat.
   Segíteni akartam a csapatoknak az új funkciók tesztelésében, és lehetőséget adni számukra, hogy más szemszögből nézzék meg a megvalósított funkciókat.

Реализация

Napunk több blokkból állt:

• eligazítás;
• rövid előadás a tesztelésről, melyben csak a főbb pontokat érintettük (a tesztelés céljai és elvei stb.);
• a „jó modor szabályairól” szóló részt a hibák bevezetésekor (itt az alapelvek jól leírtak);
• négy tesztelési munkamenet magas szintű leírt forgatókönyvekkel rendelkező projektekhez; minden foglalkozás előtt egy rövid bevezető előadást tartottak a projektről és csapatokra osztásról;
• rövid felmérés az eseményről;
• összefoglalva.

(Nem feledkeztünk meg a foglalkozások és az ebéd közötti szünetekről sem).

Alapvető szabályok

• A rendezvényekre való jelentkezés egyéni, ami megoldja azt a problémát, hogy az egész csapat a tehetetlenség miatt kiürül, ha egy ember úgy dönt, nem megy.
• A résztvevők minden foglalkozáson csapatot cserélnek. Ez lehetővé teszi a résztvevők számára, hogy bármikor jöjjenek és menjenek, és több emberrel is találkozhat.
• parancsok két ember minden ülés előtt véletlenszerűen alakulnak ki, ez dinamikusabbá és gyorsabbá teszi.
• A bevezetett hibákért díjazásban részesül pont (3-10) kritikusságtól függően.
• A másolatokért nem jár pont.
• A hibákat egy csapattagnak kell bejelentenie az összes belső szabványnak megfelelően.
• A funkcióigények külön feladatban jönnek létre, és külön jelölésben vesznek részt.
• Az audit csoport minden szabály betartását ellenőrzi.

Egyéb részletek

• Kezdetben egy „haladó” tesztelési eseményt akartam csinálni, de... Elég sok srác jelentkezett nem termékcsapatokból (SMM, ügyvédek, PR), nagymértékben le kellett egyszerűsítenünk a tartalmat és el kellett távolítanunk a bonyolult/profil eseteket.
• A Jira-i egységek különböző projektekben végzett munkája miatt, a mi folyamatunknak megfelelően, külön projektet készítettünk, amelyben egy sablont állítottunk be a hibák bevezetéséhez.
• A pontok kiszámításához webhookon keresztül frissített ranglistát terveztek használni, de valami elromlott, és végül manuálisan kellett a számítást elvégezni.

A rendezvények szervezése során mindenki problémába ütközik, és hogy egy kicsit megkönnyítsem a dolgát, leírom a problémáinkat, amelyeket elkerülhet.

Az egyik hangszóró hirtelen megbetegedett, és újat kellett keresnie.
Nagy szerencsém volt, hogy 9 órakor cserét találtam ugyanattól a csapattól). De jobb, ha nem hagyatkozunk a szerencsére, és van tartalékunk. Vagy legyen kész a szükséges jelentés elkészítésére.

Nem volt időnk kiteregetni a funkcionalitást, ki kellett cserélnünk a blokkokat.
Az egész blokk kidobásának elkerülése érdekében jobb, ha van tartalék terve.

Néhány tesztfelhasználó visszaesett, gyorsan újat kellett létrehoznunk.
Ellenőrizze a tesztfelhasználókat előre, vagy végezze el gyorsan.

Szinte senki sem jött el azok közül, akiknek leegyszerűsítették a formátumot.
Nem kell senkit erőszakkal hurcolni. Alázd meg magad.
Lehetőség van arra, hogy szigorúan előírjuk a rendezvény formátumát: „amatőr”/„haladó”, vagy készítsünk egyszerre két lehetőséget, és utólag döntsük el, melyiket tartsuk meg.

Hasznos szervezési szempontok:

• előre foglaljon találkozót;
• rendezze el az asztalokat, ne feledkezzen meg a hosszabbítóról és a túlfeszültség-védőről (a laptopok/telefonok töltése nem biztos, hogy egész napra elegendő);
• automatizálja a pontozási folyamatot;
• rangsor táblázatokat készíteni;
• papíralapú tájékoztató készítés a tesztfelhasználók bejelentkezési adataival és jelszavaival, a Jira-val való munkavégzésre vonatkozó utasításokkal, szkriptekkel;
• Ne felejtsen el egy héttel az esemény előtt emlékeztetőket kiküldeni, és azt is jelezze, hogy mit kell magával vinnie (laptopok/eszközök);
• meséljen kollégáinak az eseményről bemutatón, ebédeken, egy csésze kávé mellett;
• állapodjon meg a devokkal, hogy ezen a napon nem frissítenek vagy dobnak ki semmit;
• előkészíti a hangszórókat;
• tárgyaljon a funkciók tulajdonosaival, és írjon több forgatókönyvet a teszteléshez;
• csemegék (sütik/cukorkák) rendelése rágcsálnivalókhoz;
• ne felejtse el beszámolni nekünk az esemény eredményeiről.

Álláspontja

Az egész nap során a srácoknak 4 projektet sikerült tesztelniük, és 192 hibát (ebből 134 egyedit) és 7 funkciókéréssel kapcsolatos problémát sikerült létrehozniuk. Természetesen a projekttulajdonosok már tudtak néhány ilyen hibákról. De voltak váratlan leletek is.

Minden résztvevő édes ajándékot kapott.

A nyertesek pedig termoszok, kitűzők, pulóverek.

Ami érdekes lett:

• a résztvevők váratlannak találták a kemény foglalkozások formáját, amikor az idő korlátozott, és nem lehet sok időt tölteni gondolkodással;
• sikerült tesztelni az asztali, mobil verziót és az alkalmazásokat;
• sok projektet néztünk meg egyszerre, nem volt idő unatkozni;
• találkozott különböző kollégákkal, megvizsgálta a hibák bevezetésével kapcsolatos megközelítéseiket;
• érezte a tesztelők minden fájdalmát.

Amit lehet javítani:

• csináljon kevesebb projektet, és növelje a munkamenet idejét 1,5 órára;
• ajándékokat/ajándéktárgyakat jóval előre elkészíteni (néha a jóváhagyás/kifizetés egy hónapig tart);
• lazíts és fogadd el, hogy valami nem a tervek szerint fog menni, és vis maior lesz.

Vélemények

Anna Bystrikova, rendszergazda: „Az alamizsna nagyon tanulságos számomra. Megtanultam a tesztelési folyamatot, és éreztem a tesztelők minden „fájdalmát”.
Eleinte a tesztelés során példaértékű felhasználóként a főbb pontokat ellenőrzi: kattan-e a gomb, megy-e az oldalra, kimozdult-e az elrendezés. De később rájössz, hogy többet kell gondolkodnod a kereteken kívül, és meg kell próbálnod „megtörni” az alkalmazást. A tesztelőknek nehéz dolguk van; nem elég az egész felületet „bökni”, meg kell próbálni a kereteken kívül gondolkodni, és rendkívül figyelmesnek kell lenni.
A benyomások csak pozitívak voltak, most is, valamivel az esemény után látom, hogyan dolgoznak a talált hibákon. Nagyszerű érzés részt venni a termék fejlesztésében ^_^.”

Dmitrij Seleznev, front-end fejlesztő: „A verseny módban végzett tesztelés nagymértékben motivál bennünket, hogy további hibákat találjunk). Számomra úgy tűnik, hogy mindenkinek meg kell próbálnia részt venni a Baghuntingben. A feltáró tesztelés lehetővé teszi, hogy megtalálja azokat az eseteket, amelyek nem szerepelnek a teszttervben. Ráadásul azok, akik nem ismerik a projektet, visszajelzést adhatnak a szolgáltatás kényelméről.”

Antonina Tatchuk, vezető szerkesztő: „Szerettem kipróbálni magam tesztelőként. Ez egy teljesen más munkastílus. Meg akarod törni a rendszert, nem pedig megbarátkozni vele. Mindig volt lehetőségünk megkérdezni kollégáinkat a teszteléssel kapcsolatban. Többet tanultam a hibák priorizálásáról (például megszoktam, hogy nyelvtani hibákat keresek a szövegekben, de egy ilyen hiba "súlya" nagyon kicsi; és fordítva, valami, ami számomra nem tűnt túl fontosnak, az lett egy kritikus hiba, amelyet azonnal javítottak).
Az eseményen a srácok összefoglalót adtak a tesztelés elméletéről. Ez hasznos volt a nem műszaki emberek számára. Néhány nappal később azon kaptam magam, hogy egy másik oldal támogatására írok a „mit-hol-mikor” formulával, és részletesen leírom az oldallal és a valósággal kapcsolatos elvárásaimat.”

Következtetés

Ha változatosabbá szeretné tenni csapata életét, nézze meg frissen a funkcionalitást, rendezzen miniat "Egyél saját kutyaeledelt", akkor megpróbálhatsz egy ilyen rendezvényt tartani, és akkor megbeszélhetjük közösen.

Minden jót és kevesebb hibát!

Forrás: will.com