ProHoster > Blogs > interneta ziņas > Kāpēc mēs rīkojām hakatonu testētājiem?

Kāpēc mēs rīkojām hakatonu testētājiem?

Å is raksts bÅ«s interesants tiem, kuri, tāpat kā mēs, saskaras ar problēmu izvēlēties piemērotu speciālistu testÄ“Å”anas jomā.

Savādi, bet, pieaugot IT uzņēmumu skaitam mÅ«su republikā, pieaug tikai cienÄ«gu programmētāju, bet ne testētāju skaits. Daudzi cilvēki vēlas apgÅ«t Å”o profesiju, bet ne daudzi saprot tās nozÄ«mi.
Kāpēc mēs rīkojām hakatonu testētājiem?
Es nevaru runāt par visiem IT uzņēmumiem, bet mēs esam uzticējuÅ”i QA/QC lomu mÅ«su kvalitātes speciālistiem. Viņi ir daļa no izstrādes komandas un piedalās visos izstrādes posmos, sākot no izpētes lÄ«dz jaunas versijas izdoÅ”anai.

Testētājam komandā pat plānoÅ”anas stadijā ir jāpārdomā visas funkcionālās un nefunkcionālās prasÄ«bas lietotāja stāsta pieņemÅ”anai. Viņam ir jāsaprot produkta darbÄ«bas Ä«paŔības, kā arÄ« programmētāji un vēl labāk, un jāpalÄ«dz komandai nepieņemt nepareizus lēmumus pat plānoÅ”anas stadijā. Testētājam ir jābÅ«t skaidrai izpratnei par to, kā ieviestā funkcionalitāte darbosies un kādas var bÅ«t nepilnÄ«bas. MÅ«su testētāji paÅ”i veido testu plānus un testÄ“Å”anas gadÄ«jumus, kā arÄ« sagatavo visus nepiecieÅ”amos testu stendus. Pārbaude saskaņā ar gatavu specifikāciju, piemēram, pērtiÄ·u klikeri, nav mÅ«su izvēle. Strādājot komandā, viņam jāpalÄ«dz izdot cienÄ«gs produkts un laikus jāzvana trauksmes signāls, ja kaut kas noiet greizi.

Ar ko mēs saskārāmies, meklējot testētājus

Daudzu CV apgÅ«Å”anas posmā Ŕķita, ka ir speciālisti ar mums piemērotu pieredzi un ar testera izvēli mÅ«su komandai problēmu nebÅ«s. Taču personÄ«go tikÅ”anos laikā arvien biežāk sastapāmies ar kandidātiem, kuri patiesÄ«bā bija diezgan tālu no informācijas tehnoloÄ£iju pasaules (piemēram, viņi nevarēja pastāstÄ«t pārlÅ«kprogrammas un tÄ«mekļa servera mijiedarbÄ«bas principus, droŔības pamatus, relāciju un nesaistÄ«tus). relāciju datu bāzes, viņiem nebija ne jausmas par virtualizāciju un konteinerizāciju), bet tajā paŔā laikā novērtēja sevi Senior QA lÄ«menÄ«. Veicot desmitiem interviju, nonācām pie secinājuma, ka mums piemēroto speciālistu skaits reÄ£ionā ir niecÄ«gs.

Tālāk pastāstÄ«Å”u, kādus soļus spērām un kādas kļūdas pieļāvām, lai atrastu tos ilgi gaidÄ«tos cÄ«nÄ«tājus par kvalitāti.

Kā mēs mēģinājām labot situāciju

