Miért tartottunk hackathont tesztelőknek?

Ez a cikk azok számára lesz érdekes, akik hozzánk hasonlóan a megfelelő szakember kiválasztásának problémájával szembesülnek a tesztelés területén.

Furcsa módon köztársaságunkban az informatikai cégek számának növekedésével csak az arra érdemes programozók száma nő, a tesztelők száma nem. Sokan vágynak ebbe a szakmába, de kevesen értik a jelentését.

Nem beszélhetek minden informatikai cég nevében, de a minőségbiztosítási/minőségellenőrzési szerepet minőségügyi szakembereinkre bíztuk. Részei a fejlesztőcsapatnak, és részt vesznek a fejlesztés minden szakaszában, a kutatástól az új verzió kiadásáig.

Egy csapat tesztelőjének még a tervezési szakaszban is végig kell gondolnia a felhasználói történet elfogadásához szükséges összes funkcionális és nem funkcionális követelményt. Meg kell értenie a termék működési jellemzőit éppúgy, mint a programozókat, sőt még jobbat, és segítenie kell a csapatot abban, hogy még a tervezési szakaszban ne hozzanak rossz döntéseket. A tesztelőnek tisztában kell lennie azzal, hogy a megvalósított funkcionalitás hogyan fog működni, és milyen buktatók lehetnek. Tesztelőink maguk készítenek tesztterveket és teszteseteket, valamint elkészítik az összes szükséges próbapadot. A kész specifikáció szerinti tesztelés, mint a majomcsattogó, nem választható. A csapaton belül kell segítenie egy méltó termék kibocsátását, és időben riasztania kell, ha valami elromlik.

Amivel találkoztunk, amikor tesztelőket kerestünk

Sok önéletrajz tanulmányozásának szakaszában úgy tűnt, hogy megfelelő tapasztalattal rendelkező szakemberek vannak számunkra, és nem lesz probléma a tesztelő kiválasztásával csapatunkba. De a személyes találkozások során egyre gyakrabban találkoztunk olyan jelöltekkel, akik valójában meglehetősen távol álltak az információs technológia világától (például nem tudták megmondani a böngésző és a webszerver interakciójának elveit, a biztonság alapjait, a relációs és nem relációs adatbázisok, fogalmuk sem volt a virtualizációról és a konténerezésről), ugyanakkor a Senior QA szinten értékelték magukat. Több tucat interjú elkészítése után arra a következtetésre jutottunk, hogy a régióban elenyésző a számunkra megfelelő szakemberek száma.

Ezután elmondom, milyen lépéseket tettünk és milyen hibákat követtünk el annak érdekében, hogy megtaláljuk azokat a régóta várt minőségi harcosokat.

Hogyan próbáltuk megoldani a helyzetet

Miután kimerítettük magunkat a kész szakemberek beszerzésében, elkezdtük megcélozni a közeli területeket:

1. Igyekeztünk értékelési gyakorlatokat alkalmazni, hogy a sok „elhagyó” között azonosítsuk azokat, akikből erős szakembereket tudunk fejleszteni.

   A feladatok elvégzésére egy közel azonos szintű tudással rendelkező potenciális jelöltet kértünk fel. Gondolkodási folyamatukat figyelve megpróbáltuk azonosítani a legígéretesebb jelöltet.

   Különösen a figyelmesség, a technológia képességeinek és a multikulturalizmus jellemzőinek megértésének tesztelésére találtunk ki feladatokat:

   
   

2. A tesztelőknek találkozókat tartottunk, hogy kitágítsuk a szakma megértésének határait a meglévő kontingensek körében.

   Mindegyikről mesélek egy kicsit.

   Az Ufa Software QA and Testing Meetup #1 az első kísérletünk arra, hogy összegyűjtsük azokat, akik törődnek a szakmával, és egyúttal megértsük, hogy a közvéleményt érdekli-e az, amit közvetíteni szeretnénk nekik. A beszámolóink ​​alapvetően arról szóltak, hogy hol érdemes elkezdeni, ha úgy döntött, hogy tesztelő lesz. Segíts a kezdőknek kinyitni a szemüket, és úgy tekinteni a tesztekre, mint egy felnőttre. Beszéltünk azokról a lépésekről, amelyeket a kezdő tesztelőknek meg kell tenniük, hogy bekapcsolódhassanak a szakmába. Arról, hogy mi a minőség és hogyan érhető el valós körülmények között. És azt is, hogy mi az automatikus tesztelés, és hol célszerűbb használni.

   
   
   Ezután 1-2 hónapos szünettel még két találkozót tartottunk. Már kétszer annyi résztvevő volt. Az „Ufa Software QA and Testing Meetup #2” rendezvényen mélyebben belemerültünk a témakörbe. Szó esett a hibakövető rendszerekről, az UI/UX tesztelésről, szó esett a Dockerről, az Ansible-ről, és szó esett a fejlesztő és a tesztelő közötti esetleges konfliktusokról és azok megoldási módjairól is.

   Harmadik találkozónk, az „Ufa Software QA and Testing Meetup #3” közvetetten a tesztelők munkájához kapcsolódott, de hasznos volt abban, hogy időben emlékeztesse a programozókat technikai és szervezési feladataikra: terhelési tesztelés, e2e tesztelés, szelén az automatikus tesztelésben, webalkalmazások sebezhetősége .

   Egész idő alatt azt tanultuk, hogyan lehet normális fényt és hangot létrehozni rendezvényeink közvetítésében:

   → A tesztelés első lépései – Ufa Software QA és Testing Meetup #1
   → UI/UX tesztelés – Ufa Software QA and Testing Meetup #2
   → Biztonsági tesztelés, terhelési tesztelés és automatikus tesztelés – Ufa QA és Testing Meetup #3

