Miksi järjestimme hackathonin testaajille?

Tämä artikkeli kiinnostaa niitä, jotka, kuten me, kohtaavat ongelman valita sopiva testausalan asiantuntija.

Kummallista kyllä, IT-yritysten määrän kasvaessa tasavallassamme vain kelvollisten ohjelmoijien määrä kasvaa, mutta ei testaajia. Monet ihmiset ovat innokkaita pääsemään tähän ammattiin, mutta monet eivät ymmärrä sen merkitystä.

En voi puhua kaikkien IT-yritysten puolesta, mutta olemme antaneet QA/QC roolin laatuasiantuntijoillemme. He ovat osa kehitystiimiä ja osallistuvat kaikkiin kehitysvaiheisiin tutkimuksesta uuden version julkaisuun.

Testaajan tulee tiimissä jo suunnitteluvaiheessa miettiä läpi kaikki toiminnalliset ja ei-toiminnalliset vaatimukset käyttäjätarinan hyväksymiselle. Hänen tulee ymmärtää tuotteen toiminnalliset ominaisuudet sekä ohjelmoijat ja vielä paremmin ja auttaa tiimiä olemaan tekemässä vääriä päätöksiä jo suunnitteluvaiheessa. Testaajalla tulee olla selkeä käsitys siitä, miten toteutettu toiminnallisuus toimii ja mitä sudenkuoppia siinä voi olla. Testaajamme laativat itse testisuunnitelmat ja testitapaukset sekä valmistelevat kaikki tarvittavat testipenkit. Testaus valmiin spesifikaation mukaan, kuten apinannapsauttamalla, ei ole meidän vaihtoehtomme. Työskennellessään tiimissä hänen on autettava julkaisemaan arvokas tuote ja soitettava hälytys ajoissa, jos jokin menee pieleen.

Mitä kohtasimme etsiessämme testaajia

Monien ansioluetteloiden opiskeluvaiheessa näytti siltä, ​​että meillä oli asiantuntijoita, joilla on meille sopiva kokemus, eikä tiimiimme testerin valinnassa olisi ongelmia. Mutta henkilökohtaisissa tapaamisissa kohtasimme yhä useammin ehdokkaita, jotka olivat itse asiassa melko kaukana tietotekniikan maailmasta (esim. he eivät osaneet kertoa selaimen ja verkkopalvelimen vuorovaikutuksen periaatteita, turvallisuuden perusteita, relaatio- ja ei- relaatiotietokannat, heillä ei ollut aavistustakaan virtualisoinnista ja konteinnista), mutta samalla he arvioivat itsensä Senior QA -tasolla. Kymmenien haastattelujen jälkeen tulimme siihen tulokseen, että meille sopivien asiantuntijoiden määrä alueella on mitätön.

Seuraavaksi kerron teille, mihin toimiin teimme ja mihin virheisiin astuimme löytääksemme kauan odotetut laatutaistelijat.

Miten yritimme korjata tilanteen

Uuvutettuamme itsemme valmiiden asiantuntijoiden hankinnassa, aloimme kohdistaa lähialueille:

1. Yritimme soveltaa arviointikäytäntöjä tunnistaaksemme monien "jätä se" ihmisten joukosta juuri ne, joista voimme kehittää vahvoja asiantuntijoita.

   Pyysimme ryhmää potentiaalisia hakijoita, joilla on suunnilleen sama tietotaso, suorittamaan tehtäviä. Tarkkailemalla heidän ajatteluprosessiaan yritimme tunnistaa lupaavimman ehdokkaan.

   Erityisesti keksimme tehtäviä testataksemme tarkkaavaisuutta, ymmärrystä teknologian kyvyistä ja monikulttuurisuuden piirteistä:

   
   

2. Järjestimme testaajille tapaamisia laajentaaksemme ammatin ymmärtämisen rajoja olemassa olevan joukon keskuudessa.

   Kerron teille hieman jokaisesta niistä.

   Ufa Software QA and Testing Meetup #1 on ensimmäinen yritys koota yhteen ammatista välittävät ja samalla ymmärtää, onko yleisö kiinnostunut siitä, mitä haluamme heille välittää. Pohjimmiltaan raporteissamme oli kyse siitä, mistä on parempi aloittaa, jos olet päättänyt ryhtyä testaajaksi. Auta aloittelijoita avaamaan silmänsä ja katsomaan testausta kuin aikuista. Keskustelimme vaiheista, jotka aloittelevien testaajien tulee ottaa ammattiin liittymiseksi. Mitä laatu on ja miten se saavutetaan todellisissa olosuhteissa. Ja myös, mikä on automaattinen testaus ja missä sitä on tarkoituksenmukaisempaa käyttää.

   
   
   Sitten 1-2 kuukauden välein järjestimme vielä kaksi tapaamista. Osallistujia oli jo kaksi kertaa enemmän. "Ufa Software QA and Testing Meetup #2" -tapahtumassa sukelsimme syvemmälle aihealueeseen. He puhuivat vianseurantajärjestelmistä, UI/UX-testauksesta, koskettivat Dockeria, Ansiblea ja puhuivat myös mahdollisista ristiriidoista kehittäjän ja testaajan välillä ja niiden ratkaisemisesta.

   Kolmas tapaamisemme, "Ufa Software QA and Testing Meetup #3", liittyi epäsuorasti testaajien työhön, mutta oli hyödyllinen muistuttamaan ohjelmoijia ajoissa heidän teknisistä ja organisatorisista tehtävistään: kuormitustestaus, e2e-testaus, seleeni automaattitestauksessa, verkkosovellusten haavoittuvuudet. .

   Koko tämän ajan olemme oppineet luomaan normaalia valoa ja ääntä tapahtumiemme lähetyksiin:

   → Testauksen ensimmäiset askeleet – Ufa Software QA ja Testing Meetup #1
   → UI/UX-testaus – Ufa Software QA ja Testing Meetup #2
   → Turvatestaus, kuormitustestaus ja automaattinen testaus – Ufa QA ja Testing Meetup #3