IzsmēluÅ”i sevi ar gatavu speciālistu iegÅ«Å”anu, mēs sākām mērķēt uz tuvējiem apgabaliem:

  1. Mēs centāmies pielietot vērtÄ“Å”anas praksi, lai starp daudzajiem ā€œatstājā€ cilvēkiem identificētu tieÅ”i tos, no kuriem varam izveidot spēcÄ«gus speciālistus.

    Mēs uzdevām veikt uzdevumus potenciālo kandidātu grupai ar aptuveni vienādu zināŔanu lÄ«meni. Vērojot viņu domu gājienu, mēģinājām noteikt perspektÄ«vāko kandidātu.

    Jo Ä«paÅ”i mēs nācām klajā ar uzdevumiem, lai pārbaudÄ«tu uzmanÄ«bu, izpratni par tehnoloÄ£iju iespējām un multikulturālisma iezÄ«mēm:

    Kāpēc mēs rīkojām hakatonu testētājiem?
    Kāpēc mēs rīkojām hakatonu testētājiem?

  2. Mēs rÄ«kojām testētāju tikÅ”anās, lai paplaÅ”inātu esoŔā kontingenta izpratnes robežas par profesiju.

    Es jums pastāstīŔu nedaudz par katru no tiem.

    Ufa Software QA un Testing Meetup #1 ir mÅ«su pirmais mēģinājums pulcēt tos, kam rÅ«p Ŕī profesija, un tajā paŔā laikā saprast, vai sabiedrÄ«ba bÅ«s ieinteresēta tajā, ko mēs vēlamies viņiem nodot. BÅ«tÄ«bā mÅ«su pārskati bija par to, ar ko labāk sākt, ja esat nolēmis kļūt par testētāju. PalÄ«dziet iesācējiem atvērt acis un skatÄ«ties uz testÄ“Å”anu kā pieauguÅ”am. Mēs runājām par soļiem, kas iesācējiem testētājiem jāveic, lai pievienotos profesijai. Par to, kas ir kvalitāte un kā to sasniegt reālos apstākļos. Un arÄ«, kas ir automātiskā testÄ“Å”ana un kur to piemērotāk izmantot.

    Kāpēc mēs rīkojām hakatonu testētājiem?

    Pēc tam ar 1-2 mēneÅ”u intervālu sarÄ«kojām vēl divas tikÅ”anās. DalÄ«bnieku jau bija divreiz vairāk. ā€œUfa Software QA and Testing Meetup #2ā€ mēs iedziļinājāmies tematiskajā jomā. Viņi runāja par kļūdu izsekoÅ”anas sistēmām, UI/UX testÄ“Å”anu, pieskārās Docker, Ansible, kā arÄ« runāja par iespējamiem konfliktiem starp izstrādātāju un testētāju un veidiem, kā tos atrisināt.

    MÅ«su treŔā tikÅ”anās ā€œUfa Software QA and Testing Meetup #3ā€ bija netieÅ”i saistÄ«ta ar testētāju darbu, taču noderēja, lai laikus atgādinātu programmētājiem par viņu tehniskajiem un organizatoriskiem pienākumiem: slodzes testÄ“Å”ana, e2e testÄ“Å”ana, selēns autotestÄ“Å”anā, tÄ«mekļa lietojumprogrammu ievainojamÄ«bas. .

    Visu Å”o laiku esam mācÄ«juÅ”ies, kā veidot normālu gaismu un skaņu pārraidēs no mÅ«su pasākumiem:

    ā†’ Pirmie soļi testÄ“Å”anā ā€“ Ufa Software QA un Testing Meetup #1
    ā†’ UI/UX testÄ“Å”ana ā€” Ufa programmatÅ«ras kvalitātes nodroÅ”ināŔana un testÄ“Å”anas sapulce #2
    ā†’ DroŔības pārbaude, slodzes pārbaude un automātiskā testÄ“Å”ana ā€” Ufa QA un Testing Meetup #3

  3. Un beigās nolēmām mēģināt sarīkot hakatonu testētājiem

Kā mēs sagatavojām un vadījām hakatonu testētājiem

Sākumā mēs centāmies saprast, kāda veida ā€œzvērsā€ tas ir un kā tas parasti tiek veikts. Kā izrādÄ«jās, Krievijas Federācijā Ŕāda veida pasākumi nav notikuÅ”i daudzkārt, un idejas nav kur aizņemties. Otrkārt, es negribēju uzreiz ieguldÄ«t lielus resursus pasākumā, kas no pirmā acu uzmetiena Ŕķita apÅ”aubāms. Tāpēc nolēmām, ka veiksim Ä«sus mini hakatonus, nevis visu QA darba ciklu, bet gan atseviŔķus posmus.

MÅ«su galvenās galvassāpes ir vietējo testētāju pieredzes trÅ«kums skaidru testÄ“Å”anas karÅ”u veidoÅ”anā. Viņi netērē laiku, lai izpētÄ«tu lietotāju stāstus pirms ievieÅ”anas un izveidotu izstrādātājiem skaidri saprotamus pieņemÅ”anas kritērijus attiecÄ«bā uz funkcionālajām un nefunkcionālajām prasÄ«bām, lietotāja interfeisu/UX, droŔību, darba slodzi un maksimālo slodzi. Tāpēc mēs nolēmām pirmo reizi iziet cauri viņu darba interesantākajai un radoŔākai daļai - analÄ«zi un prasÄ«bu veidoÅ”anu pirmsprojekta pētÄ«juma laikā.

