Bakit kami nagsagawa ng hackathon para sa mga tester?

Ang artikulong ito ay magiging interesado sa mga taong, tulad namin, ay nahaharap sa problema ng pagpili ng angkop na espesyalista sa larangan ng pagsubok.

Kakatwa, sa pagdami ng mga kumpanya ng IT sa ating republika, ang bilang lamang ng mga karapat-dapat na programmer ay tumataas, ngunit hindi mga tester. Maraming tao ang sabik na makapasok sa propesyon na ito, ngunit hindi marami ang nakakaunawa sa kahulugan nito.
Bakit kami nagsagawa ng hackathon para sa mga tester?
Hindi ako makapagsalita para sa lahat ng kumpanya ng IT, ngunit itinalaga namin ang tungkulin ng QA/QC sa aming mga espesyalista sa kalidad. Bahagi sila ng development team at lumalahok sa lahat ng yugto ng development, mula sa pananaliksik hanggang sa paglabas ng bagong bersyon.

Ang isang tester sa isang team, kahit na sa yugto ng pagpaplano, ay dapat pag-isipan ang lahat ng mga kinakailangan para sa paggana at hindi gumagana para sa pagtanggap ng isang kuwento ng user. Dapat niyang maunawaan ang mga katangian ng pagpapatakbo ng produkto pati na rin ang mga programmer, at mas mabuti pa, at tulungan ang koponan na huwag gumawa ng mga maling desisyon kahit na sa yugto ng pagpaplano. Dapat ay may malinaw na pag-unawa ang tester sa kung paano gagana ang ipinatupad na functionality at kung anong mga pitfalls ang maaaring magkaroon. Ang aming mga tagasubok ay gumagawa ng mga plano sa pagsubok at mga kaso ng pagsubok sa kanilang sarili, pati na rin ang paghahanda ng lahat ng kinakailangang mga bangko ng pagsubok. Ang pagsubok ayon sa isang handa na detalye tulad ng isang clicker ng unggoy ay hindi ang aming pagpipilian. Nagtatrabaho sa loob ng koponan, dapat siyang tumulong na maglabas ng isang karapat-dapat na produkto at magpatunog ng alarma sa oras kung may mali.

Ang na-encounter namin noong naghahanap kami ng mga tester

Sa yugto ng pag-aaral ng maraming resume, tila may mga espesyalista na may angkop na karanasan para sa amin at walang magiging problema sa pagpili ng tester para sa aming koponan. Ngunit, sa panahon ng mga personal na pagpupulong, lalo kaming nakatagpo ng mga kandidato na talagang malayo sa mundo ng teknolohiya ng impormasyon (halimbawa, hindi nila masasabi ang mga prinsipyo ng pakikipag-ugnayan sa pagitan ng isang browser at isang web server, ang mga pangunahing kaalaman sa seguridad, relational at non- mga relational database, wala silang ideya tungkol sa virtualization at containerization), ngunit sa parehong oras ay tinasa ang kanilang sarili sa antas ng Senior QA. Pagkatapos magsagawa ng dose-dosenang mga panayam, dumating kami sa konklusyon na ang bilang ng mga espesyalista na angkop para sa amin sa rehiyon ay bale-wala.

Susunod, sasabihin ko sa iyo kung anong mga hakbang ang aming ginawa at kung anong mga pagkakamali ang aming natapakan upang mahanap ang mga pinakahihintay na manlalaban para sa kalidad.

Kung paano namin sinubukang ayusin ang sitwasyon

