Ta članek bo zanimiv za tiste, ki se tako kot mi soočamo s problemom izbire ustreznega strokovnjaka na področju testiranja.
Nenavadno je, da se s povečanjem števila IT podjetij v naši republiki povečuje le število vrednih programerjev, ne pa tudi preizkuševalcev. Veliko ljudi si želi v ta poklic, vendar le redki razumejo njegov pomen.
Ne morem govoriti v imenu vseh IT podjetij, vendar smo vlogo QA/QC dodelili našim strokovnjakom za kakovost. So del razvojne ekipe in sodelujejo v vseh fazah razvoja, od raziskav do izdaje nove različice.
Tester v timu mora že v fazi načrtovanja premisliti vse funkcionalne in nefunkcionalne zahteve za sprejem uporabniške zgodbe. Tako kot programerji, še bolje, mora razumeti operativne značilnosti izdelka in pomagati ekipi, da že v fazi načrtovanja ne sprejema napačnih odločitev. Preizkuševalec mora jasno razumeti, kako bo implementirana funkcionalnost delovala in kakšne pasti lahko obstajajo. Naši preizkuševalci sami izdelajo testne načrte in testne primere ter pripravijo vse potrebne testne mize. Testiranje po že pripravljeni specifikaciji kot opičji kliker ni naša možnost. Z delom v ekipi mora pomagati izdati vreden izdelek in pravočasno sprožiti alarm, če gre kaj narobe.
Na kaj smo naleteli pri iskanju preizkuševalcev
Na stopnji preučevanja številnih življenjepisov se je zdelo, da obstajajo strokovnjaki z ustreznimi izkušnjami za nas in ne bo težav pri izbiri preizkuševalca za našo ekipo. Toda med osebnimi srečanji smo vse pogosteje srečevali kandidate, ki so bili dejansko precej oddaljeni od sveta informacijske tehnologije (na primer niso znali povedati principov interakcije med brskalnikom in spletnim strežnikom, osnov varnosti, relacijske in ne- relacijskih podatkovnih bazah, o virtualizaciji in kontejnerizaciji niso imeli pojma), hkrati pa so se ocenjevali na ravni Senior QA. Po opravljenih desetinah intervjujev smo prišli do zaključka, da je število za nas primernih specialistov v regiji zanemarljivo.
V nadaljevanju vam bom povedal, katere korake smo storili in na katere napake smo stopili, da bi našli tiste dolgo pričakovane borce za kakovost.
Kako smo poskušali popraviti situacijo
Ko smo se izčrpali z iskanjem že pripravljenih strokovnjakov, smo začeli ciljati na bližnja območja:
- Poskušali smo uporabiti prakse ocenjevanja, da bi med številnimi »opusti« ljudmi prepoznali prav tiste, iz katerih lahko razvijemo močne strokovnjake.
Za opravljanje nalog smo prosili skupino potencialnih kandidatov s približno enakim nivojem znanja. Ob opazovanju njihovega razmišljanja smo skušali prepoznati najbolj obetavnega kandidata.
Predvsem smo pripravili naloge za preverjanje pozornosti, razumevanja zmogljivosti tehnologije in značilnosti multikulturalizma:
- Organizirali smo srečanja za testerje, da bi razširili meje razumevanja poklica med obstoječim kontingentom.
Povedal vam bom nekaj o vsakem od njih.
Ufa Software QA and Testing Meetup #1 je naš prvi poskus, da zberemo tiste, ki jim ni vseeno za poklic, in hkrati razumemo, ali bo javnost zanimalo, kar jim želimo sporočiti. V bistvu so bila naša poročila o tem, kje je bolje začeti, če ste se odločili postati preizkuševalec. Pomagajte začetnikom odpreti oči in na testiranje gledati kot odrasli. Pogovarjali smo se o korakih, ki jih morajo preizkuševalci začetniki narediti, da se pridružijo poklicu. O tem, kaj je kakovost in kako jo doseči v realnih razmerah. In tudi, kaj je samodejno testiranje in kje ga je bolj primerno uporabiti.
Nato smo v presledku 1-2 mesecev izvedli še dva srečanja. Udeležencev je bilo že dvakrat več. Na "Ufa Software QA and Testing Meetup #2" smo se poglobili v temo. Govorili so o sistemih za sledenje napakam, UI/UX testiranju, dotaknili so se Dockerja, Ansiblea, govorili pa so tudi o morebitnih konfliktih med razvijalcem in testerjem ter načinih njihovega reševanja.Naše tretje srečanje, »Ufa Software QA and Testing Meetup #3,« se je posredno nanašalo na delo preizkuševalcev, vendar je bilo koristno, ker smo programerje pravočasno spomnili na njihove tehnične in organizacijske dolžnosti: testiranje obremenitve, testiranje e2e, Selenium pri samodejnem testiranju, ranljivosti spletnih aplikacij .
Ves ta čas smo se učili ustvarjati normalno svetlobo in zvok v prenosih z naših dogodkov:
→
→
→ - In na koncu smo se odločili, da poskusimo izvesti hackathon za preizkuševalce
Kako smo pripravili in izvedli hackathon za preizkuševalce
Za začetek smo poskušali razumeti, kakšna "zver" je to in kako se običajno izvaja. Kot se je izkazalo, tovrstni dogodki v Ruski federaciji niso bili velikokrat in idej si ni nikjer izposoditi. Drugič, nisem želel takoj vložiti veliko sredstev v dogodek, ki se je na prvi pogled zdel dvomljiv. Zato smo se odločili, da bomo izvajali kratke mini hackathone, ne za celoten QA delovni cikel, ampak za posamezne faze.
Naš glavni glavobol je pomanjkanje prakse med lokalnimi preizkuševalci pri ustvarjanju jasnih zemljevidov testiranja. Ne porabijo časa za raziskovanje uporabniških zgodb pred implementacijo in ustvarjanje meril sprejemljivosti, ki so razvijalcem jasna za funkcionalne in nefunkcionalne zahteve, UI/UX, varnost, delovne obremenitve in največje obremenitve. Zato smo se odločili, da prvič preidemo skozi najbolj zanimiv in kreativen del njihovega dela - analizo in oblikovanje zahtev med predprojektno raziskavo.
Ocenili smo potencialno število udeležencev in se odločili, da potrebujemo vsaj 5 zaostankov za izdaje MVP, 5 produktov in 5 ljudi, ki bodo delovali kot lastniki produkta, dešifrirali poslovne potrebe in odločali o omejitvah.
Tukaj imamo: .
Glavna ideja je bila oblikovati teme, ki so čim bolj oddaljene od vsakodnevnega dela udeležencev in jim dati prostor za ustvarjalni polet domišljije.
Katere napake smo storili in kaj bi lahko storili bolje?
Uporaba ocenjevalnih praks, tako priljubljenih na področju zaposlovanja prodajalcev in nižjih vodij, je terjala ogromno truda, vendar nam ni omogočila, da bi se vsakemu udeležencu posvetili dovolj in ocenili njegove sposobnosti. Na splošno ta možnost izbire ustvarja negativno podobo podjetja, saj veliko ljudi prejme premalo povratnih informacij in posledično ustvari pri sebi in pri drugih učinek tiranije delodajalca (komunikacije v IT skupnostih so zelo razvite). Posledično nam ostaneta dobesedno dva potencialna kandidata z zelo oddaljeno prihodnostjo.
Srečanja so dobra stvar. Ustvarja se obsežna podlaga za izpopolnjevanje in splošna raven udeležencev se dviguje. Podjetje postaja vse bolj prepoznavno na trgu. Toda delovna intenzivnost takšnih podjetij ni majhna. Jasno morate razumeti, da bo organizacija srečanj trajala približno 700-800 delovnih ur na leto.
Kar se tiče testnega hackathona. Tovrstni dogodki še niso postali dolgočasni, saj se za razliko od hekatonov za razvijalce izvajajo veliko manj pogosto. Prednost te ideje je v tem, da lahko na sproščen način izmenjate ogromno praktičnega znanja in precej natančno določite nivo posameznega udeleženca.
Po analizi rezultatov dogodka smo ugotovili, da smo naredili veliko napak:
- Najbolj neoprostljiva napaka je bila verjeti, da nam bo 4-5 ur zadostovalo. Tako je samo uvajanje in seznanitev z zaostanki trajalo skoraj 2 uri.
Enako sta trajala delo z lastniki izdelkov na začetni stopnji in čas za poglobitev v predmetno področje. Preostali čas torej očitno ni bil dovolj za celovit razvoj testnih zemljevidov. - Za podrobne povratne informacije o vsaki karti ni bilo dovolj časa in energije, saj je bila že noč. Zato nam ta del očitno ni uspel, a je bil sprva mišljen kot najdragocenejši v hackathonu.
- Odločili smo se, da bomo kakovost razvoja ocenili z enostavnim glasovanjem vseh sodelujočih, pri čemer smo vsaki ekipi namenili 3 glasove, ki bi jih lahko dali za najkakovostnejše delo. Morda bi bilo bolje organizirati žirijo.
Kaj si dosegel?
Našo težavo smo delno rešili in zdaj za nas delajo 4 pogumni, čedni moški, ki pokrivajo zadek 4 razvojnih ekip. Pomembnega nabora potencialno močnih kandidatov in oprijemljivih sprememb na ravni mestne QA skupnosti še ni bilo opaziti. Vendar je nekaj napredka in to ne more razveseliti.
Vir: www.habr.com