Ovaj članak će biti od interesa za one koji se, poput nas, suočavaju s problemom odabira odgovarajućeg stručnjaka u području testiranja.
Začudo, sa povećanjem broja IT kompanija u našoj republici raste samo broj dostojnih programera, ali ne i testera. Mnogi ljudi su željni da se upuste u ovu profesiju, ali malo njih razumije njeno značenje.
Ne mogu govoriti u ime svih IT kompanija, ali smo dodijelili ulogu QA/QC našim stručnjacima za kvalitet. Oni su dio razvojnog tima i učestvuju u svim fazama razvoja, od istraživanja do izdavanja nove verzije.
Tester u timu, čak iu fazi planiranja, mora razmisliti o svim funkcionalnim i nefunkcionalnim zahtjevima za prihvaćanje korisničke priče. Mora razumjeti operativne karakteristike proizvoda kao i programere, pa čak i bolje, i pomoći timu da ne donosi pogrešne odluke čak iu fazi planiranja. Tester mora imati jasno razumijevanje o tome kako će implementirana funkcionalnost funkcionirati i koje zamke mogu postojati. Naši testeri sami kreiraju planove testiranja i test slučajeve, kao i pripremaju sve potrebne testne stolove. Testiranje prema gotovoj specifikaciji poput majmunskog klikera nije naša opcija. Radeći unutar tima, mora pomoći u puštanju vrijednog proizvoda i oglasiti alarm na vrijeme ako nešto krene po zlu.
Na šta smo naišli kada smo tražili testere
U fazi proučavanja mnogih životopisa, činilo se da postoje stručnjaci sa odgovarajućim iskustvom za nas i neće biti problema s odabirom testera za naš tim. Ali, tokom ličnih sastanaka, sve češće smo nailazili na kandidate koji su zapravo bili prilično udaljeni od svijeta informacionih tehnologija (na primjer, nisu znali principe interakcije između pretraživača i web servera, osnove sigurnosti, relacijske i ne- relacionih baza podataka, nisu imali pojma o virtuelizaciji i kontejnerizaciji), ali su se u isto vreme procenjivali na nivou Senior QA. Nakon više desetina intervjua, došli smo do zaključka da je broj specijalista koji nam odgovaraju u regionu zanemarljiv.
U nastavku ću vam reći koje smo korake poduzeli i na koje greške smo kročili da bismo pronašli te dugo očekivane borce za kvalitet.
Kako smo pokušali da popravimo situaciju
Nakon što smo se iscrpili pronalaženjem gotovih stručnjaka, počeli smo ciljati obližnja područja:
- Pokušali smo da primenimo praksu procene kako bismo među mnogim ljudima koji su „ostavili to“ identifikovali upravo one od kojih možemo razviti jake stručnjake.
Zamolili smo grupu potencijalnih kandidata sa približno istim nivoom znanja da završe zadatke. Posmatrajući njihov misaoni proces, pokušali smo da identifikujemo kandidata koji najviše obećava.
Konkretno, osmislili smo zadatke za testiranje pažnje, razumijevanja mogućnosti tehnologije i karakteristika multikulturalnosti:
- Održali smo sastanke za testere kako bismo proširili granice razumijevanja profesije među postojećim kontingentom.
Reći ću vam ponešto o svakom od njih.
Ufa Software QA and Testing Meetup #1 je naš prvi pokušaj da okupimo one kojima je stalo do profesije i da istovremeno shvatimo da li će javnost biti zainteresovana za ono što želimo da im prenesemo. 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 pridružili profesiji. O tome šta je kvalitet i kako ga postići u realnim uslovima. Takođe, šta je automatsko testiranje i gde ga je prikladnije koristiti.
Zatim smo u razmaku od 1-2 mjeseca održali još dva sastanka. Već je bilo duplo više učesnika. Na “Ufa Software QA and Testing Meetup #2” zaronili smo dublje u predmetnu oblast. Razgovarali su o sistemima za praćenje grešaka, UI/UX testiranju, dotaknuli su se Docker, Ansible, a govorili su i o mogućim sukobima između programera i testera i načinima za njihovo rješavanje.Naš treći sastanak, “Ufa Software QA and Testing Meetup #3”, indirektno se odnosio na rad testera, ali je bio koristan u pravovremenom podsjećanju programera na njihove tehničke i organizacijske dužnosti: testiranje opterećenja, e2e testiranje, Selen u automatskom testiranju, ranjivosti web aplikacija .
Sve ovo vrijeme učili smo kako stvoriti normalno svjetlo i zvuk u prenosima sa naših događaja:
→
→
→ - I na kraju smo odlučili da pokušamo da održimo hakaton za testere
Kako smo pripremili i proveli hakaton za testere
Za početak, pokušali smo shvatiti kakva je to "zvijer" i kako se obično izvodi. Kako se ispostavilo, ovakvi događaji nisu se održavali mnogo puta u Ruskoj Federaciji, a ideje nema odakle posuditi. Drugo, nisam želio odmah uložiti mnogo sredstava u događaj koji je na prvi pogled izgledao sumnjiv. Stoga smo odlučili da radimo kratke mini hakatone, ne za cijeli QA ciklus rada, već za pojedinačne faze.
Naša glavna glavobolja je nedostatak prakse među lokalnim testerima u kreiranju jasnih mapa testiranja. Oni ne troše vrijeme na istraživanje korisničkih priča prije implementacije i kreiranje kriterija prihvatljivosti koji su jasni programerima za funkcionalne i nefunkcionalne zahtjeve, UI/UX, sigurnost, radna opterećenja i vršna opterećenja. Stoga smo po prvi put odlučili da prođemo kroz najzanimljiviji i najkreativniji dio njihovog rada – analizu i formiranje zahtjeva tokom pretprojektnog istraživanja.
Procijenili smo potencijalni broj učesnika i odlučili da nam je potrebno najmanje 5 zaostataka za MVP izdanja, 5 proizvoda i 5 ljudi koji će djelovati kao vlasnici proizvoda, dešifrirati poslovne potrebe i donositi odluke o ograničenjima.
Evo šta smo dobili: .
Osnovna ideja je bila osmisliti teme koje su što dalje od svakodnevnog rada svih učesnika i dati im prostor za kreativni let mašte.
Koje smo greške napravili i šta bismo mogli bolje?
Upotreba praksi procene, tako popularne u oblasti zapošljavanja prodavaca i menadžera nižeg nivoa, zahtevala je ogroman napor, ali nam nije omogućila da posvetimo dovoljno pažnje svakom učesniku i procenimo njegove sposobnosti. Općenito, ova opcija odabira stvara negativan imidž o kompaniji, jer dosta ljudi dobija nedovoljno povratnih informacija i nakon toga stvara kod sebe i kod drugih efekat tiranije poslodavca (komunikacija u IT zajednicama je veoma razvijena). Kao rezultat, preostala su nam bukvalno dva potencijalna kandidata sa veoma dalekom budućnošću.
Sastanci su dobra stvar. Stvara se opsežna osnova za razradu, a opšti nivo učesnika raste. Kompanija postaje sve prepoznatljivija na tržištu. Ali radni intenzitet takvih poduhvata 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š nisu postali dosadni, jer se, za razliku od hakatona za programere, održavaju mnogo rjeđe. Prednost ove ideje je što na opušten način možete razmijeniti veliku količinu praktičnih znanja i prilično precizno odrediti nivo svakog učesnika.
Nakon analize rezultata događaja, shvatili smo da smo napravili mnogo grešaka:
- Najneoprostiva greška bila je vjerovati da će nam 4-5 sati biti dovoljno. Kao rezultat toga, samo upoznavanje i upoznavanje sa zaostalim predmetima trajalo je skoro 2 sata.
Rad sa vlasnicima proizvoda u početnoj fazi i vrijeme da se uroni u predmetnu oblast oduzeli su isto toliko vremena. Dakle, preostalo vrijeme očito nije bilo dovoljno za sveobuhvatan razvoj testnih karata. - Nije bilo dovoljno vremena i energije za detaljne povratne informacije o svakoj karti, jer je već bila noć. Stoga smo očigledno pali u ovom dijelu, ali je prvobitno zamišljeno da budemo najvredniji na hakatonu.
- Odlučili smo da ocijenimo kvalitetu izrade jednostavnim glasanjem svih učesnika, dodijelivši svakom timu po 3 glasa koje su mogli dati za što kvalitetniji rad. Možda bi bilo bolje da se organizuje žiri.
Šta ste postigli?
Djelomično smo riješili naš problem i sada imamo 4 hrabra, zgodna muškarca koji rade za nas, koji pokrivaju stražnji dio 4 razvojna tima. Značajan skup potencijalnih jakih kandidata i opipljive promjene na nivou gradske QA zajednice još nisu uočene. Ali ima nekog pomaka i to ne može a da ne raduje.
izvor: www.habr.com