Dahil napagod ang aming mga sarili sa paghahanap ng mga handa na espesyalista, sinimulan naming i-target ang mga kalapit na lugar:

  1. Sinubukan naming ilapat ang mga kasanayan sa pagtatasa upang matukoy sa maraming mga taong "iwanan-it", ang mga mismong kung saan maaari kaming bumuo ng mga mahuhusay na espesyalista.

    Tinanong namin ang isang pangkat ng mga potensyal na kandidato na may humigit-kumulang kaparehong antas ng kaalaman na kumpletuhin ang mga gawain. Sa pagmamasid sa kanilang proseso ng pag-iisip, sinubukan naming kilalanin ang pinaka-promising na kandidato.

    Sa partikular, nakagawa kami ng mga gawain upang subukan ang pagkaasikaso, pag-unawa sa mga kakayahan ng teknolohiya at mga tampok ng multikulturalismo:

    Bakit kami nagsagawa ng hackathon para sa mga tester?
    Bakit kami nagsagawa ng hackathon para sa mga tester?

  2. Nagsagawa kami ng mga pagkikita-kita para sa mga tester upang palawakin ang mga hangganan ng pag-unawa sa propesyon sa mga umiiral na contingent.

    Sasabihin ko sa iyo ng kaunti tungkol sa bawat isa sa kanila.

    Ang Ufa Software QA at Testing Meetup #1 ay ang aming unang pagtatangka upang tipunin ang mga nagmamalasakit sa propesyon at sa parehong oras ay maunawaan kung ang publiko ay magiging interesado sa kung ano ang gusto naming iparating sa kanila. Karaniwan, ang aming mga ulat ay tungkol sa kung saan mas mahusay na magsimula kung nagpasya kang maging isang tester. Tulungan ang mga baguhan na buksan ang kanilang mga mata at tumingin sa pagsubok na parang nasa hustong gulang. Napag-usapan namin ang tungkol sa mga hakbang na kailangang gawin ng mga baguhang tester para makasali sa propesyon. Tungkol sa kung ano ang kalidad at kung paano makamit ito sa totoong mga kondisyon. At gayundin, ano ang awtomatikong pagsubok at kung saan ito mas angkop na gamitin ito.

    Bakit kami nagsagawa ng hackathon para sa mga tester?

    Tapos, with an interval of 1-2 months, we held two more meetups. Doble na ang dami ng kalahok. Sa "Ufa Software QA and Testing Meetup #2" kami ay bumulusok nang mas malalim sa lugar ng paksa. Pinag-usapan nila ang tungkol sa mga sistema ng pagsubaybay sa bug, pagsubok sa UI/UX, pag-usapan ang Docker, Ansible, at pinag-usapan din ang mga posibleng salungatan sa pagitan ng isang developer at isang tester at mga paraan upang malutas ang mga ito.

    Ang aming ikatlong pulong, "Ufa Software QA at Testing Meetup #3," na hindi direktang nauugnay sa gawain ng mga tester, ngunit kapaki-pakinabang sa napapanahong pagpapaalala sa mga programmer ng kanilang mga teknikal at pang-organisasyong tungkulin: pagsubok sa pag-load, pagsubok sa e2e, Selenium sa autotesting, mga kahinaan sa web application .

    Sa lahat ng oras na ito, natutunan namin kung paano lumikha ng normal na liwanag at tunog sa mga broadcast mula sa aming mga kaganapan:

    β†’ Mga unang hakbang sa pagsubok – Ufa Software QA at Testing Meetup #1
    β†’ Pagsubok sa UI/UX – Ufa Software QA at Pagsusulit na Meetup #2
    β†’ Pagsubok sa seguridad, pagsubok sa pag-load at pagsubok sa auto – Ufa QA at Pagsusuri ng Pagkikita #3

  3. At sa huli, nagpasya kaming subukang magsagawa ng hackathon para sa mga tester

Paano kami naghanda at nagsagawa ng hackathon para sa mga tester

Upang magsimula, sinubukan naming maunawaan kung anong uri ng "hayop" ito at kung paano ito karaniwang isinasagawa. Tulad ng nangyari, ang mga kaganapan sa ganitong uri ay hindi ginanap nang maraming beses sa Russian Federation, at walang lugar upang humiram ng mga ideya. Pangalawa, hindi ko nais na agad na mamuhunan ng maraming mapagkukunan sa isang kaganapan na tila kahina-hinala sa unang tingin. Samakatuwid, nagpasya kaming gagawa kami ng mga maikling mini-hackathon, hindi para sa buong cycle ng trabaho ng QA, ngunit para sa mga indibidwal na yugto.

Ang aming pangunahing sakit sa ulo ay ang kakulangan ng pagsasanay sa mga lokal na tester sa paglikha ng malinaw na mga mapa ng pagsubok. Hindi sila gumugugol ng oras sa pagsasaliksik ng mga kwento ng user bago ang pagpapatupad at paggawa ng mga pamantayan sa pagtanggap na malinaw sa mga developer para sa functional at non-functional na mga kinakailangan, UI/UX, seguridad, workload at peak load. Samakatuwid, napagpasyahan namin, sa unang pagkakataon, na dumaan sa pinakakawili-wili at malikhaing bahagi ng kanilang trabaho - pagsusuri at pagbuo ng mga kinakailangan sa panahon ng pananaliksik bago ang proyekto.