Mēs aprēķinājām potenciālo dalÄ«bnieku skaitu un nolēmām, ka mums ir nepiecieÅ”ami vismaz 5 neizpaustie MVP izlaidumi, 5 produkti un 5 cilvēki, kas darbotos kā produktu Ä«paÅ”nieki, atÅ”ifrētu biznesa vajadzÄ«bas un pieņemtu lēmumus par ierobežojumiem.

Lūk, ko mēs saņēmām: kavējumi hakatonā.

Galvenā ideja bija izdomāt tēmas, kas bÅ«tu pēc iespējas tālāk no visiem dalÄ«bnieku ikdienas darbiem, un dot viņiem iespēju radoÅ”am iztēles lidojumam.

Kāpēc mēs rīkojām hakatonu testētājiem?

Kāpēc mēs rīkojām hakatonu testētājiem?

Kādas kļūdas mēs pieļāvām un ko mēs varētu darīt labāk?

Pārdevēju un zemāka lÄ«meņa vadÄ«tāju algoÅ”anas jomā tik populārās vērtÄ“Å”anas prakses izmantoÅ”ana prasÄ«ja milzÄ«gu piepÅ«li, taču neļāva pievērst pietiekamu uzmanÄ«bu katram dalÄ«bniekam un novērtēt viņa spējas. Kopumā Ŕī izvēles iespēja rada negatÄ«vu uzņēmuma tēlu, jo diezgan daudzi cilvēki saņem nepietiekamas atsauksmes un pēc tam rada sevÄ« un citos darba devēja tirānijas efektu (saziņa IT kopienās ir ļoti attÄ«stÄ«ta). Rezultātā mums paliek burtiski divi potenciālie kandidāti ar ļoti tālu nākotni.

TikÅ”anās ir laba lieta. Tiek radÄ«ta plaÅ”a bāze izstrādei, paaugstinās dalÄ«bnieku vispārējais lÄ«menis. Uzņēmums kļūst arvien atpazÄ«stamāks tirgÅ«. Taču Ŕādu uzņēmumu darbietilpÄ«ba nav maza. Jums skaidri jāsaprot, ka sanāksmju rÄ«koÅ”ana prasÄ«s aptuveni 700ā€“800 cilvēkstundas gadā.

Kas attiecas uz testÄ“Å”anas hakatonu. Šāda veida pasākumi vēl nav kļuvuÅ”i garlaicÄ«gi, jo atŔķirÄ«bā no hakatoniem izstrādātājiem tie tiek rÄ«koti daudz retāk. Å Ä«s idejas priekÅ”rocÄ«ba ir tāda, ka atraisÄ«tā veidā var apmainÄ«ties ar lielu daudzumu praktisko zināŔanu un diezgan precÄ«zi noteikt katra dalÄ«bnieka lÄ«meni.

Izanalizējot pasākuma rezultātus, sapratām, ka esam pieļāvuÅ”i daudz kļūdu:

  1. Visnepiedodamākā kļūda bija uzskatÄ«t, ka mums pietiks ar 4-5 stundām. Rezultātā tikai iepazÄ«Å”anās un iepazÄ«Å”anās ar atpalikuÅ”ajiem darbiem aizņēma gandrÄ«z 2 stundas.
    Darbs ar produktu Ä«paÅ”niekiem sākotnējā posmā un laiks, lai ienirt tēmas jomā, prasÄ«ja tikpat daudz laika. Tātad atlikuÅ”ais laiks nepārprotami nebija pietiekami visaptveroÅ”ai testÄ“Å”anas karÅ”u izstrādei.
  2. Nepietika laika un enerÄ£ijas detalizētai atsauksmei par katru karti, jo bija jau nakts. Tāpēc mums Ŕī daļa nepārprotami neizdevās, bet sākotnēji bija iecerēta kā vērtÄ«gākā hakatonā.
  3. Izstrādes kvalitāti nolēmām novērtēt ar vienkārÅ”u visu dalÄ«bnieku balsojumu, katrai komandai atvēlot 3 balsis, kuras viņi varēja dot par kvalitatÄ«vāko darbu. VarbÅ«t labāk bÅ«tu organizēt žūriju.

Ko tu esi sasniedzis?

Mēs esam daļēji atrisinājuÅ”i savu problēmu, un tagad pie mums strādā 4 drosmÄ«gi, izskatÄ«gi vÄ«rieÅ”i, kas nosedz 4 izstrādes komandu aizmuguri. Ievērojams potenciālo spēcÄ«gu kandidātu kopums un taustāmas izmaiņas pilsētas kvalitātes nodroÅ”ināŔanas kopienas lÄ«menÄ« vēl nav pamanÄ«tas. Taču ir zināms progress, un tas var vien priecāties.

Avots: www.habr.com

Pievieno komentāru