Tento článek bude zajímat ty, kteří se stejně jako my potýkají s problémem výběru vhodného specialisty v oblasti testování.
S nárůstem počtu IT firem v naší republice kupodivu přibývá jen hodných programátorů, ale ne testerů. Mnoho lidí touží po této profesi, ale málokdo chápe její význam.
Nemohu mluvit za všechny IT společnosti, ale roli QA/QC jsme přidělili našim specialistům na kvalitu. Jsou součástí vývojového týmu a podílejí se na všech fázích vývoje, od výzkumu až po vydání nové verze.
Tester v týmu i ve fázi plánování musí promyslet všechny funkční i nefunkční požadavky na přijetí uživatelského příběhu. Musí rozumět provozním charakteristikám produktu i programátorům a ještě lépe a pomoci týmu nedělat špatná rozhodnutí ani ve fázi plánování. Tester musí mít jasno v tom, jak bude implementovaná funkcionalita fungovat a jaká mohou být úskalí. Naši testeři sami vytvářejí testovací plány a testovací případy a také připravují všechny potřebné testovací stolice. Testování podle hotové specifikace jako opičí kliker není naše možnost. Při práci v týmu musí pomoci uvolnit hodnotný produkt a včas spustit poplach, pokud se něco pokazí.
Na co jsme narazili při hledání testerů
Ve fázi studia mnoha životopisů se zdálo, že pro nás existují specialisté s vhodnými zkušenostmi a s výběrem testera do našeho týmu nebudou žádné problémy. Při osobních setkáních jsme se ale stále častěji setkávali s kandidáty, kteří měli do světa informačních technologií ve skutečnosti dost daleko (neuměli například sdělit principy interakce mezi prohlížečem a webovým serverem, základy bezpečnosti, vztahové a ne relační databáze, o virtualizaci a kontejnerizaci neměli ani ponětí), ale zároveň se hodnotili na úrovni Senior QA. Po provedení desítek rozhovorů jsme došli k závěru, že počet pro nás vhodných specialistů v regionu je zanedbatelný.
Dále vám řeknu, jaké kroky jsme podnikli a jaké chyby jsme šlápli, abychom našli ty dlouho očekávané bojovníky za kvalitu.
Jak jsme se snažili situaci napravit
Když jsme se vyčerpali sháněním hotových specialistů, začali jsme cílit na blízké oblasti:
- Snažili jsme se aplikovat postupy hodnocení, abychom mezi mnoha „nenechavci“ identifikovali právě ty, z nichž můžeme vyvinout silné specialisty.
O splnění úkolů jsme požádali skupinu potenciálních kandidátů s přibližně stejnou úrovní znalostí. Sledováním jejich myšlenkového procesu jsme se pokusili identifikovat nejslibnějšího kandidáta.
Zejména jsme přišli s úkoly, které měly otestovat pozornost, porozumění schopnostem technologie a rysům multikulturalismu:
- Uspořádali jsme setkání pro testery, abychom rozšířili hranice chápání profese mezi stávající kontingenty.
Řeknu vám něco málo o každém z nich.
Ufa Software QA and Testing Meetup #1 je naším prvním pokusem shromáždit ty, kterým na profesi záleží a zároveň pochopit, zda veřejnost bude zajímat, co jim chceme sdělit. Naše zprávy byly v podstatě o tom, kde je lepší začít, pokud jste se rozhodli stát se testerem. Pomozte začátečníkům otevřít oči a podívat se na testování jako dospělí. Mluvili jsme o krocích, které musí začínající testeři podniknout, aby se mohli zapojit do profese. O tom, co je kvalita a jak jí dosáhnout v reálných podmínkách. A také, co je automatické testování a kde je vhodnější jej použít.
Poté jsme v intervalu 1-2 měsíců uspořádali další dvě setkání. Účastníků už bylo dvakrát tolik. Na „Ufa Software QA and Testing Meetup #2“ jsme se ponořili hlouběji do této oblasti. Mluvili o systémech sledování chyb, testování UI/UX, dotkli se Dockeru, Ansible a hovořili také o možných konfliktech mezi vývojářem a testerem a způsobech jejich řešení.Naše třetí setkání, „Ufa Software QA and Testing Meetup #3“, se nepřímo týkalo práce testerů, ale bylo užitečné při včasném připomenutí programátorů jejich technických a organizačních povinností: zátěžové testování, e2e testování, Selenium v autotestování, zranitelnosti webových aplikací. .
Celou tu dobu jsme se učili, jak vytvořit normální světlo a zvuk ve vysílání z našich akcí:
→
→
→ - A nakonec jsme se rozhodli, že zkusíme uspořádat hackathon pro testery
Jak jsme připravili a provedli hackathon pro testery
Nejprve jsme se pokusili pochopit, co je to za „zvíře“ a jak se obvykle provádí. Jak se ukázalo, akce tohoto druhu se v Ruské federaci mockrát nekonaly a nápady není kde půjčovat. Za druhé, nechtěl jsem okamžitě investovat spoustu prostředků do akce, která na první pohled vypadala pochybně. Proto jsme se rozhodli, že budeme dělat krátké minihackathony, ne na celý pracovní cyklus QA, ale na jednotlivé etapy.
Naší hlavní bolestí je nedostatek praxe mezi místními testery při vytváření přehledných testovacích map. Netráví čas zkoumáním uživatelských příběhů před implementací a vytvářením kritérií přijetí, která jsou vývojářům jasná pro funkční a nefunkční požadavky, UI/UX, zabezpečení, pracovní zátěž a špičkovou zátěž. Proto jsme se poprvé rozhodli projít nejzajímavější a nejkreativnější část jejich práce - analýzu a formování požadavků při předprojektovém výzkumu.
Odhadli jsme potenciální počet účastníků a rozhodli jsme se, že potřebujeme alespoň 5 nevyřízených vydání pro vydání MVP, 5 produktů a 5 lidí, kteří by vystupovali jako vlastníci produktů, dešifrovali obchodní potřeby a rozhodovali o omezeních.
Tady je to, co máme: .
Hlavní myšlenkou bylo vymýšlet témata, která byla co nejvíce vzdálená každodenní práci všech účastníků a dát jim prostor pro kreativní let imaginace.
Jaké chyby jsme udělali a co bychom mohli udělat lépe?
Využití hodnotících praktik, tolik oblíbených v oblasti najímání obchodníků a nižších manažerů, stálo obrovské úsilí, ale neumožnilo se dostatečně věnovat každému účastníkovi a zhodnotit jeho schopnosti. Obecně tato možnost výběru vytváří negativní obraz společnosti, protože poměrně hodně lidí dostává nedostatečnou zpětnou vazbu a následně v sobě i ostatních vytváří efekt tyranie zaměstnavatele (komunikace v IT komunitách je velmi rozvinutá). Ve výsledku nám tak zbývají doslova dva potenciální kandidáti s velmi vzdálenou budoucností.
Setkání jsou dobrá věc. Vzniká rozsáhlý podklad pro zpracování a zvyšuje se obecná úroveň účastníků. Společnost je na trhu stále více rozpoznatelná. Pracovní náročnost těchto podniků však není malá. Musíte jasně pochopit, že pořádání setkání zabere přibližně 700–800 člověkohodin ročně.
Co se týče testovacího hackathonu. Tyto druhy akcí se ještě nestaly nudnými, protože na rozdíl od hackathonů pro vývojáře se konají mnohem méně často. Výhodou tohoto nápadu je, že si můžete uvolněnou formou vyměnit velké množství praktických znalostí a poměrně přesně určit úroveň každého účastníka.
Po analýze výsledků akce jsme si uvědomili, že jsme udělali spoustu chyb:
- Nejneodpustitelnější chybou bylo věřit, že nám 4-5 hodin bude stačit. Výsledkem bylo, že pouhé představení a seznámení s backlogy zabralo téměř 2 hodiny.
Práce s vlastníky produktů v počáteční fázi a čas ponořit se do předmětné oblasti trvaly stejně dlouho. Zbývající čas tedy zjevně nestačil na komplexní vývoj testovacích map. - Na podrobnou zpětnou vazbu ke každé mapě nebylo dost času a energie, protože už byla noc. Tudíž jsme tuto část jednoznačně propadli, ale původně byla zamýšlena jako nejcennější v hackathonu.
- Kvalitu vývoje jsme se rozhodli hodnotit prostým hlasováním všech zúčastněných, přičemž každému týmu jsme přidělili 3 hlasy, které mohli dát za nejkvalitnější práci. Možná by bylo lepší uspořádat porotu.
čeho jsi dosáhl?
Náš problém jsme částečně vyřešili a nyní pro nás pracují 4 stateční, pohlední muži, kteří kryjí zadní část 4 vývojových týmů. Významná skupina potenciálních silných kandidátů a hmatatelné změny na úrovni městské komunity QA zatím nebyly zaznamenány. Ale je tu určitý pokrok a to se nemůže jinak než radovat.
Zdroj: www.habr.com