Tento článok bude zaujímať tých, ktorí sa rovnako ako my stretávajú s problémom výberu vhodného špecialistu v oblasti testovania.
Napodiv, s pribúdajúcim počtom IT firiem v našej republike pribúda len hodných programátorov, ale nie testerov. Mnoho ľudí sa túži dostať do tohto povolania, no málokto chápe jeho význam.
Nemôžem hovoriť za všetky IT spoločnosti, ale úlohu QA/QC sme pridelili našim špecialistom na kvalitu. Sú súčasťou vývojového tímu a podieľajú sa na všetkých fázach vývoja, od výskumu až po vydanie novej verzie.
Tester v tíme, už vo fáze plánovania, musí premyslieť všetky funkčné a nefunkčné požiadavky na prijatie používateľského príbehu. Musí rozumieť prevádzkovým charakteristikám produktu aj programátorom a ešte lepšie a pomáhať tímu nerobiť nesprávne rozhodnutia ani vo fáze plánovania. Tester musí mať jasno v tom, ako bude implementovaná funkcionalita fungovať a aké môžu byť úskalia. Naši testeri sami vytvárajú testovacie plány a testovacie prípady, ako aj pripravujú všetky potrebné testovacie lavice. Testovanie podľa pripravenej špecifikácie ako opičí kliker nie je naša možnosť. V rámci tímu musí pomôcť uvoľniť hodnotný produkt a včas spustiť alarm, ak sa niečo pokazí.
S čím sme sa stretli pri hľadaní testerov
V štádiu študovania mnohých životopisov sa zdalo, že pre nás existujú špecialisti s vhodnými skúsenosťami a s výberom testera do nášho tímu nebudú žiadne problémy. Pri osobných stretnutiach sme sa však čoraz častejšie stretávali s kandidátmi, ktorí mali skutočne dosť ďaleko od sveta informačných technológií (napríklad nevedeli povedať princípy interakcie medzi prehliadačom a webovým serverom, základy bezpečnosti, vzťahovej a relačné databázy, o virtualizácii a kontajnerizácii nemali ani potuchy), no zároveň sa hodnotili na úrovni Senior QA. Po vykonaní desiatok rozhovorov sme dospeli k záveru, že počet špecialistov vhodných pre nás v regióne je zanedbateľný.
Ďalej vám poviem, aké kroky sme podnikli a aké chyby sme šliapali, aby sme našli tých dlho očakávaných bojovníkov za kvalitu.
Ako sme sa snažili situáciu napraviť
Keď sme sa vyčerpali získavaním hotových špecialistov, začali sme sa zameriavať na blízke oblasti:
- Snažili sme sa aplikovať hodnotiace praktiky, aby sme medzi mnohými „nechavcami“ identifikovali práve tých, z ktorých môžeme vychovať silných špecialistov.
O splnenie úloh sme požiadali skupinu potenciálnych kandidátov s približne rovnakou úrovňou vedomostí. Sledovaním ich myšlienkového procesu sme sa pokúsili identifikovať najsľubnejšieho kandidáta.
Predovšetkým sme prišli s úlohami na testovanie pozornosti, chápania schopností technológie a čŕt multikulturalizmu:
- Usporiadali sme stretnutia pre testerov, aby sme rozšírili hranice chápania profesie medzi existujúcim kontingentom.
O každom z nich vám trochu poviem.
Ufa Software QA and Testing Meetup #1 je naším prvým pokusom zhromaždiť tých, ktorým na profesii záleží a zároveň pochopiť, či verejnosť bude mať záujem o to, čo im chceme sprostredkovať. Naše správy boli v podstate o tom, kde je lepšie začať, ak ste sa rozhodli stať sa testerom. Pomôžte začiatočníkom otvoriť oči a pozrieť sa na testovanie ako dospelý. Hovorili sme o krokoch, ktoré musia urobiť začínajúci testeri, aby sa mohli zapojiť do tejto profesie. O tom, čo je kvalita a ako ju dosiahnuť v reálnych podmienkach. A tiež, čo je automatické testovanie a kde je vhodnejšie ho použiť.
Potom sme v intervale 1-2 mesiacov uskutočnili ďalšie dve stretnutia. Účastníkov bolo už dvakrát toľko. Na „Ufa Software QA and Testing Meetup #2“ sme sa ponorili hlbšie do predmetnej oblasti. Hovorili o systémoch na sledovanie chýb, testovaní UI/UX, dotkli sa Dockera, Ansible a hovorili aj o možných konfliktoch medzi vývojárom a testerom a spôsoboch ich riešenia.Naše tretie stretnutie, „Ufa Software QA and Testing Meetup #3“, sa nepriamo týkalo práce testerov, ale bolo užitočné na to, aby sme programátorom včas pripomenuli ich technické a organizačné povinnosti: záťažové testovanie, e2e testovanie, Selén v autotestovaní, zraniteľnosti webových aplikácií. .
Celý ten čas sme sa učili vytvárať normálne svetlo a zvuk vo vysielaniach z našich podujatí:
→
→
→ - A nakoniec sme sa rozhodli, že skúsime spraviť hackathon pre testerov
Ako sme pripravili a zrealizovali hackathon pre testerov
Najprv sme sa pokúsili pochopiť, o aký druh „šelmy“ ide a ako sa zvyčajne vykonáva. Ako sa ukázalo, podujatia tohto druhu sa v Ruskej federácii veľakrát neuskutočnili a nápady si niet kde požičiavať. Po druhé, nechcel som okamžite investovať veľa prostriedkov do udalosti, ktorá sa na prvý pohľad zdala pochybná. Preto sme sa rozhodli, že budeme robiť krátke minihackatóny nie na celý pracovný cyklus QA, ale na jednotlivé etapy.
Našou hlavnou bolesťou je nedostatok praxe medzi miestnymi testermi pri vytváraní prehľadných testovacích máp. Netrávia čas skúmaním príbehov používateľov pred implementáciou a vytváraním kritérií prijatia, ktoré sú vývojárom jasné pre funkčné a nefunkčné požiadavky, UI/UX, bezpečnosť, pracovné zaťaženie a špičkové zaťaženie. Preto sme sa po prvýkrát rozhodli prejsť najzaujímavejšou a najkreatívnejšou časťou ich práce – analýzou a formovaním požiadaviek počas predprojektového výskumu.
Odhadli sme potenciálny počet účastníkov a rozhodli sme sa, že potrebujeme aspoň 5 nevybavených vydaní MVP, 5 produktov a 5 ľudí, ktorí budú pôsobiť ako vlastníci produktov, dešifrovať obchodné potreby a rozhodovať o obmedzeniach.
Tu je to, čo máme: .
Hlavnou myšlienkou bolo prísť s témami, ktoré boli čo najviac vzdialené od každodennej práce účastníkov a dať im priestor na tvorivý let fantázie.
Aké chyby sme urobili a čo by sme mohli urobiť lepšie?
Využitie hodnotiacich praktík, tak populárnych v oblasti najímania obchodníkov a nižších manažérov, si vyžiadalo obrovské množstvo úsilia, no neumožnilo nám venovať dostatočnú pozornosť každému účastníkovi a hodnotiť jeho schopnosti. Vo všeobecnosti táto možnosť výberu vytvára negatívny obraz o spoločnosti, keďže pomerne veľa ľudí dostáva nedostatočnú spätnú väzbu a následne v sebe a iných vytvárajú efekt tyranie zamestnávateľa (komunikácia v IT komunitách je veľmi rozvinutá). Tým pádom nám ostávajú doslova dvaja potenciálni kandidáti s veľmi vzdialenou budúcnosťou.
Stretnutia sú dobrá vec. Vytvára sa rozsiahly základ pre vypracovanie a zvyšuje sa všeobecná úroveň účastníkov. Spoločnosť je na trhu čoraz viditeľnejšia. Pracovná náročnosť takýchto podnikov však nie je malá. Musíte jasne pochopiť, že organizovanie stretnutí zaberie približne 700 – 800 človekohodín ročne.
Čo sa týka testovacieho hackathonu. Takéto podujatia sa ešte nestali nudnými, pretože na rozdiel od hackathonov pre vývojárov sa konajú oveľa menej často. Výhodou tohto nápadu je, že uvoľneným spôsobom si môžete vymeniť veľké množstvo praktických vedomostí a celkom presne určiť úroveň každého účastníka.
Po analýze výsledkov udalosti sme si uvedomili, že sme urobili veľa chýb:
- Najneodpustiteľnejšou chybou bolo veriť, že 4-5 hodín nám bude stačiť. Výsledkom bolo, že len predstavenie a oboznámenie sa s backlogmi trvalo takmer 2 hodiny.
Práca s vlastníkmi produktov v počiatočnej fáze a čas ponorenia sa do predmetnej oblasti trvali rovnako dlho. Zostávajúci čas teda zjavne nestačil na komplexný vývoj testovacích máp. - Na podrobnú spätnú väzbu ku každej mape nebolo dosť času a energie, keďže už bola noc. Preto sme túto časť jednoznačne zlyhali, ale pôvodne sme mali byť najhodnotnejšou v hackathone.
- Kvalitu vývoja sme sa rozhodli hodnotiť jednoduchým hlasovaním všetkých zúčastnených, pričom každému tímu sme pridelili 3 hlasy, ktoré mohli dať za najkvalitnejšiu prácu. Možno by bolo lepšie zorganizovať porotu.
čo ste dosiahli?
Čiastočne sme náš problém vyriešili a teraz u nás pracujú 4 statoční krásni muži, ktorí kryjú zadnú časť 4 vývojových tímov. Významná skupina potenciálnych silných kandidátov a hmatateľné zmeny na úrovni komunity QA v meste zatiaľ neboli zaznamenané. Ale je tu určitý pokrok a to sa nemôže len radovať.
Zdroj: hab.com