Zergatik egin genuen hackaton bat probatzaileentzat?

Artikulu hau interesgarria izango da, gu bezala, proben alorrean espezialista egokia hautatzeko arazoa dutenentzat.

Bitxia bada ere, gure errepublikan informatika-enpresen kopurua handituz doazen programatzaileen kopurua baino ez da handitzen, baina ez probatzaileak. Jende asko gogotsu dago lanbide honetan sartzeko, baina askok ez dute ulertzen haren esanahia.

Ezin dut IT enpresa guztientzat hitz egin, baina QA/QC rola esleitu diegu gure kalitateko espezialistei. Garapen-taldearen parte dira eta garapen-fase guztietan parte hartzen dute, ikerketatik hasi eta bertsio berri bat kaleratu arte.

Talde bateko probatzaileak, plangintza-fasean ere, erabiltzaile-istorio bat onartzeko baldintza funtzional eta ez-funtzional guztiak pentsatu behar ditu. Produktuaren ezaugarri operatiboak zein programatzaileak ulertu behar ditu, eta are hobeto, eta taldeari plangintza-fasean ere erabaki okerrak hartzen lagundu behar du. Probatzaileak argi izan behar du inplementatutako funtzionalitateak nola funtzionatuko duen eta zer hutsune egon daitezkeen. Gure probalariek proba-planak eta proba-kasuak eurek sortzen dituzte, baita beharrezko proba-banku guztiak prestatzen ere. Tximino klikatzailea bezalako prest egindako zehaztapen baten arabera probatzea ez da gure aukera. Taldean lan eginez, merezi duen produktu bat askatzen lagundu behar du eta zerbait gaizki gertatzen bada alarma jo behar du garaiz.

Tester bilatzean topatu genuena

Curriculum asko aztertzeko fasean, bazirudien guretzako esperientzia egokia zuten espezialistak zeudela eta gure talderako probatzaile bat aukeratzeko arazorik ez zela egongo. Baina, bilera pertsonaletan, gero eta gehiago topatu genituen informazio teknologien mundutik nahiko urrun zeuden hautagaiak (adibidez, ezin zituzten kontatu arakatzaile baten eta web zerbitzari baten arteko elkarrekintzaren printzipioak, segurtasunaren oinarriak, erlazionalak eta ez-zerbitzariak). datu-base erlazionalak, birtualizazioari eta edukiontziei buruz ideiarik ez zuten), baina, aldi berean, beren burua ebaluatu zuten Senior QA mailan. Dozenaka elkarrizketa egin ostean, eskualdean guretzat egokia den espezialista kopurua arbuiagarria dela ondorioztatu genuen.

Jarraian, zer pauso eman ditugun eta zein akats zapaldu ditugun kontatuko dizuet aspaldiko itxaroten diren borrokalari horiek kalitatearen bila.

Nola saiatu ginen egoera konpontzen

Prestatutako espezialistak eskuratzearekin agortuta, inguruko eremuetara bideratzen hasi ginen:

1. Ebaluazio-praktikak aplikatzen saiatu gara "utzi" pertsona askoren artean identifikatzeko, zeinetatik espezialista sendoak gara ditzakegun.

   Gutxi gorabehera ezagutza maila bera duten hautagai potentzial talde bati zereginak burutzeko eskatu genion. Haien pentsamendu prozesua ikusita, hautagairik itxaropentsuena identifikatzen saiatu gara.

   Hain zuzen ere, arreta, teknologiaren gaitasunak eta kulturaniztasunaren ezaugarriak ulertzea probatzeko zereginak egin genituen:

   
   

2. Testerentzako topaketak egin genituen lanbidearen ulermenaren mugak lehendik zegoen kontingenteen artean zabaltzeko.

   Horietako bakoitzari buruz pixka bat kontatuko dizuet.

   Ufa Software QA eta Testing Meetup #1 lanbidea zaintzen dutenak biltzeko gure lehen saiakera da eta, aldi berean, publikoari helarazi nahi diegunarekin interesatuko ote den ulertzeko. Funtsean, gure txostenak nondik hobe zen hastea probatzaile izatea erabaki baduzu. Lagundu hasiberriei begiak irekitzen eta heldu baten moduan aztertzen. Lanbidean sartzeko probalari hasiberriek eman behar dituzten urratsei buruz hitz egin dugu. Kalitatea zer den eta nola lortu baldintza errealetan. Eta, gainera, zer den proba automatikoa eta non den egokiagoa erabiltzea.

   
   
   Gero, 1-2 hilabeteko tartearekin, beste bi bilera egin genituen. Dagoeneko bikoiztu ziren parte hartzaile gehiago. "Ufa Software QA and Testing Meetup #2"-n, gai-eremuan sakondu genuen. Akatsen jarraipen-sistemei, UI/UX probei buruz hitz egin zuten, Docker, Ansible-ri buruz hitz egin zuten, eta garatzaile baten eta probatzaile baten arteko gatazka posibleez eta horiek konpontzeko moduez ere hitz egin zuten.

   Gure hirugarren bilera, "Ufa Software QA and Testing Meetup # 3", zeharka probatzaileen lanarekin erlazionatuta zegoen, baina erabilgarria izan zen programatzaileei beren eginkizun teknikoak eta antolakuntzak garaiz gogoratzeko: karga-probak, e2e probak, Selenium autotestetan, web aplikazioen ahultasunak. .

   Denbora honetan guztian, gure ekitaldietako emankizunetan argia eta soinu normalak nola sortzen diren ikasten aritu gara:

   → Probetan lehen urratsak - Ufa Software QA eta Testing Meetup #1
   → UI/UX probak - Ufa Software QA eta Testing Meetup #2
   → Segurtasun-probak, karga-probak eta auto-probak - Ufa QA eta Testing Meetup #3

