Coders Lab intervju: Simon Šerbetar o ročnem testiranju

1. Kaj vas je pritegnilo v svet programskega testiranja in kako bi popolnega začetnika navdušili nad tem poklicem?

 Tukaj sem pristal po naključju, vendar sem sčasoma ugotovil, da si lahko v tej niši zgradim dobro in zanimivo kariero. Vse je nekoliko pogojeno od okolja in organizacije, v kateri delamo, vendar načeloma kot QA-jevci delamo na več projektih naenkrat, posledično stopimo v stik z več produkti in različnimi ekipami. Ta rotacija nam omogoča redno pridobivanje novih izkušenj. Vsi pa vemo, da v IT-svetu te pomenijo več kot vse druge metrike.

2. Zakaj menite, da je ročno testiranje kljub naraščanju avtomatiziranih orodij za testiranje še vedno ključno v življenjskem ciklu razvoja programske opreme?

 Knjižnice in ogrodja za avtomatsko testiranje so odličen dodatek za vsakega QA-jevca, vendar so na začetku in v zgodnjih fazah projektov nesmiselni, zato ker se projekt spreminja, raste in deluje v nestabilnem okolju, ta orodja pa v takšnih pogojih dostikrat zatajijo. Tu se lahko najbolj zanesemo na ročne teste in metodologije, ki si jih zastavimo. Ključni dejavnik je čas, saj je vzpostavitev avtomatskega testa veliko bolj časovno intenzivna kot preprost ročni test, kjer sami izvedemo neko akcijo in se prepričamo, ali stvar deluje tako, kot je bila zastavljena v fazi načrtovanja. Stvar lahko posplošimo nekako takole: samo zato ker imaš doma traktor, še ne pomeni, da z njim orješ vrtiček za hišo. Vsa orodja imajo svoj namen in čas, ko jih je smiselno uporabiti.

3. Kako zagotovite, da študenti razumejo tako teoretično znanje kot tudi praktične veščine, potrebne za ročno testiranje?

Kot pri vseh drugih stvareh: z vajo. Stvar je treba preizkusiti čim prej in čim pogosteje. Le tako se znanje konsolidira v naših glavah. Če se na primer pogovarjamo o API-klicih, je smiselno odpreti konzolo v brskalniku in si jih ogledati, potem pa jih sprožimo še sami. Če govorimo o pisanju testnih scenarijev, odpremo aplikacijo in začnemo pisati oziroma dokumentirati korake, ki jih je treba izvesti. Potem pa narejeno seveda preučimo in se vprašamo, kaj je dobro in kaj bi lahko še izboljšali.

4. Ali obstajajo kake napačne predstave oz. miti o ročnem testiranju, ki bi jih želeli nasloviti?

Marsikdo meni, da je ročno testiranje dolgočasno in monotono. Vendar je to popolnoma odvisno od projekta in faze, v kateri je projekt. V različnih časih so pred nami različni izzivi, ti so včasih zelo zanimivi, kot sta na primer pisanje kode za avtomatske teste ali iskanje in replikacija kompleksnih »bugov«, včasih pa moramo pripravljati projektno dokumentacijo ali testne scenarije za regresijo, kjer ni vedno prostora za kreativnost.

5. Kako poudarjate pomembnost komunikacije med testerji in razvijalci v realnem okolju?

Sodelovanje testne ekipe z razvojno je ključnega pomena pri pravočasnem odpravljanju napak. Agilni razvoj, ki je danes dejansko standard v IT-svetu, narekuje, da ekipe delajo v krajših ciklih, kjer nenehno izboljšujejo izdelek in se prilagajajo spremembam iz produktne ekipe. To posledično pomeni, da razvijalci nimajo toliko časa za testiranje. Tukaj nastopijo testne ekipe, ki izdelek temeljito stestirajo in ugotovitve sporočajo razvojni ekipi.

6. Ali lahko delite primer še posebej zahtevne napake ali težave, s katero ste se srečali, in kako je bilo testiranje ključno pri njenem prepoznavanju?