Tinantya namin ang potensyal na bilang ng mga kalahok at napagpasyahan namin na kailangan namin ng hindi bababa sa 5 backlog para sa mga release ng MVP, 5 produkto at 5 tao na gaganap bilang mga may-ari ng produkto, intindihin ang mga pangangailangan ng negosyo at gagawa ng mga desisyon sa mga paghihigpit.

Narito kung ano ang nakuha namin: backlogs para sa hackathon.

Ang pangunahing ideya ay upang makabuo ng mga paksa na malayo sa lahat ng pang-araw-araw na gawain ng mga kalahok hangga't maaari at upang bigyan sila ng saklaw para sa isang malikhaing paglipad ng imahinasyon.

Bakit kami nagsagawa ng hackathon para sa mga tester?

Bakit kami nagsagawa ng hackathon para sa mga tester?

Anong mga pagkakamali ang nagawa natin at ano ang maaari nating gawin nang mas mahusay?

Ang paggamit ng mga kasanayan sa pagtatasa, na napakapopular sa larangan ng pagkuha ng mga salespeople at lower-level managers, ay nagsagawa ng malaking pagsisikap, ngunit hindi namin pinahintulutan na bigyang-pansin ang bawat kalahok at suriin ang kanyang mga kakayahan. Sa pangkalahatan, ang pagpipiliang ito sa pagpili ay lumilikha ng isang negatibong imahe ng kumpanya, dahil marami sa mga tao ang tumatanggap ng hindi sapat na feedback at kasunod na lumikha sa kanilang sarili at sa iba ang epekto ng paniniil ng employer (ang mga komunikasyon sa mga komunidad ng IT ay napakaunlad). Bilang resulta, naiwan tayo sa literal na dalawang potensyal na kandidato na may napakalayong hinaharap.

Ang mga pagkikita ay isang magandang bagay. Ang isang malawak na batayan para sa elaborasyon ay nilikha, at ang pangkalahatang antas ng mga kalahok ay tumataas. Ang kumpanya ay nagiging mas at mas nakikilala sa merkado. Ngunit ang lakas ng paggawa ng naturang mga gawain ay hindi maliit. Kailangan mong malinaw na maunawaan na ang pagdaraos ng mga meetup ay aabot ng humigit-kumulang 700-800 man-hours bawat taon.

Tulad ng para sa pagsubok na hackathon. Ang mga ganitong uri ng mga kaganapan ay hindi pa nakakabagot, dahil, hindi tulad ng mga hackathon para sa mga developer, ang mga ito ay gaganapin nang mas madalas. Ang bentahe ng ideyang ito ay na sa isang nakakarelaks na paraan maaari kang makipagpalitan ng isang malaking halaga ng praktikal na kaalaman at medyo tumpak na matukoy ang antas ng bawat kalahok.

Matapos suriin ang mga resulta ng kaganapan, napagtanto namin na marami kaming pagkakamali:

  1. Ang pinaka hindi mapapatawad na pagkakamali ay ang maniwala na ang 4-5 na oras ay magiging sapat para sa amin. Dahil dito, halos 2 oras lang ang introduction at familiarization sa backlogs.
    Ang pakikipagtulungan sa mga may-ari ng produkto sa paunang yugto at oras upang sumisid sa lugar ng paksa ay tumagal ng parehong tagal ng oras. Kaya't ang natitirang oras ay malinaw na hindi sapat para sa isang komprehensibong pag-unlad ng mga mapa ng pagsubok.
  2. Walang sapat na oras at lakas para sa detalyadong feedback sa bawat mapa, dahil gabi na. Samakatuwid, malinaw na nabigo kami sa bahaging ito, ngunit sa una ay nilayon na maging pinakamahalaga sa hackathon.
  3. Nagpasya kaming suriin ang kalidad ng pag-unlad sa pamamagitan ng isang simpleng boto ng lahat ng kalahok, na naglalaan ng 3 boto para sa bawat koponan, na maaari nilang ibigay para sa pinakamataas na kalidad ng trabaho. Marahil ay mas mahusay na mag-organisa ng isang hurado.

Ano ang naabot mo?

Bahagyang nalutas namin ang aming problema at ngayon ay mayroon na kaming 4 na matapang at guwapong lalaki na nagtatrabaho para sa amin, na sumasakop sa likuran ng 4 na development team. Hindi pa napapansin ang isang makabuluhang grupo ng mga potensyal na malalakas na kandidato at mga nasasalat na pagbabago sa antas ng komunidad ng QA ng lungsod. Ngunit mayroong ilang pag-unlad at ito ay hindi maaaring hindi magalak.

Pinagmulan: www.habr.com

Magdagdag ng komento