Hvers vegna héldum við hackathon fyrir prófunarmenn?

Þessi grein mun vekja áhuga þeirra sem, eins og við, standa frammi fyrir því vandamáli að velja viðeigandi sérfræðing á sviði prófunar.

Merkilegt nokk, með fjölgun upplýsingatæknifyrirtækja í lýðveldinu okkar, fjölgar aðeins verðugum forriturum, en ekki prófunaraðilum. Margir eru áhugasamir um að komast í þetta starf, en ekki margir skilja merkingu þess.
Hvers vegna héldum við hackathon fyrir prófunarmenn?
Ég get ekki talað fyrir hönd allra upplýsingatæknifyrirtækja, en við höfum úthlutað hlutverki QA/QC til gæðasérfræðinga okkar. Þeir eru hluti af þróunarteymi og taka þátt í öllum stigum þróunar, allt frá rannsóknum til útgáfu nýrrar útgáfu.

Prófari í teymi, jafnvel á skipulagsstigi, verður að hugsa í gegnum allar virkni og óvirkar kröfur til að samþykkja notendasögu. Hann verður að skilja rekstrareiginleika vörunnar sem og forritara, og jafnvel betra, og hjálpa teyminu að taka ekki rangar ákvarðanir jafnvel á skipulagsstigi. Prófandinn verður að hafa skýran skilning á því hvernig innleidd virkni mun virka og hvaða gildrur geta verið. Prófunaraðilar okkar búa til prófunaráætlanir og prófunartilvik sjálfir, auk þess að undirbúa alla nauðsynlega prófunarbekki. Að prófa samkvæmt tilbúinni forskrift eins og apa-smelli er ekki valkostur okkar. Með því að vinna innan teymisins verður hann að hjálpa til við að gefa út verðuga vöru og hringja í tíma ef eitthvað fer úrskeiðis.

Það sem við lentum í þegar leitað var að prófunaraðilum

Á því stigi að skoða margar ferilskrár virtist sem það væru til sérfræðingar með viðeigandi reynslu fyrir okkur og það væri engin vandamál með að velja prófunaraðila fyrir teymið okkar. En á persónulegum fundum rákumst við í auknum mæli á frambjóðendur sem voru í raun langt frá heimi upplýsingatækninnar (til dæmis gátu þeir ekki greint frá meginreglum samskipta vafra og vefþjóns, grundvallaratriði öryggis, tengsla og ó- tengslagagnagrunna, höfðu þeir ekki hugmynd um sýndarvæðingu og gámavæðingu), en á sama tíma mátu sig á Senior QA stigi. Eftir að hafa tekið tugi viðtala komumst við að þeirri niðurstöðu að fjöldi sérfræðinga sem hentar okkur á svæðinu er hverfandi.

Næst mun ég segja þér hvaða skref við tókum og hvaða mistök við stigum á til að finna þessa langþráðu bardagamenn fyrir gæði.

Hvernig við reyndum að laga ástandið

Eftir að hafa klárað okkur með að útvega tilbúnum sérfræðingum fórum við að miða á nærliggjandi svæði:

  1. Við reyndum að beita matsaðferðum til að bera kennsl á meðal margra „slepptu því“ fólki, einmitt það fólk sem við getum þróað sterka sérfræðinga frá.

    Við báðum hóp mögulegra umsækjenda með um það bil jafnmikla þekkingu að klára verkefni. Með því að fylgjast með hugsunarferli þeirra reyndum við að finna efnilegasta frambjóðandann.

    Sérstaklega komum við með verkefni til að prófa athygli, skilning á getu tækni og eiginleikum fjölmenningar:

    Hvers vegna héldum við hackathon fyrir prófunarmenn?
    Hvers vegna héldum við hackathon fyrir prófunarmenn?

  2. Við héldum fundi fyrir prófunaraðila til að víkka út mörk skilnings á faginu meðal núverandi liðsmanna.

    Ég skal segja þér aðeins frá hverjum þeirra.

    Ufa Software QA and Testing Meetup #1 er fyrsta tilraun okkar til að safna saman þeim sem láta sér annt um fagið og skilja um leið hvort almenningur hafi áhuga á því sem við viljum koma þeim á framfæri. Í grundvallaratriðum snerust skýrslur okkar um hvar það er betra að byrja ef þú hefur ákveðið að gerast prófari. Hjálpaðu byrjendum að opna augun og líta á próf eins og fullorðinn einstakling. Við ræddum skrefin sem nýliði prófarar þurfa að taka til að taka þátt í faginu. Um hvað gæði eru og hvernig á að ná þeim við raunverulegar aðstæður. Og líka hvað er sjálfvirk prófun og hvar er hentugra að nota það.

    Hvers vegna héldum við hackathon fyrir prófunarmenn?

    Síðan héldum við tvo fundi í viðbót með 1-2 mánaða millibili. Þátttakendur voru þegar tvöfalt fleiri. Á „Ufa Software QA and Testing Meetup #2“ steyptum við okkur dýpra í efnið. Þeir ræddu um villurakningarkerfi, UI/UX prófun, snerta Docker, Ansible og ræddu einnig um hugsanlega átök milli þróunaraðila og prófunaraðila og leiðir til að leysa þau.

    Þriðji fundur okkar, „Ufa Software QA and Testing Meetup #3,“ tengdist óbeint starfi prófunaraðila, en var gagnlegur til að minna forritara tímanlega á tæknilegar og skipulagslegar skyldur þeirra: álagsprófun, e2e prófun, Selen í sjálfvirkri prófun, veikleika á vefforritum .

    Allan þennan tíma höfum við verið að læra hvernig á að búa til eðlilegt ljós og hljóð í útsendingum frá viðburðum okkar:

    → Fyrstu skrefin í prófun - Ufa Software QA og Testing Meetup #1
    → UI/UX próf – Ufa Software QA og Testing Meetup #2
    → Öryggispróf, álagspróf og sjálfvirk próf – Ufa QA og Testing Meetup #3

  3. Og á endanum ákváðum við að reyna að halda hackathon fyrir prófunarmenn

