Hoekom het ons 'n hackathon vir toetsers gehou?

Hierdie artikel sal van belang wees vir diegene wat, soos ons, gekonfronteer word met die probleem om 'n geskikte spesialis op die gebied van toetsing te kies.

Vreemd genoeg, met die toename in die aantal IT-maatskappye in ons republiek, neem net die aantal waardige programmeerders toe, maar nie toetsers nie. Baie mense is gretig om hierdie beroep te betree, maar nie baie verstaan ​​die betekenis daarvan nie.

Ek kan nie namens alle IT-maatskappye praat nie, maar ons het die rol van QA/QC aan ons kwaliteitspesialiste toegeken. Hulle is deel van die ontwikkelingspan en neem deel aan alle stadiums van ontwikkeling, van navorsing tot die vrystelling van 'n nuwe weergawe.

'n Toetser in 'n span, selfs in die beplanningstadium, moet deur al die funksionele en nie-funksionele vereistes dink om 'n gebruikersstorie te aanvaar. Hy moet die operasionele kenmerke van die produk sowel as programmeerders verstaan, en selfs beter, en die span help om selfs in die beplanningstadium nie verkeerde besluite te neem nie. Die toetser moet 'n duidelike begrip hê van hoe die geïmplementeerde funksionaliteit sal werk en watter slaggate daar mag wees. Ons toetsers skep self toetsplanne en toetsgevalle, asook berei al die nodige toetsbanke voor. Toets volgens 'n klaargemaakte spesifikasie soos 'n aapklikker is nie ons opsie nie. Werk binne die span, moet hy help om 'n waardige produk vry te stel en betyds alarm te maak as iets verkeerd loop.

Wat ons teëgekom het toe ons na toetsers gesoek het

Op die stadium van die bestudering van baie CV's het dit gelyk of daar spesialiste was met geskikte ondervinding vir ons en daar sou geen probleme wees om 'n toetser vir ons span te kies nie. Maar tydens persoonlike vergaderings het ons toenemend kandidate teëgekom wat eintlik redelik ver van die wêreld van inligtingstegnologie was (hulle kon byvoorbeeld nie die beginsels van interaksie tussen 'n blaaier en 'n webbediener, die basiese beginsels van sekuriteit, relasionele en nie- relasionele databasisse, het hulle geen idee gehad van virtualisering en houerisering nie), maar terselfdertyd hulself op die Senior QA-vlak geassesseer. Nadat ons tientalle onderhoude gevoer het, het ons tot die gevolgtrekking gekom dat die aantal spesialiste wat vir ons in die streek geskik is, weglaatbaar is.

Vervolgens sal ek jou vertel watter stappe ons gedoen het en watter foute ons getrap het om daardie langverwagte vegters vir kwaliteit te vind.

Hoe ons probeer het om die situasie reg te stel

Nadat ons onsself uitgeput het met die verkryging van gereedgemaakte spesialiste, het ons nabygeleë gebiede begin teiken:

1. Ons het probeer om assesseringspraktyke toe te pas om onder die baie "los-dit"-mense te identifiseer, die einste van wie ons sterk spesialiste kan ontwikkel.

   Ons het 'n groep potensiële kandidate met ongeveer dieselfde vlak van kennis gevra om take te voltooi. Deur hul denkproses waar te neem, het ons probeer om die mees belowende kandidaat te identifiseer.

   Ons het veral met take vorendag gekom om aandag, begrip van die vermoëns van tegnologie en die kenmerke van multikulturalisme te toets:

   
   

2. Ons het ontmoetings vir toetsers gehou om die grense van begrip van die beroep onder die bestaande kontingent uit te brei.

   Ek vertel jou 'n bietjie van elkeen van hulle.

   Ufa Software QA and Testing Meetup #1 is ons eerste poging om diegene wat omgee vir die beroep bymekaar te maak en terselfdertyd te verstaan ​​of die publiek sal belangstel in wat ons aan hulle wil oordra. Basies was ons verslae oor waar dit beter is om te begin as jy besluit het om 'n toetser te word. Help beginners om hul oë oop te maak en kyk na toetsing soos 'n volwassene. Ons het gesels oor die stappe wat beginnertoetsers moet neem om by die beroep aan te sluit. Oor wat kwaliteit is en hoe om dit in werklike omstandighede te bereik. En ook, wat is outomatiese toetsing en waar dit meer gepas is om dit te gebruik.

   
   
   Toe, met 'n tussenpose van 1-2 maande, het ons nog twee ontmoetings gehou. Daar was reeds twee keer soveel deelnemers. By "Ufa Software QA and Testing Meetup #2" het ons dieper in die vakgebied gedompel. Hulle het gepraat oor foutopsporingstelsels, UI/UX-toetsing, Docker, Ansible aangeraak en ook gepraat oor moontlike konflikte tussen 'n ontwikkelaar en 'n toetser en maniere om dit op te los.

   Ons derde vergadering, "Ufa Software QA and Testing Meetup #3," het indirek verband gehou met die werk van toetsers, maar was nuttig om programmeerders betyds te herinner aan hul tegniese en organisatoriese pligte: lastoetsing, e2e-toetsing, Selenium in outotoetsing, webtoepassingskwesbaarhede .

   Ons het al hierdie tyd geleer hoe om normale lig en klank te skep in uitsendings van ons geleenthede:

   → Eerste stappe in toetsing – Ufa Sagteware QA en Toets Meetup #1
   → UI/UX-toetsing – Ufa Sagteware QA en Toets Meetup #2
   → Sekuriteitstoetsing, vragtoetsing en outotoetsing – Ufa QA en Toets Meetup #3