3. Ja lopulta päätimme yrittää pitää hackathonin testaajille

Kuinka valmistelimme ja toteutimme hackathonin testaajille

Aluksi yritimme ymmärtää, millainen "peto" tämä on ja miten se yleensä suoritetaan. Kuten kävi ilmi, tällaisia ​​tapahtumia ei ole järjestetty monta kertaa Venäjän federaatiossa, eikä ideoita ole mistä lainata. Toiseksi, en halunnut heti investoida paljoa resursseja tapahtumaan, joka vaikutti ensi silmäyksellä epäilyttävältä. Siksi päätimme tehdä lyhyitä minihackathoneja, emme koko laadunvarmistustyösykliä, vaan yksittäisiä vaiheita.

Suurin päänsärkymme on paikallisten testaajien harjoittelun puute selkeiden testauskarttojen luomisessa. He eivät käytä aikaa ennen käyttöönottoa olevien käyttäjätarinoiden tutkimiseen ja hyväksymiskriteerien luomiseen, jotka ovat kehittäjille selvät toiminnallisille ja ei-toiminnallisille vaatimuksille, käyttöliittymälle/UX:lle, tietoturvalle, työkuormille ja huippukuormituksille. Siksi päätimme ensimmäistä kertaa käydä läpi heidän työnsä mielenkiintoisimman ja luovimman osan - analyysin ja vaatimusten muodostuksen esiprojektitutkimuksen aikana.

Arvioimme mahdollisen osallistujamäärän ja päätimme, että tarvitsemme vähintään 5 ruuhkaa MVP-julkaisuihin, 5 tuotetta ja 5 henkilöä, jotka toimisivat tuoteomistajina, selvittävät liiketoiminnan tarpeita ja tekevät päätöksiä rajoituksista.

Tässä on mitä saimme: ruuhkat hackathonille.

Pääideana oli keksiä aiheita, jotka ovat mahdollisimman kaukana kaikesta osallistujien päivittäisestä työstä ja antaa heille tilaa luovalle mielikuvituslennolle.

Mitä virheitä teimme ja mitä voisimme tehdä paremmin?

Myyjien ja alemman tason johtajien palkkaamisessa niin suosittujen arviointikäytäntöjen käyttö vaati valtavasti vaivaa, mutta ei antanut meidän kiinnittää riittävästi huomiota jokaiseen osallistujaan ja arvioida hänen kykyjään. Yleisesti ottaen tämä valintavaihtoehto luo negatiivisen kuvan yrityksestä, koska melko monet ihmiset saavat riittämätöntä palautetta ja luovat myöhemmin itseensä ja muihin työnantajan tyrannian vaikutuksen (viestintä IT-yhteisöissä on erittäin kehittynyttä). Tämän seurauksena meillä on kirjaimellisesti kaksi mahdollista ehdokasta, joilla on hyvin kaukainen tulevaisuus.

Tapaamiset ovat hyvä asia. Muodostuu laaja pohja työstämiselle ja osallistujien yleinen taso nousee. Yrityksestä on tulossa yhä tunnetumpi markkinoilla. Mutta tällaisten yritysten työvoimaintensiteetti ei ole pieni. Sinun on ymmärrettävä selvästi, että tapaamisten pitäminen vie noin 700-800 työtuntia vuodessa.

Mitä tulee testaushackathoniin. Tällaisista tapahtumista ei ole vielä tullut tylsää, sillä toisin kuin kehittäjien hackathoneja, niitä järjestetään paljon harvemmin. Tämän idean etuna on, että voit rennosti vaihtaa suuren määrän käytännön tietoa ja määrittää melko tarkasti jokaisen osallistujan tason.

Tapahtuman tulosten analysoinnin jälkeen huomasimme, että teimme paljon virheitä:

1. Anteeksiantamattomin virhe oli uskoa, että 4-5 tuntia riittäisi meille. Tästä johtuen pelkkä esittely ja ruuhkaan tutustuminen kesti lähes 2 tuntia.
   Alkuvaiheessa työskentely tuotteen omistajien kanssa ja aihealueeseen sukeltamiseen kului yhtä paljon aikaa. Jäljellä oleva aika ei siis selvästikään riittänyt testauskarttojen kattavaan kehittämiseen.
2. Aika ja energia ei riittänyt yksityiskohtaiseen palautteeseen jokaisesta kartasta, koska oli jo yö. Siksi epäonnistuimme selvästi tässä osassa, mutta sen oli alun perin tarkoitus olla hackathonin arvokkain.
3. Päätimme arvioida kehityksen laatua kaikkien osallistujien yksinkertaisella äänestyksellä, jakamalla jokaiselle tiimille 3 ääntä, jotka he saattoivat antaa laadukkaimmasta työstä. Ehkä olisi parempi järjestää tuomaristo.

Mitä olet saavuttanut?

Olemme osittain ratkaisseet ongelmamme ja nyt meillä on töissä 4 rohkeaa, komeaa miestä, jotka kattavat 4 kehitystiimin takaosan. Merkittävää joukkoa mahdollisia vahvoja ehdokkaita ja konkreettisia muutoksia kaupungin laadunvarmistusyhteisön tasolla ei ole vielä havaittu. Mutta edistystä on tapahtunut, ja tämä ei voi muuta kuin iloita.

Lähde: will.com