Kwa nini tulishikilia hackathon kwa wanaojaribu?

Nakala hii itakuwa ya kupendeza kwa wale ambao, kama sisi, wanakabiliwa na shida ya kuchagua mtaalamu anayefaa katika uwanja wa upimaji.

Cha ajabu, pamoja na ongezeko la idadi ya makampuni ya IT katika jamhuri yetu, ni idadi tu ya waandaaji programu wanaostahili huongezeka, lakini sio wanaojaribu. Watu wengi wana hamu ya kuingia katika taaluma hii, lakini sio wengi wanaoelewa maana yake.

Siwezi kuzungumzia kampuni zote za TEHAMA, lakini tumeweka jukumu la QA/QC kwa wataalamu wetu wa ubora. Wao ni sehemu ya timu ya maendeleo na wanashiriki katika hatua zote za maendeleo, kutoka kwa utafiti hadi kutolewa kwa toleo jipya.

Mjaribu katika timu, hata katika hatua ya kupanga, lazima afikirie mahitaji yote ya utendaji na yasiyo ya utendaji ili kukubali hadithi ya mtumiaji. Lazima aelewe sifa za uendeshaji wa bidhaa pamoja na waandaaji wa programu, na hata bora zaidi, na kusaidia timu isifanye maamuzi mabaya hata katika hatua ya kupanga. Mjaribu lazima awe na ufahamu wazi wa jinsi utendakazi uliotekelezwa utafanya kazi na ni mitego gani inaweza kuwa. Wajaribu wetu huunda mipango ya majaribio na kesi za majaribio wenyewe, na pia kuandaa madawati yote muhimu ya majaribio. Kujaribu kulingana na vipimo vilivyotengenezwa tayari kama kibofyo cha tumbili sio chaguo letu. Akifanya kazi ndani ya timu, lazima asaidie kutoa bidhaa inayofaa na kupiga kengele kwa wakati ikiwa kitu kitaenda vibaya.

Tulichokutana nacho tulipotafuta wanaojaribu

Katika hatua ya kusoma wasifu mwingi, ilionekana kuwa kuna wataalam walio na uzoefu unaofaa kwetu na hakutakuwa na shida na kuchagua mtu anayejaribu kwa timu yetu. Lakini, wakati wa mikutano ya kibinafsi, tulizidi kukutana na wagombea ambao walikuwa mbali kabisa na ulimwengu wa teknolojia ya habari (kwa mfano, hawakuweza kusema kanuni za mwingiliano kati ya kivinjari na seva ya wavuti, misingi ya usalama, uhusiano na isiyo ya kawaida. hifadhidata za uhusiano, hawakuwa na wazo juu ya uboreshaji na uwekaji vyombo), lakini wakati huo huo walijitathmini katika kiwango cha Juu cha QA. Baada ya kufanya mahojiano kadhaa, tulifikia hitimisho kwamba idadi ya wataalam wanaofaa kwetu katika mkoa huo ni kidogo.

Ifuatayo, nitakuambia ni hatua gani tulizochukua na ni makosa gani tuliyopitia ili kuwapata wapiganaji hao ambao walikuwa wakingojewa kwa ubora.

Jinsi tulijaribu kurekebisha hali hiyo

Baada ya kujichoka na kutafuta wataalam waliotengenezwa tayari, tulianza kulenga maeneo ya karibu:

1. Tulijaribu kutumia mazoea ya tathmini ili kutambua miongoni mwa watu wengi "wacha tu", ambao tunaweza kupata wataalamu madhubuti kutoka kwao.

   Tuliuliza kikundi cha watahiniwa watarajiwa walio na takriban kiwango sawa cha maarifa kukamilisha kazi. Kuzingatia mchakato wao wa mawazo, tulijaribu kutambua mgombea aliyeahidi zaidi.

   Hasa, tulikuja na kazi za kujaribu usikivu, uelewa wa uwezo wa teknolojia na sifa za tamaduni nyingi:

   
   