3. En op die ou end het ons besluit om 'n hackathon vir toetsers te probeer hou

Hoe ons 'n hackathon vir toetsers voorberei en uitgevoer het

Om mee te begin, het ons probeer verstaan ​​watter soort "dier" dit is en hoe dit gewoonlik uitgevoer word. Soos dit geblyk het, is sulke geleenthede nie baie keer in die Russiese Federasie gehou nie, en daar is nêrens om idees te leen nie. Tweedens wou ek nie dadelik baie hulpbronne belê in 'n gebeurtenis wat met die eerste oogopslag twyfelagtig gelyk het nie. Daarom het ons besluit dat ons kort mini-hackathons sal doen, nie vir die hele QA-werksiklus nie, maar vir individuele stadiums.

Ons hoofpyn is die gebrek aan oefening onder plaaslike toetsers om duidelike toetskaarte te skep. Hulle spandeer nie tyd om voor-implementering gebruikersstories na te vors en aanvaardingskriteria te skep wat duidelik is vir ontwikkelaars vir funksionele en nie-funksionele vereistes, UI/UX, sekuriteit, werkladings en piekladings nie. Daarom het ons vir die eerste keer besluit om deur die interessantste en kreatiefste deel van hul werk te gaan – ontleding en vorming van vereistes tydens voorprojeknavorsing.

Ons het die potensiële aantal deelnemers beraam en besluit dat ons ten minste 5 agterstande benodig vir MVP-vrystellings, 5 produkte en 5 mense wat as produkeienaars sou optree, besigheidsbehoeftes sou ontsyfer en besluite oor beperkings sou neem.

Hier is wat ons gekry het: agterstande vir hackathon.

Die hoofgedagte was om met onderwerpe vorendag te kom wat so ver as moontlik van al die deelnemers se daaglikse werk verwyder is en om hulle ruimte te gee vir 'n kreatiewe verbeeldingsvlug.

Watter foute het ons gemaak en wat kan ons beter doen?

Die gebruik van assesseringspraktyke, so gewild op die gebied van die aanstelling van verkopers en laervlakbestuurders, het baie moeite gekos, maar het ons nie toegelaat om genoeg aandag aan elke deelnemer te gee en sy vermoëns te evalueer nie. Oor die algemeen skep hierdie seleksie-opsie 'n negatiewe beeld van die maatskappy, aangesien baie mense onvoldoende terugvoer ontvang en dan in hulself en ander die effek van tirannie van die werkgewer skep (kommunikasie in IT-gemeenskappe is baie ontwikkel). Gevolglik sit ons met letterlik twee potensiële kandidate oor met 'n baie verre toekoms.

Ontmoetings is 'n goeie ding. 'n Uitgebreide basis vir uitwerking word geskep, en die algemene vlak van die deelnemers neem toe. Die maatskappy word al hoe meer herkenbaar in die mark. Maar die arbeidsintensiteit van sulke ondernemings is nie gering nie. Jy moet duidelik verstaan ​​dat die hou van ontmoetings ongeveer 700-800 man-ure per jaar sal neem.

Wat die toets hackathon betref. Hierdie soort geleenthede het nog nie vervelig geword nie, aangesien dit, anders as hackathons vir ontwikkelaars, baie minder gereeld gehou word. Die voordeel van hierdie idee is dat jy op 'n ontspanne manier 'n groot hoeveelheid praktiese kennis kan uitruil en die vlak van elke deelnemer redelik akkuraat kan bepaal.

Nadat ons die resultate van die geleentheid ontleed het, het ons besef dat ons baie foute gemaak het:

1. Die mees onvergeeflike fout was om te glo dat 4-5 ure vir ons genoeg sou wees. Gevolglik het net die bekendstelling en vertroudheid met die agterstande amper 2 uur geneem.
   Om in die aanvanklike stadium met produkeienaars te werk en tyd om in die vakgebied te duik, het dieselfde tyd geneem. Die oorblywende tyd was dus duidelik nie genoeg vir 'n omvattende ontwikkeling van die toetskaarte nie.
2. Daar was nie genoeg tyd en energie vir gedetailleerde terugvoer op elke kaart nie, aangesien dit reeds nag was. Daarom het ons hierdie deel duidelik misluk, maar was aanvanklik bedoel om die waardevolste in die hackathon te wees.
3. Ons het besluit om die kwaliteit van ontwikkeling te evalueer deur 'n eenvoudige stem van al die deelnemers, toekenning van 3 stemme vir elke span, wat hulle kon gee vir die hoogste gehalte werk. Miskien sal dit beter wees om 'n jurie te organiseer.

Wat het jy bereik?

Ons het ons probleem gedeeltelik opgelos en nou het ons 4 dapper, aantreklike mans wat vir ons werk, wat die agterkant van 4 ontwikkelingspanne dek. ’n Beduidende poel potensiële sterk kandidate en tasbare veranderinge in die vlak van die stad se QA-gemeenskap is nog nie opgemerk nie. Maar daar is 'n mate van vordering en dit kan nie anders as om bly te wees nie.

Bron: will.com