Ovaj će članak biti od interesa za one koji se, poput nas, suočavaju s problemom odabira odgovarajućeg stručnjaka u području testiranja.
Začudo, povećanjem broja informatičkih tvrtki u našoj republici povećava se samo broj vrijednih programera, ali ne i testera. Mnogi ljudi jedva čekaju ući u ovu profesiju, ali malo njih razumije njezino značenje.
Ne mogu govoriti u ime svih IT tvrtki, ali dodijelili smo ulogu QA/QC našim stručnjacima za kvalitetu. Oni su dio razvojnog tima i sudjeluju u svim fazama razvoja, od istraživanja do izdavanja nove verzije.
Tester u timu, već u fazi planiranja, mora promisliti sve funkcionalne i nefunkcionalne zahtjeve za prihvaćanje korisničke priče. Mora razumjeti operativne karakteristike proizvoda kao i programeri, pa čak i bolje, te pomoći timu da ne donosi pogrešne odluke već u fazi planiranja. Ispitivač mora jasno razumjeti kako će implementirana funkcionalnost funkcionirati i koje zamke mogu postojati. Naši testeri sami izrađuju planove testiranja i testne slučajeve, kao i pripremaju sve potrebne ispitne klupe. Testiranje po gotovim specifikacijama poput majmunskog klikera nije naša opcija. Radeći unutar tima, on mora pomoći u izdavanju vrijednog proizvoda i na vrijeme oglasiti alarm ako nešto pođe po zlu.
Na što smo naišli tražeći testere
U fazi proučavanja mnogih životopisa, činilo se da postoje stručnjaci s odgovarajućim iskustvom za nas i da neće biti problema s odabirom testera za naš tim. No, tijekom osobnih susreta sve smo češće nailazili na kandidate koji su zapravo bili dosta udaljeni od svijeta informacijske tehnologije (primjerice, nisu znali reći principe interakcije između preglednika i web poslužitelja, osnove sigurnosti, relacijske i ne- relacijske baze podataka, nisu imali pojma o virtualizaciji i kontejnerizaciji), ali su se istovremeno ocjenjivali na razini Senior QA. Nakon obavljenih desetaka razgovora došli smo do zaključka da je broj nama podobnih specijalista u regiji zanemariv.
Zatim ću vam reći koje smo sve korake poduzeli i na kojim smo greškama gazili kako bismo pronašli te dugo očekivane borce za kvalitetu.
Kako smo pokušali popraviti situaciju
Nakon što smo se iscrpili traženjem gotovih stručnjaka, počeli smo ciljati obližnja područja:
- Pokušali smo primijeniti praksu ocjenjivanja kako bismo među mnogim "ostavljenim" ljudima identificirali upravo one od kojih možemo razviti snažne stručnjake.
Za rješavanje zadataka zamolili smo skupinu potencijalnih kandidata s približno istim stupnjem znanja. Promatrajući njihov proces razmišljanja, pokušali smo identificirati kandidata koji najviše obećava.
Konkretno, osmislili smo zadatke za testiranje pažnje, razumijevanja mogućnosti tehnologije i značajki multikulturalizma:
- Održali smo susrete za testere kako bismo proširili granice razumijevanja profesije među postojećim kontingentom.
Reći ću vam nešto o svakom od njih.
Ufa Software QA and Testing Meetup #1 naš je prvi pokušaj da okupimo one kojima je struka stalo, a ujedno shvatimo hoće li javnost biti zainteresirana za ono što im želimo prenijeti. Uglavnom, naši izvještaji su bili o tome gdje je bolje početi ako ste odlučili postati tester. Pomozite početnicima da otvore oči i gledaju na testiranje kao odrasli. Razgovarali smo o koracima koje testeri početnici moraju poduzeti da bi se uključili u profesiju. O tome što je kvaliteta i kako je postići u stvarnim uvjetima. Također, što je automatsko testiranje i gdje ga je prikladnije koristiti.
Zatim smo u razmaku od 1-2 mjeseca održali još dva susreta. Već je bilo dvostruko više sudionika. Na “Ufa Software QA and Testing Meetup #2” zaronili smo dublje u predmetno područje. Razgovarali su o sustavima za praćenje grešaka, UI/UX testiranju, dotakli se Dockera, Ansiblea, a govorili su i o mogućim sukobima između developera i testera te načinima za njihovo rješavanje.Naš treći sastanak, “Ufa Software QA and Testing Meetup #3,” neizravno se odnosio na rad testera, ali je bio koristan jer je programere pravovremeno podsjetio na njihove tehničke i organizacijske dužnosti: testiranje opterećenja, e2e testiranje, Selenium u automatskom testiranju, ranjivosti web aplikacija .
Sve ovo vrijeme učili smo kako stvoriti normalno svjetlo i zvuk u prijenosima s naših događaja:
→
→
→ - I na kraju smo odlučili pokušati održati hackathon za testere
Kako smo pripremili i proveli hackathon za testere
Za početak, pokušali smo shvatiti kakva je to "zvijer" i kako se obično provodi. Kako se pokazalo, događaji ove vrste nisu se održavali mnogo puta u Ruskoj Federaciji, a nema se gdje posuditi ideje. Drugo, nisam želio odmah uložiti puno sredstava u događaj koji je na prvi pogled djelovao dvojbeno. Stoga smo odlučili da ćemo raditi kratke mini-hackathone, ne za cijeli QA ciklus rada, već za pojedinačne faze.
Naša glavna glavobolja je nedostatak prakse među lokalnim ispitivačima u stvaranju jasnih mapa testiranja. Oni ne troše vrijeme na istraživanje korisničkih priča prije implementacije i stvaranje kriterija prihvaćanja koji su jasni programerima za funkcionalne i nefunkcionalne zahtjeve, UI/UX, sigurnost, radna opterećenja i vršna opterećenja. Stoga smo odlučili po prvi put proći kroz najzanimljiviji i najkreativniji dio njihovog rada - analizu i formiranje zahtjeva tijekom predprojektnog istraživanja.
Procijenili smo potencijalni broj sudionika i zaključili da nam treba najmanje 5 backlogova za MVP izdanja, 5 proizvoda i 5 ljudi koji bi bili vlasnici proizvoda, dešifrirali poslovne potrebe i donosili odluke o ograničenjima.
Evo što smo dobili: .
Glavna ideja bila je osmisliti teme koje su što dalje od svakodnevnog rada svih sudionika i dati im prostora za kreativni let mašte.
Koje smo pogreške napravili i što bismo mogli učiniti bolje?
Korištenje praksi ocjenjivanja, tako popularnih u području zapošljavanja prodavača i nižih menadžera, iziskivalo je ogroman trud, ali nam nije omogućilo da svakom sudioniku posvetimo dovoljno pažnje i ocijenimo njegove sposobnosti. Općenito, ova opcija odabira stvara negativnu sliku o tvrtki, budući da dosta ljudi dobiva nedovoljno povratnih informacija i posljedično kod sebe i kod drugih stvara učinak tiranije poslodavca (komunikacije u IT zajednicama su vrlo razvijene). Kao rezultat toga, ostala su nam doslovno dva potencijalna kandidata s vrlo dalekom budućnošću.
Sastanci su dobra stvar. Stvara se opsežna osnova za razradu, a povećava se opća razina sudionika. Tvrtka postaje sve prepoznatljivija na tržištu. No radni intenzitet takvih pothvata nije mali. Morate jasno shvatiti da će održavanje sastanaka trajati otprilike 700-800 radnih sati godišnje.
Što se tiče testiranja hackathona. Ovakvi događaji još uvijek nisu dosadili jer se, za razliku od hackathona za programere, održavaju mnogo rjeđe. Prednost ove ideje je što se na opušten način može razmijeniti velika količina praktičnih znanja i prilično točno odrediti razina svakog polaznika.
Nakon analize rezultata događaja, shvatili smo da smo napravili puno grešaka:
- Najneoprostivija greška bila je vjerovati da će nam 4-5 sati biti dovoljno. Samim time samo upoznavanje i upoznavanje sa zaostacima trajalo je gotovo 2 sata.
Rad s vlasnicima proizvoda u početnoj fazi i vrijeme za uranjanje u predmetno područje oduzeli su jednako vrijeme. Dakle, preostalo vrijeme očito nije bilo dovoljno za sveobuhvatan razvoj mapa testiranja. - Nije bilo dovoljno vremena i energije za detaljne povratne informacije o svakoj karti, jer je već bila noć. Stoga smo očito podbacili ovaj dio, ali je u početku trebao biti najvrjedniji na hackathonu.
- Odlučili smo ocjenjivati kvalitetu izrade jednostavnim glasovanjem svih sudionika, pri čemu smo svakom timu dodijelili po 3 glasa koliko su mogli dati za najkvalitetniji rad. Možda bi bilo bolje organizirati žiri.
Što ste postigli?
Djelomično smo riješili problem i sada za nas rade 4 hrabra, zgodna muškarca koji pokrivaju začelje 4 razvojna tima. Značajan skup potencijalno jakih kandidata i opipljive promjene u razini QA zajednice u gradu još nisu primijećene. Ali postoji određeni napredak i to ne može nego radovati.
Izvor: www.habr.com