See artikkel pakub huvi neile, kes, nagu meiegi, seisavad silmitsi testimisvaldkonnas sobiva spetsialisti valimise probleemiga.
Kummalisel kombel suureneb IT-ettevõtete arvu kasvuga meie vabariigis ainult väärt programmeerijate arv, kuid mitte testijate arv. Paljud inimesed soovivad sellele erialale asuda, kuid vähesed ei mõista selle tähendust.
Ma ei saa rääkida kõigi IT-ettevõtete eest, kuid oleme andnud QA/QC rolli oma kvaliteedispetsialistidele. Nad on osa arendusmeeskonnast ja osalevad kõigis arendusetappides alates uurimistööst kuni uue versiooni väljaandmiseni.
Meeskonnas olev testija peab juba planeerimisetapis läbi mõtlema kõik funktsionaalsed ja mittefunktsionaalsed nõuded kasutajaloo vastuvõtmiseks. Ta peab mõistma nii toote tööomadusi kui ka programmeerijaid ja veelgi paremini ning aitama meeskonnal mitte teha valesid otsuseid juba planeerimisetapis. Testijal peab olema selge arusaam, kuidas rakendatud funktsionaalsus töötab ja millised lõksud võivad olla. Meie testijad koostavad ise katseplaane ja katsejuhtumeid, samuti valmistavad ette kõik vajalikud katsestendid. Valmis spetsifikatsiooni järgi testimine nagu ahvikliker ei ole meie valik. Meeskonnas töötades peab ta aitama välja anda väärt toote ja andma õigel ajal häirekella, kui midagi läheb valesti.
Millega me testijaid otsides kokku puutusime
Paljude CV-de õppimise staadiumis tundus, et meile sobiva kogemusega spetsialistid on olemas ja meie meeskonda testija valikuga probleeme ei teki. Kuid isiklikel kohtumistel kohtasime üha enam kandidaate, kes olid infotehnoloogia maailmast tegelikult üsna kaugel (näiteks ei osanud öelda brauseri ja veebiserveri interaktsiooni põhimõtteid, turvalisuse põhitõdesid, relatsiooni- ja mitte-). relatsiooniandmebaasid, neil polnud aimugi virtualiseerimisest ja konteineriseerimisest), kuid samal ajal hindasid nad end Senior QA tasemel. Pärast kümnete intervjuude läbiviimist jõudsime järeldusele, et meile sobivate spetsialistide arv piirkonnas on tühine.
Järgmisena räägin teile, milliseid samme astusime ja milliseid vigu tegime, et leida need kauaoodatud kvaliteedi eest võitlejad.
Kuidas me püüdsime olukorda parandada
Olles ammendanud end valmis spetsialistide hankimisega, hakkasime sihtima lähipiirkondi:
- Püüdsime rakendada hindamispraktikaid, et tuvastada paljude "jätke" inimeste hulgast just need, kellest saame välja arendada tugevad spetsialistid.
Palusime ülesandeid täitma grupil potentsiaalseid kandidaate, kellel on ligikaudu sama teadmiste tase. Nende mõttekäiku jälgides püüdsime välja selgitada kõige lootustandvama kandidaadi.
Eelkõige mõtlesime välja ülesanded, et testida tähelepanelikkust, arusaamist tehnoloogia võimalustest ja multikultuursuse tunnustest:
- Korraldasime testijatele kohtumisi, et laiendada olemasoleva kontingendi eriala mõistmise piire.
Ma räägin teile neist igaühe kohta veidi.
Ufa Software QA and Testing Meetup #1 on meie esimene katse koguda kokku need, kes hoolivad sellest erialast ja samal ajal mõista, kas avalikkus on huvitatud sellest, mida me neile edastada tahame. Põhimõtteliselt olid meie aruanded selle kohta, kust on parem alustada, kui olete otsustanud testijaks hakata. Aidake algajatel silmad avada ja vaadata testimist nagu täiskasvanud. Rääkisime sammudest, mida algajad testijad peavad tegema, et erialaga liituda. Sellest, mis on kvaliteet ja kuidas seda reaalsetes tingimustes saavutada. Ja ka, mis on automaattestimine ja kus on seda sobivam kasutada.
Seejärel pidasime 1-2-kuulise vahega veel kaks kokkusaamist. Osalejaid oli juba kaks korda rohkem. „Ufa tarkvara kvaliteedi tagamise ja testimise kohtumisel nr 2” sukeldusime teemavaldkonda sügavamale. Räägiti vigade jälgimise süsteemidest, UI/UX testimisest, puudutati Dockerit, Ansible’i ning räägiti ka võimalikest konfliktidest arendaja ja testija vahel ning nende lahendamise viisidest.Meie kolmas kohtumine “Ufa Software QA and Testing Meetup #3” oli kaudselt seotud testijate tööga, kuid oli kasulik, et tuletada programmeerijatele õigeaegselt meelde nende tehnilisi ja korralduslikke kohustusi: koormustestimine, e2e testimine, seleen automaattestis, veebirakenduste haavatavused. .
Kogu selle aja oleme õppinud oma ürituste ülekannetes normaalset valgust ja heli looma:
→
→
→ - Ja lõpuks otsustasime proovida läbi viia testijatele häkatoni
Kuidas valmistasime ette ja viisime läbi testijatele mõeldud häkatoni
Alustuseks püüdsime aru saada, milline "metsaline" see on ja kuidas seda tavaliselt tehakse. Nagu selgus, pole sedalaadi üritusi Vene Föderatsioonis palju korraldatud ja ideid pole kusagilt laenata. Teiseks ei tahtnud ma esmapilgul kahtlasena tundunud sündmusesse kohe palju ressursse investeerida. Seetõttu otsustasime, et teeme lühikesi mini-hackathone mitte kogu QA töötsükli, vaid üksikute etappide kaupa.
Meie peamiseks peavaluks on kohalike testijate vähene praktika selgete testimiskaartide loomisel. Nad ei kuluta aega juurutuseelsete kasutajalugude uurimisele ja vastuvõtmise kriteeriumide loomisele, mis on arendajatele selged funktsionaalsete ja mittefunktsionaalsete nõuete, kasutajaliidese/UX-i, turvalisuse, töökoormuse ja tippkoormuse kohta. Seetõttu otsustasime esimest korda läbida nende töö kõige huvitavama ja loomingulisema osa – analüüsi ja nõuete kujundamise projektieelse uurimistöö käigus.
Hindasime potentsiaalset osalejate arvu ja otsustasime, et vajame MVP väljaannete jaoks vähemalt 5 mahajäämust, 5 toodet ja 5 inimest, kes tegutseksid tooteomanikena, dešifreeriksid ärivajadusi ja langetaksid piiranguid puudutavaid otsuseid.
Siin on, mida saime: .
Peamine idee oli välja mõelda teemad, mis oleksid võimalikult kaugel kõigist osalejate igapäevatööst ja anda neile ruumi loominguliseks kujutluslennuks.
Milliseid vigu me tegime ja mida saaksime paremini teha?
Müüjate ja madalama taseme juhtide palkamise vallas nii populaarsete hindamispraktikate kasutamine nõudis tohutut pingutust, kuid ei võimaldanud igale osalejale piisavalt tähelepanu pöörata ja tema võimeid hinnata. Üldiselt loob see valikuvõimalus ettevõttest negatiivse kuvandi, kuna üsna paljud inimesed saavad ebapiisavat tagasisidet ning tekitavad nii endas kui ka teistes tööandja türannia efekti (suhtlus IT-kogukondades on väga arenenud). Selle tulemusena jääb meile sõna otseses mõttes kaks potentsiaalset kandidaati, kelle tulevik on väga kauge.
Kohtumised on hea asi. Luuakse ulatuslik baas läbitöötamiseks ja tõuseb osalejate üldine tase. Ettevõte muutub turul üha tuntumaks. Kuid selliste ettevõtmiste töömahukus pole väike. Peate selgelt mõistma, et kohtumiste korraldamine võtab aastas umbes 700–800 töötundi.
Mis puutub testimise häkatoni. Sellised üritused pole veel igavaks muutunud, kuna erinevalt arendajatele mõeldud häkatonidest korraldatakse neid palju harvemini. Selle idee eeliseks on see, et saate pingevabalt vahetada suure hulga praktilisi teadmisi ja üsna täpselt määrata iga osaleja taseme.
Pärast ürituse tulemuste analüüsi saime aru, et tegime palju vigu:
- Kõige andestamatum viga oli uskuda, et meile piisab 4-5 tunnist. Sellest tulenevalt võttis ainuüksi tutvustamine ja mahajäämustega tutvumine aega peaaegu 2 tundi.
Algstaadiumis tooteomanikega töötamine ja teemasse sukeldumine võttis sama palju aega. Seega ei piisanud järelejäänud ajast selgelt testimiskaartide igakülgseks väljatöötamiseks. - Iga kaardi üksikasjalikuks tagasisideks ei jätkunud aega ja energiat, sest oli juba öö. Seetõttu kukkusime see osa selgelt läbi, kuid oli esialgu mõeldud häkatoni kõige väärtuslikumaks.
- Arengu kvaliteeti otsustasime hinnata kõigi osalejate lihthääletusega, jagades igale meeskonnale 3 häält, mille nad said anda kvaliteetseima töö eest. Võib-olla oleks õigem korraldada žürii.
Mida olete saavutanud?
Oleme oma probleemi osaliselt lahendanud ja nüüd töötab meie juures 4 vaprat, nägusat meest, kes katavad 4 arendusmeeskonna tagalat. Märkimisväärset potentsiaalsete tugevate kandidaatide kogumit ja käegakatsutavaid muutusi linna kvaliteedikontrolli kogukonna tasemel ei ole veel märgatud. Kuid mõningaid edusamme on tehtud ja see ei saa muud üle kui rõõmustada.
Allikas: www.habr.com