2. Tulifanya mikutano ya wanaojaribu ili kupanua mipaka ya uelewa wa taaluma kati ya kikosi kilichopo.

   Nitakuambia kidogo juu ya kila mmoja wao.

   Ufa Software QA na Meetup Testing Meetup #1 ni jaribio letu la kwanza la kukusanya wale wanaojali taaluma na wakati huo huo kuelewa kama umma utavutiwa na kile tunachotaka kuwasilisha kwao. Kimsingi, ripoti zetu zilikuwa kuhusu mahali ambapo ni bora kuanza ikiwa umeamua kuwa mtu anayejaribu. Wasaidie wanaoanza kufungua macho yao na kutazama majaribio kama mtu mzima. Tulizungumza kuhusu hatua ambazo watumiaji wa majaribio wanahitaji kuchukua ili kujiunga na taaluma. Kuhusu ubora ni nini na jinsi ya kuifanikisha katika hali halisi. Na pia, ni upimaji wa kiotomatiki ni nini na ni wapi inafaa zaidi kuitumia.

   
   
   Kisha, kwa muda wa miezi 1-2, tulifanya mikutano miwili zaidi. Tayari kulikuwa na washiriki mara mbili zaidi. Katika "Ufa Software QA na Testing Meetup #2" tulizama zaidi katika eneo la somo. Walizungumza kuhusu mifumo ya kufuatilia hitilafu, upimaji wa UI/UX, waligusa Docker, Ansible, na pia walizungumza kuhusu migogoro inayoweza kutokea kati ya msanidi programu na anayejaribu na njia za kuzitatua.

   Mkutano wetu wa tatu, "Ufa Software QA na Testing Meetup #3," ulihusiana kwa njia isiyo ya moja kwa moja na kazi ya wanaojaribu, lakini ulikuwa muhimu katika kuwakumbusha kwa wakati ufaao waandaaji wa programu majukumu yao ya kiufundi na ya shirika: kupima mzigo, kupima e2e, Selenium katika kupima kiotomatiki, udhaifu wa programu ya wavuti. .

   Wakati huu wote tumekuwa tukijifunza jinsi ya kuunda mwanga wa kawaida na sauti katika matangazo kutoka kwa matukio yetu:

   → Hatua za kwanza za majaribio - Ufa Software QA na Meetup ya Majaribio #1
   → Jaribio la UI/UX - Ufa Software QA na Mkutano wa Kujaribio #2
   → Upimaji wa usalama, upimaji wa upakiaji na majaribio ya kiotomatiki - Ufa QA na Mkutano wa Majaribio #3

3. Na mwisho tuliamua kujaribu kushikilia hackathon kwa wanaojaribu

Jinsi tulivyotayarisha na kuendesha hackathon kwa wanaojaribu

Kuanza, tulijaribu kuelewa ni "mnyama" wa aina gani na jinsi kawaida hufanywa. Kama ilivyotokea, matukio ya aina hii hayajafanyika mara nyingi katika Shirikisho la Urusi, na hakuna mahali pa kukopa mawazo. Pili, sikutaka kuwekeza rasilimali nyingi mara moja katika tukio ambalo lilionekana kuwa la shaka mwanzoni. Kwa hivyo, tuliamua kwamba tutafanya mini-hackathons fupi, sio kwa mzunguko mzima wa kazi wa QA, lakini kwa hatua za kibinafsi.

Kichwa chetu kikuu ni ukosefu wa mazoezi kati ya wapimaji wa ndani katika kuunda ramani wazi za majaribio. Hawatumii muda kutafiti hadithi za watumiaji kabla ya utekelezaji na kuunda vigezo vya kukubalika ambavyo ni wazi kwa wasanidi programu kwa mahitaji ya utendaji na yasiyo ya utendaji, UI/UX, usalama, mzigo wa kazi na mizigo ya kilele. Kwa hiyo, tuliamua, kwa mara ya kwanza, kupitia sehemu ya kuvutia zaidi na ya ubunifu ya kazi zao - uchambuzi na uundaji wa mahitaji wakati wa utafiti wa kabla ya mradi.