Hvernig við undirbjuggum og framkvæmdum hackathon fyrir prófunaraðila

Til að byrja með reyndum við að skilja hvers konar „dýr“ þetta er og hvernig það er venjulega framkvæmt. Eins og kom í ljós hafa viðburðir af þessu tagi ekki verið haldnir oft í Rússlandi og hvergi hægt að fá hugmyndir að láni. Í öðru lagi vildi ég ekki fjárfesta strax mikið fjármagn í atburði sem virtist vafasöm við fyrstu sýn. Þess vegna ákváðum við að gera stutt mini-hackaþon, ekki fyrir allan QA vinnuferilinn, heldur fyrir einstaka áfanga.

Helsti höfuðverkurinn okkar er skortur á æfingum meðal staðbundinna prófara við að búa til skýr prófunarkort. Þeir eyða ekki tíma í að rannsaka notendasögur fyrir innleiðingu og búa til viðurkenningarviðmið sem eru skýr fyrir þróunaraðila fyrir hagnýtar og óvirkar kröfur, UI/UX, öryggi, vinnuálag og hámarksálag. Þess vegna ákváðum við, í fyrsta skipti, að fara í gegnum áhugaverðasta og skapandi hluta vinnu þeirra - greiningu og kröfugerð við forrannsóknir.

Við áætluðum mögulegan fjölda þátttakenda og ákváðum að við þyrftum að minnsta kosti 5 eftirstöðvar fyrir MVP útgáfur, 5 vörur og 5 manns sem myndu starfa sem vörueigendur, ráða viðskiptaþarfir og taka ákvarðanir um takmarkanir.

Hér er það sem við fengum: backlogs fyrir hackathon.

Meginhugsunin var að koma með efni sem væru eins fjarri öllum daglegum störfum þátttakenda og hægt væri og gefa þeim svigrúm til skapandi hugmyndaflugs.

Hvers vegna héldum við hackathon fyrir prófunarmenn?

Hvers vegna héldum við hackathon fyrir prófunarmenn?

Hvaða mistök gerðum við og hvað gætum við gert betur?

Notkun matsaðferða, sem er svo vinsæl á sviði ráðningar sölufólks og lægri stjórnenda, kostaði gríðarlega mikið átak en leyfði okkur ekki að veita hverjum og einum þátttakanda næga athygli og meta hæfileika hans. Almennt séð skapar þessi valmöguleiki neikvæða mynd af fyrirtækinu, þar sem nokkuð margir fá ófullnægjandi endurgjöf og skapa í kjölfarið í sjálfu sér og öðrum áhrif ofríkis vinnuveitanda (samskipti í upplýsingatæknisamfélögum eru mjög þróuð). Fyrir vikið sitjum við uppi með bókstaflega tvo mögulega umsækjendur með mjög fjarlæga framtíð.

Fundir eru af hinu góða. Víðtækur grunnur fyrir úrvinnslu skapast og almennt stig þátttakenda eykst. Fyrirtækið verður sífellt þekktara á markaðnum. En vinnustyrkur slíkra fyrirtækja er ekki lítill. Þú þarft að gera þér grein fyrir því að það mun taka um það bil 700-800 vinnustundir á ári að halda fundi.

Hvað varðar prófunarhakkaþonið. Svona viðburðir eru ekki enn orðnir leiðinlegir þar sem þeir eru haldnir mun sjaldnar, ólíkt hackathons fyrir forritara. Kosturinn við þessa hugmynd er að á afslappaðan hátt er hægt að skiptast á miklu magni af hagnýtri þekkingu og ákvarða nákvæmlega stig hvers þátttakanda.

Eftir að hafa greint niðurstöður viðburðarins komumst við að því að við gerðum mörg mistök:

  1. Ófyrirgefanlegustu mistökin voru að trúa því að 4-5 tímar væru nóg fyrir okkur. Fyrir vikið tók bara kynningin og kynningin á eftirstöðvunum næstum 2 klukkustundir.
    Sama langan tíma tók að vinna með vörueigendum á upphafsstigi og tími til að kafa ofan í viðfangsefnið. Þannig að sá tími sem eftir var var greinilega ekki nóg fyrir alhliða þróun á prófunarkortunum.
  2. Það var ekki nægur tími og orka fyrir nákvæma endurgjöf á hverju korti, þar sem það var þegar nótt. Þess vegna mistókst okkur greinilega þennan þátt, en var upphaflega ætlað að vera það verðmætasta í hackathoninu.
  3. Við ákváðum að meta gæði þróunar með einfaldri atkvæðagreiðslu allra þátttakenda, úthluta 3 atkvæðum fyrir hvert lið sem þeir gátu gefið fyrir vinnu í hæsta gæðaflokki. Kannski væri betra að skipuleggja dómnefnd.

Hverju hefur þú áorkað?

Við höfum leyst vandamálið okkar að hluta og nú erum við með 4 hugrakka, myndarlega menn sem vinna fyrir okkur, sem dekka aftan á 4 þróunarteymi. Ekki hefur enn verið tekið eftir verulegum hópi hugsanlegra sterkra umsækjenda og áþreifanlegra breytinga á stigi QA samfélags borgarinnar. En það eru nokkur framfarir og þetta getur ekki annað en fagnað.

Heimild: www.habr.com

Bæta við athugasemd