Ky artikull do të jetë me interes për ata që, si ne, përballen me problemin e zgjedhjes së një specialisti të përshtatshëm në fushën e testimit.
Mjaft e çuditshme, me rritjen e numrit të kompanive të IT në republikën tonë, rritet vetëm numri i programuesve të denjë, por jo testues. Shumë njerëz janë të etur për t'u futur në këtë profesion, por jo shumë e kuptojnë kuptimin e tij.
Nuk mund të flas për të gjitha kompanitë e IT-së, por ne ua kemi caktuar rolin e QA/QC specialistëve tanë të cilësisë. Ata janë pjesë e ekipit të zhvillimit dhe marrin pjesë në të gjitha fazat e zhvillimit, nga kërkimi deri te nxjerrja e një versioni të ri.
Një testues në një ekip, edhe në fazën e planifikimit, duhet të mendojë për të gjitha kërkesat funksionale dhe jofunksionale për të pranuar një histori përdoruesi. Ai duhet të kuptojë karakteristikat operacionale të produktit si dhe programuesit, madje edhe më mirë, dhe të ndihmojë ekipin të mos marrë vendime të gabuara edhe në fazën e planifikimit. Testuesi duhet të ketë një kuptim të qartë se si do të funksionojë funksionaliteti i zbatuar dhe çfarë grackash mund të ketë. Testuesit tanë krijojnë vetë planet e testimit dhe rastet e testimit, si dhe përgatisin të gjitha stolat e nevojshme të provës. Testimi sipas një specifikimi të gatshëm si një klikues majmuni nuk është opsioni ynë. Duke punuar brenda ekipit, ai duhet të ndihmojë në lëshimin e një produkti të denjë dhe të japë alarmin në kohë nëse diçka shkon keq.
Ajo që hasëm kur kërkonim testues
Në fazën e studimit të shumë rezymeve, dukej se kishte specialistë me përvojë të përshtatshme për ne dhe nuk do të kishte probleme me zgjedhjen e një testuesi për ekipin tonë. Por, gjatë takimeve personale, ne ndesheshim gjithnjë e më shumë me kandidatë që në fakt ishin mjaft larg botës së teknologjisë së informacionit (për shembull, ata nuk mund të tregonin parimet e ndërveprimit midis një shfletuesi dhe një serveri në internet, bazat e sigurisë, marrëdhëniet dhe jo- bazat e të dhënave relacionale, ata nuk kishin asnjë ide për virtualizimin dhe kontejnerizimin), por në të njëjtën kohë e vlerësuan veten në nivelin Senior QA. Pas kryerjes së dhjetëra intervistave, arritëm në përfundimin se numri i specialistëve të përshtatshëm për ne në rajon është i papërfillshëm.
Më pas do t'ju tregoj se çfarë hapash kemi marrë dhe në çfarë gabimesh kemi shkelur për të gjetur ata luftëtarët e shumëpritur për cilësi.
Si u përpoqëm ta rregullonim situatën
Pasi u lodhëm me burimin e specialistëve të gatshëm, filluam të synonim zonat e afërta:
- Ne u përpoqëm të zbatonim praktikat e vlerësimit për të identifikuar mes shumë njerëzve të “lënë-it”, pikërisht ata nga të cilët mund të zhvillojmë specialistë të fortë.
Ne i kërkuam një grupi kandidatësh potencialë me përafërsisht të njëjtin nivel njohurish për të përfunduar detyrat. Duke vëzhguar procesin e tyre të mendimit, ne u përpoqëm të identifikonim kandidatin më premtues.
Në veçanti, ne dolëm me detyra për të testuar vëmendjen, të kuptuarit e aftësive të teknologjisë dhe tiparet e multikulturalizmit:
- Ne mbajtëm takime për testuesit për të zgjeruar kufijtë e të kuptuarit të profesionit midis kontigjentit ekzistues.
Unë do t'ju tregoj pak për secilën prej tyre.
Ufa Software QA and Testing Meetup #1 është përpjekja jonë e parë për të mbledhur ata që kujdesen për profesionin dhe në të njëjtën kohë për të kuptuar nëse publiku do të jetë i interesuar për atë që ne duam t'u përcjellim. Në thelb, raportet tona kishin të bënin me atë se ku është më mirë të filloni nëse keni vendosur të bëheni testues. Ndihmojini fillestarët të hapin sytë dhe ta shikojnë testimin si të rritur. Ne folëm për hapat që testuesit fillestarë duhet të ndërmarrin për t'u bashkuar me profesionin. Se çfarë është cilësia dhe si ta arrijmë atë në kushte reale. Dhe gjithashtu, çfarë është testimi automatik dhe ku është më e përshtatshme për ta përdorur atë.
Më pas, me një interval prej 1-2 muajsh zhvilluam edhe dy takime të tjera. Tashmë kishte dy herë më shumë pjesëmarrës. Në "Ufa Software QA and Testing Meetup #2" ne u zhytëm më thellë në fushën e temës. Ata folën për sistemet e gjurmimit të gabimeve, testimin e UI/UX, prekën Docker, Ansible dhe gjithashtu folën për konfliktet e mundshme midis një zhvilluesi dhe një testuesi dhe mënyrat për t'i zgjidhur ato.Takimi ynë i tretë, "Ufa Software QA and Testing Meetup #3", lidhej indirekt me punën e testuesve, por ishte i dobishëm për t'i kujtuar programuesit në kohë detyrat e tyre teknike dhe organizative: testimi i ngarkesës, testimi e2e, Selenium në autotestim, dobësitë e aplikacioneve në ueb .
Gjatë gjithë kësaj kohe ne kemi mësuar se si të krijojmë dritë dhe zë normal në transmetimet nga ngjarjet tona:
→
→
→ - Dhe në fund vendosëm të përpiqemi të zhvillojmë një hackathon për testuesit
Si përgatitëm dhe zhvilluam një hackathon për testuesit
Për të filluar, ne u përpoqëm të kuptonim se çfarë lloj "bishë" është kjo dhe si kryhet zakonisht. Siç doli, ngjarje të këtij lloji nuk janë mbajtur shumë herë në Federatën Ruse dhe nuk ka ku të huazosh ide. Së dyti, nuk doja të investoja menjëherë shumë burime në një ngjarje që dukej e dyshimtë në shikim të parë. Prandaj, vendosëm që të bëjmë mini-hakatone të shkurtra, jo për të gjithë ciklin e punës së QA, por për faza individuale.
Dhimbja jonë kryesore është mungesa e praktikës midis testuesve lokalë në krijimin e hartave të qarta të testimit. Ata nuk shpenzojnë kohë duke hulumtuar historitë e përdoruesve të para-zbatimit dhe duke krijuar kritere pranimi që janë të qarta për zhvilluesit për kërkesat funksionale dhe jofunksionale, UI/UX, sigurinë, ngarkesat e punës dhe ngarkesat maksimale. Prandaj, vendosëm, për herë të parë, të kalojmë pjesën më interesante dhe kreative të punës së tyre - analizën dhe formimin e kërkesave gjatë hulumtimit para projektit.
Ne vlerësuam numrin e mundshëm të pjesëmarrësve dhe vendosëm që na duheshin të paktën 5 lëndë të mbetura për publikimet e MVP-ve, 5 produkte dhe 5 persona që do të vepronin si pronarë të produkteve, do të deshifronin nevojat e biznesit dhe do të merrnin vendime për kufizimet.
Ja çfarë kemi: .
Ideja kryesore ishte të dilnim me tema që ishin sa më larg punës së përditshme të të gjithë pjesëmarrësve dhe t'u jepej atyre hapësirë për një fluturim krijues të imagjinatës.
Çfarë gabimesh bëmë dhe çfarë mund të bënim më mirë?
Përdorimi i praktikave të vlerësimit, kaq të njohura në fushën e punësimit të shitësve dhe menaxherëve të nivelit më të ulët, mori një përpjekje të madhe, por nuk na lejoi t'i kushtonim vëmendje të mjaftueshme secilit pjesëmarrës dhe të vlerësonim aftësitë e tij. Në përgjithësi, ky opsion përzgjedhjeje krijon një imazh negativ të kompanisë, pasi mjaft njerëz marrin reagime të pamjaftueshme dhe më pas krijojnë tek vetja dhe të tjerët efektin e tiranisë së punëdhënësit (komunikimet në komunitetet e IT janë shumë të zhvilluara). Si rezultat, ne kemi mbetur fjalë për fjalë me dy kandidatë potencialë me një të ardhme shumë të largët.
Takimet janë një gjë e mirë. Krijohet një bazë e gjerë për përpunim dhe niveli i përgjithshëm i pjesëmarrësve rritet. Kompania po bëhet gjithnjë e më e njohur në treg. Por intensiteti i punës i ndërmarrjeve të tilla nuk është i vogël. Duhet të kuptoni qartë se mbajtja e takimeve do të zgjasë afërsisht 700-800 orë pune në vit.
Sa i përket hackathon-it të testimit. Këto lloj ngjarjesh nuk janë bërë ende të mërzitshme, pasi, ndryshe nga hackathon për zhvilluesit, ato mbahen shumë më rrallë. Avantazhi i kësaj ideje është se në mënyrë të relaksuar mund të shkëmbeni një sasi të madhe njohurish praktike dhe të përcaktoni me saktësi nivelin e secilit pjesëmarrës.
Pasi analizuam rezultatet e ngjarjes, kuptuam se kemi bërë shumë gabime:
- Gabimi më i pafalshëm ishte të besuam se do të na mjaftonin 4-5 orë. Si rezultat, vetëm prezantimi dhe njohja me lëndët e prapambetura zgjati pothuajse 2 orë.
Puna me pronarët e produkteve në fazën fillestare dhe koha për t'u zhytur në fushën e temës mori të njëjtën kohë. Pra, koha e mbetur nuk ishte qartësisht e mjaftueshme për një zhvillim gjithëpërfshirës të hartave të testimit. - Nuk kishte kohë dhe energji të mjaftueshme për reagime të hollësishme në secilën hartë, pasi tashmë ishte natë. Prandaj, padyshim që dështuam në këtë pjesë, por fillimisht synohej të ishte më e vlefshme në hackathon.
- Ne vendosëm të vlerësonim cilësinë e zhvillimit me një votë të thjeshtë të të gjithë pjesëmarrësve, duke ndarë 3 vota për secilin ekip, të cilat ata mund të jepnin për punën më cilësore. Ndoshta do të ishte më mirë të organizohej një juri.
Çfarë keni arritur?
Ne e kemi zgjidhur pjesërisht problemin tonë dhe tani kemi 4 burra të guximshëm, të pashëm që punojnë për ne, duke mbuluar pjesën e pasme të 4 ekipeve të zhvillimit. Ende nuk janë vënë re një grup i konsiderueshëm kandidatësh të fortë potencialë dhe ndryshime të prekshme në nivelin e komunitetit të SC të qytetit. Por ka disa përparime dhe kjo nuk mund të mos gëzojë.
Burimi: www.habr.com