3. Eta azkenean probalarientzako hackaton bat egiten saiatzea erabaki genuen

Nola prestatu eta egin genuen probatzaileentzako hackaton bat

Hasteko, zer nolako “piztia” den eta nola gauzatu ohi den ulertzen saiatu gara. Gertatu zenez, mota honetako ekitaldiak ez dira askotan egin Errusiako Federazioan, eta ez dago ideiak maileguan hartzeko. Bigarrenik, ez nuen berehala baliabide asko inbertitu nahi lehen begiratuan zalantzazkoa zirudien gertaera batean. Hori dela eta, mini-hackathon laburrak egingo genituela erabaki genuen, ez QA lan-ziklo osorako, etapa indibidualetarako baizik.

Gure buruhauste nagusia tokiko probatzaileen artean probaren mapa argiak sortzeko praktika falta da. Ez dute denborarik ematen inplementazio aurreko erabiltzaileen istorioak ikertzen eta garatzaileentzat argiak diren eskakizun funtzionalak eta ez-funtzionalak, UI/UX, segurtasuna, lan-kargak eta karga gailurrak dituzten onarpen-irizpideak sortzen. Hori dela eta, erabaki genuen, lehen aldiz, haien lanaren zatirik interesgarri eta sortzaileena igarotzea: proiektuaren aurreko ikerketan eskakizunen azterketa eta eratzea.

Parte-hartzaileen kopuru potentziala kalkulatu genuen eta erabaki genuen gutxienez 5 atzerapen behar genituela MVP-ren kaleratzeetarako, 5 produktu eta produktuen jabe gisa jardungo zuten 5 pertsona, negozio beharrak deszifratu eta murrizketei buruzko erabakiak hartuko zituztenak.

Hona hemen lortu duguna: hackatonerako atzerapenak.

Parte-hartzaileen eguneroko lanetik ahalik eta urrunen zeuden gaiak planteatzea zen ideia nagusia eta irudimenaren sormen hegaldiari aukera ematea.

Zein akats egin ditugu eta zer hobetu genezake?

Saltzaileak eta behe-mailako kudeatzaileak kontratatzeko alorrean hain ezagunak diren ebaluazio-praktiken erabilerak esfortzu handia behar zuen, baina ez zigun utzi parte-hartzaile bakoitzari behar besteko arreta jarri eta bere gaitasunak ebaluatzeko. Oro har, hautaketa-aukera honek enpresaren irudi negatiboa sortzen du, jende askok ez baitu iritzi nahikorik jasotzen eta, ondoren, bere baitan eta besteengan enpresariaren tiraniaren eragina sortzen du (informatika komunitateetan komunikazioak oso garatuta daude). Ondorioz, etorkizun oso urruneko bi hautagai potentzial geratzen zaizkigu literalki.

Topaketak gauza ona dira. Elaboratzeko oinarri zabala sortzen da, eta parte-hartzaileen maila orokorra handitzen da. Konpainia gero eta ezagunagoa da merkatuan. Baina horrelako enpresen lan-intentsitatea ez da txikia. Argi eta garbi ulertu behar duzu bilerak egiteak urtean 700-800 gizon-ordu beharko dituela gutxi gorabehera.

Proba hackatonari dagokionez. Mota honetako ekitaldiak ez dira oraindik aspergarriak bihurtu, izan ere, garatzaileentzako hackath-ak ez bezala, askoz ere gutxiago egiten dira. Ideia honen abantaila da modu lasai batean ezagutza praktiko ugari trukatu ditzakezula eta parte-hartzaile bakoitzaren maila nahiko zehatz zehaztea.

Ekitaldiaren emaitzak aztertu ondoren, akats asko egin genituela konturatu ginen:

1. Akats barkaezina guretzat 4-5 ordu nahikoa izango zirela sinistea izan zen. Ondorioz, ia 2 ordu behar izan zituen sarrerak eta ezagutzeak.
   Produktu-jabeekin hasierako fasean lan egiteak eta gai-arloan murgiltzeko denbora denbora bera behar izan zuen. Beraz, geratzen den denbora ez zen nahikoa proba-mapen garapen integralerako.
2. Ez zegoen denbora eta energia nahikoa mapa bakoitzean iritzi zehatzak egiteko, gaua baitzen jada. Hori dela eta, argi eta garbi porrot egin genuen zati hau, baina hasiera batean hackatoian baliotsuena izatea zen asmoa.
3. Garapenaren kalitatea parte hartzaile guztien boto soil baten bidez ebaluatzea erabaki genuen, talde bakoitzari 3 boto banatuz, kalitate goreneko lanerako eman zezaketenak. Agian hobe litzateke epaimahai bat antolatzea.

Zer lortu duzu?

Gure arazoa partzialki konpondu dugu eta orain 4 gizon ausart eta eder ditugu lanean, 4 garapen-talderen atzealdea estaltzen. Hautagai indartsu potentzialen sorta esanguratsua eta hiriko QA komunitatearen mailan aldaketa nabariak ez dira oraindik nabaritu. Baina aurrerapen batzuk daude eta honek ezin du poztu.

Iturria: www.habr.com