To so ponavadi napake najhujše vrste, tiste, ki pridejo iz produkcije oziroma jih prijavijo uporabniki aplikacije. Tukaj je treba najprej reproducirati prijavljeno napako, kar pa je ponavadi precej zahtevno, saj uporabniki ne razmišljajo na enak način kot razvijalci in QA-ejevci. Njihov opis napake je pogosto skop in nenatančen. Zadeva je ponavadi videti tako: »V aplikaciji ne morem izdati PDF-naročilnice.« Tu se potem pojavi težava, ker ima takšna aplikacija veliko mest, kjer se lahko ta akcija sproži. Delo testerja je, da najde to mesto in potem poskuša najti kombinacijo vnosov, ki sproži napako. V veliko pomoč je, če se postavimo v vlogo uporabnika. Moramo se vprašati, v kakšnem okolju je uporabil/-a naš produkt. Dejavniki, kot so strojna oprema, operacijski sistem in čas uporabe, lahko vplivajo na delovanje produkta. 

7. Kako se je testiranje programske opreme razvijalo skozi leta?

Testiranje sega v 50. leta prejšnjega stoletja, lahko bi rekli, da se začne s Turingovim testom. Skozi naslednja desetletja pa se v tehnični literaturi in raznih publikacijah omenjajo razne testne ekipe. Z razvojem modernih programskih jezikov in orodij pa so se razvila tudi orodja za testiranje, tukaj imam v mislih predvsem Selenium. Danes si tržni delež večajo orodja, kot so Playwright in Cypress, zgrajena z node.js in javascriptom. 

8. Poleg tehnične strani, katere druge veščine menite, da so ključne za uspeh testerja v ekipnem okolju?

Če bi jih kar naštel, bi šlo tako nekako:

• zbranost: tester mora biti sposoben ostati osredotočen med testiranjem programske opreme, le tako lahko potrdi ali zavrže, da nekaj deluje pravilno,
• iznajdljivost: včasih nekega testa ne moremo izvesti zaradi določenih omejitev okolja, v katerem testiramo, in takrat je treba razmišljati mimo okvirjev in je treba najdi rešitev,
• temeljitost: naša naloga je, da najdemo čim več napak, preden produkt potuje v »resnični svet«, 
• komunikativnost: napake in dognanja moramo učinkovito in razločno razložiti drugim članom ekipe.

9. IT-industrija se nenehno razvija. Kako priporočate, da testerji ostanejo na tekočem in sledijo najnovejšim metodologijam?

Dober tester je ta, ki razume, kako deluje njegov produkt. To pomeni, da ima makro razumevanje o celotnem sistemu, v katerem njegov produkt deluje. V praktičnem primeru to pomeni, da ima nekaj znanja o programiranju in razume, kaj so gradniki takšnega sistema. Tukaj govorimo predvsem o osnovah spletnih aplikacij, podatkovnih bazah in komunikacijskih protokolih na spletu. Dobro je, da imamo širok spekter znanja, da smo neke vrste T-shaped person, torej da vemo nekaj malega o vsem in zelo veliko o eni nišni zadevi. To znanje najlažje pridobimo z uporabo kakšnega novega programskega jezika, hobi projektom, kjer sami poskušamo nekaj zgraditi. Potem slej ko prej naletimo na napake in pridobimo novo znanje, ko napake poskušamo odpraviti. 

10. Ali obstaja izkušnja iz vaše kariere, ki jo delite s svojimi študenti, da bi prikazali pomen testiranja?

Pomen testiranja je v osnovi izboljševanje produkta in krajšanje razvojnega cikla tega produkta. Napake je veliko lažje popraviti v fazi razvoja, ker se takrat naš produkt še ne uporablja v produkciji. Ko enkrat produkt pošljemo v svet, pa je odpravljanje napak veliko bolj mukotrpno. Takrat moramo poskrbeti, da nov popravek ne poruši sistema, da uporabniki ne izgubijo dostopa do produkta in še marsikaj drugega. Pri svojem delu imam kar nekaj izkušenj, kjer smo s pravočasnim in namenskim testiranjem odkrili napake ali pa napačno implementirane funkcionalnosti. Posledično smo s tem prihranili denar in čas.