Dit artikel sil fan belang wêze foar dyjingen dy't, lykas ús, te krijen hawwe mei it probleem fan it selektearjen fan in gaadlike spesjalist op it mêd fan testen.
Frjemd genôch, mei it tanimmen fan it oantal IT-bedriuwen yn ús republyk, nimt allinich it oantal weardige programmeurs ta, mar net testers. In protte minsken binne entûsjast te krijen yn dit berop, mar net folle begripe de betsjutting.
Ik kin net prate foar alle IT bedriuwen, mar wy hawwe tawiisd de rol fan QA / QC oan ús kwaliteit spesjalisten. Se meitsje diel út fan it ûntwikkelingsteam en dogge mei oan alle stadia fan ûntwikkeling, fan ûndersyk oant de frijlitting fan in nije ferzje.
In tester yn in team, sels yn 'e planningstadium, moat alle funksjonele en net-funksjonele easken neitinke foar it akseptearjen fan in brûkersferhaal. Hy moat begripe de operasjonele skaaimerken fan it produkt likegoed as programmeurs, en noch better, en helpe it team net meitsje ferkearde besluten sels yn de planning stadium. De tester moat in dúdlik begryp hawwe fan hoe't de ymplementearre funksjonaliteit sil wurkje en hokker falkûlen d'r kinne wêze. Us testers meitsje sels testplannen en testgefallen, en meitsje ek alle nedige testbanken tariede. Testen neffens in klear makke spesifikaasje lykas in aapklikker is net ús opsje. Wurkjen binnen it team moat hy helpe om in weardich produkt frij te litten en op 'e tiid alarm te slaan as der wat mis giet.
Wat wy tsjinkamen by it sykjen nei testers
Op it poadium fan it studearjen fan in protte cv's, like it dat d'r spesjalisten wiene mei passende ûnderfining foar ús en d'r soe gjin problemen wêze mei it kiezen fan in tester foar ús team. Mar, tidens persoanlike gearkomsten, kamen wy hieltyd faker kandidaten tsjin dy't eins frij fier fan 'e wrâld fan ynformaasjetechnology wiene (se koenen bygelyks de prinsipes fan ynteraksje tusken in browser en in webserver net fertelle, de basis fan feiligens, relaasje en net- relational databases, se hiene gjin idee oer virtualisaasje en containerization), mar tagelyk beoardiele harsels op de Senior QA nivo. Nei it hâlden fan tsientallen ynterviews kamen wy ta de konklúzje dat it tal spesjalisten dat geskikt is foar ús yn 'e regio te ferwaarlozen is.
Folgjende sil ik jo fertelle hokker stappen wy namen en hokker flaters wy stapten om dy langverwachte fjochters foar kwaliteit te finen.
Hoe't wy besochten de situaasje te reparearjen
Nei't wy ússels útput hawwe mei it keapjen fan klearmakke spesjalisten, begon wy te rjochtsjen op gebieten yn 'e buert:
- Wy besochten beoardielingspraktiken ta te passen om te identifisearjen ûnder de protte "leave-it" minsken, dejingen fan wa't wy sterke spesjalisten kinne ûntwikkelje.
Wy fregen in groep potinsjele kandidaten mei sawat itselde nivo fan kennis om taken te foltôgjen. Observearjen fan har gedachteproses, hawwe wy besocht de meast kânsrike kandidaat te identifisearjen.
Yn it bysûnder, wy kamen mei taken te testen oandacht, begryp fan de mooglikheden fan technology en de funksjes fan multikulturalisme:
- Wy holden gearkomsten foar testers om de grinzen fan begryp fan it berop út te wreidzjen ûnder de besteande kontingint.
Ik sil jo in bytsje fertelle oer elk fan har.
Ufa Software QA en Testing Meetup #1 is ús earste besykjen om dejingen te sammeljen dy't soarchje oer it berop en tagelyk te begripen oft it publyk ynteressearre sil wêze yn wat wy har oerbringe wolle. Yn prinsipe wiene ús rapporten oer wêr't it better is om te begjinnen as jo besletten hawwe om in tester te wurden. Help begjinners har eagen te iepenjen en te sjen nei testen as in folwoeksene. Wy prate oer de stappen dy't begjinnende testers moatte nimme om mei te dwaan oan it berop. Oer wat kwaliteit is en hoe te berikken it yn echte omstannichheden. En ek, wat is automatyske testen en wêr't it passend is om it te brûken.
Dan, mei in ynterval fan 1-2 moannen, hawwe wy noch twa gearkomsten hâlden. Der wiene al twa kear safolle dielnimmers. By "Ufa Software QA and Testing Meetup #2" dûke wy djipper yn it ûnderwerpgebiet. Se praatten oer bug-trackingsystemen, UI / UX-testen, troffen Docker, Ansible oan, en praatten ek oer mooglike konflikten tusken in ûntwikkelder en in tester en manieren om se op te lossen.Us tredde gearkomste, "Ufa Software QA and Testing Meetup #3," yndirekt relatearre oan it wurk fan testers, mar wie nuttich om programmeurs op 'e tiid te herinnerjen oan har technyske en organisatoaryske taken: loadtesten, e2e-testen, Selenium yn autotesten, kwetsberens foar webapplikaasjes .
Al dy tiid hawwe wy leard hoe't jo normaal ljocht en lûd kinne meitsje yn útstjoerings fan ús eveneminten:
→
→
→ - En op it lêst hawwe wy besletten om te besykjen in hackathon te hâlden foar testers
Hoe't wy in hackathon foar testers tariede en fierden
Om te begjinnen, wy besocht te begripen hokker soarte fan "beest" dit is en hoe't it wurdt meastal útfierd. Sa die bliken, eveneminten fan dit soarte binne net in protte kearen hâlden yn 'e Russyske Federaasje, en d'r is nearne om ideeën te lienen. As twadde woe ik net fuortendaliks in protte middels ynvestearje yn in evenemint dat op it earste each dubieuze like. Dêrom hawwe wy besletten dat wy koarte mini-hackathons soene dwaan, net foar de hiele QA-wurksyklus, mar foar yndividuele stadia.
Us wichtichste hoofdpijn is it gebrek oan praktyk ûnder lokale testers by it meitsjen fan dúdlike testkaarten. Se besteegje gjin tiid oan it ûndersiikjen fan brûkersferhalen foar pre-ymplemintaasje en it meitsjen fan akseptaasjekritearia dy't dúdlik binne foar ûntwikkelders foar funksjonele en net-funksjonele easken, UI / UX, feiligens, workloads en peakloads. Dêrom besleaten wy foar it earst it meast nijsgjirrige en kreative diel fan har wurk troch te gean - analyze en formaasje fan easken tidens pre-projektûndersyk.
Wy skatte it potinsjele oantal dielnimmers en besletten dat wy nedich op syn minst 5 efterstân foar MVP releases, 5 produkten en 5 minsken dy't soe fungearje as produkt eigners, ûntsiferje saaklike behoeften en meitsje besluten oer beheinings.
Hjir is wat wy krigen: .
It haadgedachte wie om ûnderwerpen te betinken dy't sa fier mooglik fan alle deistige wurksumheden fan de dielnimmers ôfstutsen en harren romte te jaan foar in kreatyf ferbyldingsflecht.
Hokker flaters hawwe wy makke en wat kinne wy better dwaan?
It brûken fan beoardielingspraktiken, sa populêr op it mêd fan it ynhieren fan ferkeapers en managers op legere nivo, koste in enoarme ynspanning, mar liet ús net genôch omtinken jaan oan elke dielnimmer en evaluearje syn kapasiteiten. Yn 't algemien makket dizze seleksjeopsje in negatyf byld fan it bedriuw, om't in protte minsken net genôch feedback krije en dêrnei yn harsels en oaren it effekt fan tiranny fan' e wurkjouwer meitsje (kommunikaasje yn IT-mienskippen binne tige ûntwikkele). As gefolch hawwe wy letterlik twa potinsjele kandidaten oer mei in heul fiere takomst.
Meetups binne in goede saak. In wiidweidige basis foar útwurking wurdt makke, en it algemiene nivo fan de dielnimmers nimt ta. It bedriuw wurdt hieltyd mear werkenber yn de merk. Mar de arbeidsintensiteit fan sokke bedriuwen is net lyts. Jo moatte dúdlik begripe dat it hâlden fan gearkomsten sawat 700-800 manoeren per jier sil nimme.
Wat de test-hackathon oanbelanget. Dit soarte fan eveneminten binne noch net saai wurden, om't se, yn tsjinstelling ta hackathons foar ûntwikkelders, folle minder faak wurde hâlden. It foardiel fan dit idee is dat jo op in ûntspannen manier in grutte hoemannichte praktyske kennis kinne útwikselje en it nivo fan elke dielnimmer frij sekuer bepale.
Nei it analysearjen fan de resultaten fan it evenemint, realisearre wy dat wy in protte flaters makken:
- De meast ûnferjitlike flater wie te leauwen dat 4-5 oeren genôch wêze soe foar ús. Dêrtroch duorre allinnich de yntroduksje en fertroudmaking mei de efterstân hast 2 oeren.
Wurkje mei produkteigners yn 'e earste faze en tiid om te dûken yn it fakgebiet naam deselde tiid. Sa wie de oerbleaune tiid dúdlik net genôch foar in wiidweidige ûntwikkeling fan de testkaarten. - D'r wie net genôch tiid en enerzjy foar detaillearre feedback op elke kaart, om't it al nacht wie. Dêrom hawwe wy dit diel dúdlik mislearre, mar wie yn earste ynstânsje bedoeld om de meast weardefolle te wêzen yn 'e hackathon.
- Wy besletten om de kwaliteit fan ûntwikkeling te evaluearjen troch in ienfâldige stimming fan alle dielnimmers, it tawizen fan 3 stimmen foar elk team, dy't se kinne jaan foar wurk fan 'e heechste kwaliteit. Miskien soe it better wêze om in sjuery te organisearjen.
Wat hawwe jo berikt?
Wy hawwe ús probleem foar in part oplost en no hawwe wy 4 dappere, knappe manlju dy't foar ús wurkje, dy't de efterkant fan 4 ûntwikkelingsteams dekke. In wichtige pool fan potinsjele sterke kandidaten en taastbere feroaringen yn it nivo fan 'e QA-mienskip fan' e stêd binne noch net opmurken. Mar d'r is wat foarútgong en dit kin net oars as bliid wêze.
Boarne: www.habr.com