3. És végül úgy döntöttünk, hogy megpróbálunk hackathont tartani a tesztelőknek

Hogyan készítettünk elő és bonyolítottunk le egy hackathont tesztelőknek

Először is megpróbáltuk megérteni, hogy ez milyen „vadállat”, és hogyan szokták végrehajtani. Mint kiderült, az Orosz Föderációban nem sokszor rendeztek ilyen jellegű rendezvényeket, és nincs honnan ötleteket kölcsönözni. Másodszor, nem akartam azonnal sok erőforrást fektetni egy első pillantásra kétesnek tűnő eseménybe. Ezért úgy döntöttünk, hogy nem a teljes minőségbiztosítási munkaciklusra, hanem az egyes szakaszokra rövid mini-hackathonokat készítünk.

A fő fejtörést a helyi tesztelők gyakorlatának hiánya okozza az egyértelmű tesztelési térképek elkészítésében. Nem töltik az időt a bevezetés előtti felhasználói történetek kutatásával és olyan elfogadási kritériumok létrehozásával, amelyek a fejlesztők számára egyértelműek a funkcionális és nem funkcionális követelmények, UI/UX, biztonság, munkaterhelések és csúcsterhelések tekintetében. Ezért először úgy döntöttünk, hogy munkájuk legérdekesebb és legkreatívabb részét - a projekt előtti kutatás során végzett elemzést és a követelmények kialakítását - végigvesszük.

Megbecsültük a potenciális résztvevők számát, és úgy döntöttünk, hogy legalább 5 lemaradásra van szükségünk az MVP kiadásokhoz, 5 termékre és 5 emberre, akik terméktulajdonosként lépnek fel, megfejtik az üzleti igényeket és döntéseket hoznak a korlátozásokról.

Íme, amit kaptunk: elmaradások a hackathonhoz.

A fő ötlet az volt, hogy olyan témákat dolgozzunk ki, amelyek a lehető legtávolabb állnak a résztvevők napi munkájától, és teret adjunk nekik a kreatív képzeletrepüléshez.

Milyen hibákat követtünk el, és mit tehetnénk jobban?

Az értékesítők és az alsóbb szintű menedzserek alkalmazása terén oly népszerű értékelési gyakorlatok alkalmazása hatalmas erőfeszítést igényelt, de nem tette lehetővé, hogy minden résztvevőre kellő figyelmet fordítsunk és képességeit értékeljük. Általánosságban elmondható, hogy ez a kiválasztási lehetőség negatív képet hoz létre a vállalatról, mivel meglehetősen sokan nem kapnak elegendő visszajelzést, és ezt követően magukban és másokban a munkáltató zsarnokságának hatását keltik (az IT-közösségek kommunikációja nagyon fejlett). Ennek eredményeként szó szerint két potenciális jelöltünk maradt, akiknek nagyon távoli jövője van.

A találkozások jó dolgok. A kidolgozásra kiterjedt alapot teremtenek, a résztvevők általános színvonala emelkedik. A cég egyre jobban felismerhető a piacon. De az ilyen vállalkozások munkaintenzitása nem kicsi. Világosan meg kell értenie, hogy a találkozók megtartása körülbelül 700-800 munkaórát vesz igénybe évente.

Ami a tesztelő hackathont illeti. Az ilyen jellegű rendezvények még nem váltak unalmassá, hiszen a fejlesztői hackathonokkal ellentétben sokkal ritkábban rendezik meg őket. Ennek az ötletnek az az előnye, hogy laza módon nagy mennyiségű gyakorlati tudást cserélhet ki, és elég pontosan meghatározhatja az egyes résztvevők szintjét.

A rendezvény eredményeit elemezve rájöttünk, hogy rengeteg hibát követtünk el:

1. A legmegbocsáthatatlanabb tévedés az volt, hogy azt hittük, nekünk 4-5 óra is elég lesz. Ennek eredményeként csak a bemutatkozás és a lemaradásokkal való ismerkedés közel 2 órát vett igénybe.
   A terméktulajdonosokkal való együttműködés a kezdeti szakaszban, és ugyanennyi időt vett igénybe, hogy belemerüljünk a témakörbe. A fennmaradó idő tehát nyilvánvalóan nem volt elegendő a tesztelési térképek átfogó kidolgozásához.
2. Nem volt elég idő és energia az egyes térképek részletes visszajelzésére, mivel már éjszaka volt. Ezért ezt a részt egyértelműen megbuktuk, de eredetileg a legértékesebbnek szántuk a hackathonon.
3. Úgy döntöttünk, hogy a fejlesztés minőségét minden résztvevő egyszerű szavazatával értékeljük, csapatonként 3 szavazatot osztva ki, amit a legmagasabb színvonalú munkáért adhatnak. Talán jobb lenne zsűrit szervezni.

Mit értél el?

Részben megoldottuk a problémánkat, és most 4 bátor, jóképű férfi dolgozik nálunk, 4 fejlesztőcsapat hátulját lefedve. A potenciális erős jelöltek jelentős körét és a város minőségbiztosítási közösségének szintjén tapasztalható kézzelfogható változásokat még nem vették észre. De van némi előrelépés, és ez csak örülni fog.

Forrás: will.com