Tulikadiria idadi inayowezekana ya washiriki na tukaamua kuwa tunahitaji angalau kumbukumbu 5 za matoleo ya MVP, bidhaa 5 na watu 5 ambao watakuwa wamiliki wa bidhaa, kubainisha mahitaji ya biashara na kufanya maamuzi kuhusu vikwazo.

Hivi ndivyo tulivyopata: backlogs kwa hackathon.

Wazo kuu lilikuwa kuja na mada ambazo zilikuwa mbali na kazi ya kila siku ya washiriki wote iwezekanavyo na kuwapa upeo wa kukimbia kwa ubunifu wa mawazo.

Ni makosa gani tuliyofanya na ni nini tunaweza kufanya vizuri zaidi?

Utumiaji wa mazoea ya tathmini, maarufu sana katika uwanja wa kuajiri wauzaji na wasimamizi wa kiwango cha chini, ulichukua bidii kubwa, lakini haukuturuhusu kulipa kipaumbele cha kutosha kwa kila mshiriki na kutathmini uwezo wake. Kwa ujumla, chaguo hili la uteuzi huunda picha mbaya ya kampuni, kwani watu wengi hupokea maoni ya kutosha na baadaye hujitengenezea wenyewe na wengine athari za udhalimu wa mwajiri (mawasiliano katika jamii za IT yamekuzwa sana). Kwa hivyo, tumesalia na wagombeaji wawili watarajiwa walio na mustakabali wa mbali sana.

Mikutano ni jambo zuri. Msingi wa kina wa ufafanuzi huundwa, na kiwango cha jumla cha washiriki huongezeka. Kampuni hiyo inazidi kutambulika kwenye soko. Lakini nguvu ya kazi ya shughuli kama hizo sio ndogo. Unahitaji kuelewa wazi kwamba kufanya mikutano itachukua takriban masaa 700-800 kwa mwaka.

Kama kwa hackathon ya majaribio. Matukio ya aina hii bado hayajachosha, kwani, tofauti na hackathons kwa watengenezaji, hufanyika mara chache sana. Faida ya wazo hili ni kwamba kwa namna ya utulivu unaweza kubadilishana kiasi kikubwa cha ujuzi wa vitendo na kuamua kwa usahihi kiwango cha kila mshiriki.

Baada ya kuchambua matokeo ya hafla hiyo, tuligundua kuwa tulifanya makosa mengi:

1. Hitilafu isiyoweza kusamehewa ilikuwa kuamini kwamba masaa 4-5 yatatosha kwetu. Kwa hivyo, utangulizi tu na kufahamiana na kumbukumbu kulichukua karibu masaa 2.
   Kufanya kazi na wamiliki wa bidhaa katika hatua ya awali na wakati wa kupiga mbizi kwenye eneo la somo kulichukua muda sawa. Kwa hivyo wakati uliobaki haukutosha kwa maendeleo ya kina ya ramani za majaribio.
2. Hakukuwa na wakati na nishati ya kutosha kwa maoni ya kina kwenye kila ramani, kwa kuwa ilikuwa tayari usiku. Kwa hivyo, tulishindwa wazi sehemu hii, lakini hapo awali ilikusudiwa kuwa ya thamani zaidi katika hackathon.
3. Tuliamua kutathmini ubora wa maendeleo kwa kura rahisi ya washiriki wote, tukitenga kura 3 kwa kila timu, ambazo wangeweza kutoa kwa kazi bora zaidi. Labda itakuwa bora kuandaa jury.

Umepata nini?

Tumetatua tatizo letu kwa kiasi na sasa tuna wanaume 4 jasiri na warembo wanaotufanyia kazi, wanaoshughulikia sehemu ya nyuma ya timu 4 za maendeleo. Idadi kubwa ya wagombeaji hodari na mabadiliko yanayoonekana katika kiwango cha jumuiya ya jiji la QA bado hayajatambuliwa. Lakini kuna maendeleo fulani na hii haiwezi lakini kufurahi.

Chanzo: mapenzi.com