Šis straipsnis bus įdomus tiems, kurie, kaip ir mes, susiduria su tinkamo specialisto pasirinkimo testavimo srityje problema.
Kad ir kaip būtų keista, mūsų respublikoje daugėjant IT įmonių, daugėja tik vertų programuotojų, bet ne testuotojų. Daugelis žmonių nori įgyti šią profesiją, tačiau mažai kas supranta jos prasmę.
Negaliu kalbėti už visas IT įmones, bet kokybės užtikrinimo/kokybės kontrolės vaidmenį priskyrėme savo kokybės specialistams. Jie yra kūrimo komandos dalis ir dalyvauja visuose kūrimo etapuose – nuo tyrimų iki naujos versijos išleidimo.
Testuotojas komandoje net planavimo etape turi apgalvoti visus funkcinius ir nefunkcinius reikalavimus, kad priimtų vartotojo istoriją. Jis turi suprasti produkto eksploatacines ypatybes ir programuotojus, o dar geriau ir padėti komandai nepriimti klaidingų sprendimų net planavimo etape. Testuotojas turi aiškiai suprasti, kaip veiks įdiegta funkcija ir kokios gali būti spąstų. Mūsų testuotojai patys sukuria bandymų planus ir testavimo atvejus, taip pat paruošia visus reikiamus bandymų stendus. Testavimas pagal paruoštas specifikacijas, pavyzdžiui, beždžionių spustelėjus, nėra mūsų pasirinkimas. Dirbdamas komandoje, jis turi padėti išleisti vertą produktą ir laiku įspėti, jei kas nors negerai.
Su kuo susidūrėme ieškodami bandytojų
Daugelio gyvenimo aprašymų studijavimo etape atrodė, kad yra mums tinkamos patirties turinčių specialistų ir nebus jokių problemų renkantis testerį mūsų komandai. Tačiau asmeninių susitikimų metu vis dažniau susidurdavome su kandidatais, kurie iš tikrųjų buvo gana toli nuo informacinių technologijų pasaulio (pavyzdžiui, jie negalėjo nupasakoti naršyklės ir žiniatinklio serverio sąveikos principų, saugumo, reliacinių ir ne reliacinės duomenų bazės, jie neturėjo supratimo apie virtualizavimą ir konteinerizavimą), tačiau tuo pat metu įvertino save vyresniojo kokybės užtikrinimo lygiu. Atlikę dešimtis interviu padarėme išvadą, kad regione mums tinkamų specialistų yra nežymiai.
Toliau papasakosiu, kokių žingsnių ėmėmės ir kokias klaidas padarėme, kad rastume tuos ilgai lauktus kovotojus už kokybę.
Kaip bandėme taisyti situaciją
Išnaudoję save paruoštų specialistų įsigijimu, pradėjome taikytis į netoliese esančias sritis:
- Bandėme taikyti vertinimo praktiką, kad tarp daugybės „palikti“ žmonių būtų atpažinti tie, iš kurių galime išugdyti stiprius specialistus.
Atlikti užduotis paprašėme grupės potencialių kandidatų, turinčių maždaug tokį patį žinių lygį. Stebėdami jų mąstymo procesą, bandėme nustatyti perspektyviausią kandidatą.
Visų pirma, mes sugalvojome užduotis, kad patikrintume dėmesingumą, technologijų galimybių ir daugiakultūriškumo ypatybių supratimą:
- Surengėme testuotojų susitikimus, siekdami išplėsti esamo kontingento supratimo apie profesiją ribas.
Aš jums šiek tiek papasakosiu apie kiekvieną iš jų.
Ufa Software QA and Testing Meetup #1 – tai pirmasis mūsų bandymas suburti tuos, kuriems ši profesija rūpi, ir tuo pačiu suprasti, ar visuomenei bus įdomu tai, ką norime jiems perteikti. Iš esmės mūsų ataskaitos buvo apie tai, nuo ko geriau pradėti, jei nusprendėte tapti bandytoju. Padėkite pradedantiesiems atmerkti akis ir žiūrėti į testavimą kaip suaugusiems. Kalbėjome apie žingsnius, kuriuos turi atlikti pradedantieji bandytojai, norintys prisijungti prie šios profesijos. Apie tai, kas yra kokybė ir kaip ją pasiekti realiomis sąlygomis. Taip pat, kas yra automatinis testavimas ir kur jį tikslingiau naudoti.
Tada su 1-2 mėnesių intervalu surengėme dar du susitikimus. Dalyvių jau buvo dvigubai daugiau. „Ufa Software QA and Testing Meetup Nr. 2“ mes gilinomės į dalykinę sritį. Jie kalbėjo apie klaidų sekimo sistemas, UI/UX testavimą, palietė Docker, Ansible, taip pat kalbėjo apie galimus konfliktus tarp kūrėjo ir testuotojo bei būdus, kaip juos išspręsti.Trečiasis mūsų susitikimas „Ufa Software QA and Testing Meetup #3“ buvo netiesiogiai susijęs su testuotojų darbu, tačiau buvo naudingas programišiams laiku priminti apie jų technines ir organizacines pareigas: apkrovos testavimą, e2e testavimą, seleną automatiniame testavime, žiniatinklio programų pažeidžiamumus. .
Visą šį laiką mokėmės, kaip sukurti normalią šviesą ir garsą savo renginių transliacijose:
→
→
→ - Ir galiausiai nusprendėme pabandyti surengti hakatoną testuotojams
Kaip ruošėmės ir vedėme hakatoną testuotojams
Pirmiausia bandėme suprasti, koks tai „žvėris“ ir kaip tai paprastai atliekama. Kaip paaiškėjo, Rusijos Federacijoje tokio pobūdžio renginiai nebuvo daug kartų, o idėjų pasiskolinti nėra kur. Antra, nenorėjau iš karto investuoti daug resursų į renginį, kuris iš pirmo žvilgsnio atrodė abejotinas. Todėl nusprendėme, kad trumpus mini hakatonus darysime ne visam QA darbo ciklui, o atskiriems etapams.
Pagrindinis mūsų galvos skausmas yra vietinių bandytojų praktikos trūkumas kuriant aiškius testavimo žemėlapius. Jie negaišta laiko tyrinėdami naudotojų istorijas prieš įdiegimą ir kurdami pripažinimo kriterijus, kurie kūrėjams būtų aiškūs dėl funkcinių ir nefunkcinių reikalavimų, vartotojo sąsajos / UX, saugumo, darbo krūvių ir didžiausių apkrovų. Todėl pirmą kartą nusprendėme atlikti įdomiausią ir kūrybiškiausią jų darbo dalį – analizę ir reikalavimų formavimą priešprojektinio tyrimo metu.
Apskaičiavome galimą dalyvių skaičių ir nusprendėme, kad mums reikia mažiausiai 5 MVP leidimų atsilikimų, 5 produktų ir 5 žmonių, kurie veiktų kaip produktų savininkai, iššifruotų verslo poreikius ir priimtų sprendimus dėl apribojimų.
Štai ką mes gavome: .
Pagrindinė mintis buvo sugalvoti temas, kurios būtų kuo labiau nutolusios nuo visų dalyvių kasdienių darbų ir suteikti erdvės kūrybiniam vaizduotės polėkiui.
Kokias klaidas padarėme ir ką galėtume padaryti geriau?
Vertinimo praktikos, taip populiarios pardavėjų ir žemesnio lygio vadovų samdymo srityje, taikymas pareikalavo didžiulių pastangų, tačiau neleido skirti pakankamai dėmesio kiekvienam dalyviui ir įvertinti jo gebėjimus. Apskritai toks atrankos variantas sukuria neigiamą įmonės įvaizdį, nes gana daug žmonių sulaukia nepakankamo grįžtamojo ryšio ir vėliau sukuria darbdavio tironijos efektą savyje ir kituose (komunikacijos IT bendruomenėse yra labai išvystytos). Dėl to mums liko du potencialūs kandidatai, kurių ateitis labai toli.
Susitikimai yra geras dalykas. Sukuriamas platus tobulinimų pagrindas, pakyla bendras dalyvių lygis. Įmonė vis labiau atpažįstama rinkoje. Tačiau tokių įmonių darbo intensyvumas nėra mažas. Turite aiškiai suprasti, kad susitikimų organizavimas užtruks maždaug 700–800 darbo valandų per metus.
Kalbant apie testavimo hakatoną. Tokie renginiai dar nepasidarė nuobodūs, nes, skirtingai nei kūrėjams skirti hakatonai, jie vyksta daug rečiau. Šios idėjos privalumas yra tas, kad atsipalaidavus galite apsikeisti daugybe praktinių žinių ir gana tiksliai nustatyti kiekvieno dalyvio lygį.
Išanalizavę renginio rezultatus supratome, kad padarėme daug klaidų:
- Labiausiai nedovanotina klaida buvo tikėjimas, kad mums užteks 4-5 valandų. Dėl to vien susipažinimas ir susipažinimas su atsilikimais užtruko beveik 2 valandas.
Darbas su produktų savininkais pradiniame etape ir laikas pasinerti į dalykinę sritį užtruko tiek pat laiko. Taigi likusio laiko aiškiai nepakako visapusiškam testavimo žemėlapių kūrimui. - Neužteko laiko ir jėgų išsamiam atsiliepimui apie kiekvieną žemėlapį, nes jau buvo naktis. Todėl ši dalis mums akivaizdžiai nepavyko, bet iš pradžių buvo numatyta kaip vertingiausia hakatone.
- Kūrimo kokybę nusprendėme įvertinti paprastu visų dalyvių balsavimu, kiekvienai komandai skirdami po 3 balsus, kuriuos jie galėtų atiduoti už kokybiškiausią darbą. Galbūt geriau būtų suorganizuoti žiuri.
Ką tu pasiekei?
Iš dalies išsprendėme savo problemą ir dabar pas mus dirba 4 drąsūs, gražūs vyrai, kurie dengia 4 kūrėjų komandų užnugarį. Didelis potencialių stiprių kandidatų skaičius ir apčiuopiami miesto kokybės užtikrinimo bendruomenės lygio pokyčiai dar nepastebėti. Tačiau yra tam tikra pažanga, ir tai gali tik džiaugtis.
Šaltinis: www.habr.com