Intervju s Klavdijo Blatnik, Vodja enote Zagotavljanje kakovosti programske opreme v Mikrocopu
V svetu, kjer podjetja vsak dan obdelajo na tisoče dokumentov, se napake ne merijo le v izgubljenih minutah. Lahko pomenijo zamujene roke, napačne odločitve ali celo izgubo zaupanja. Zato pri razvoju InDoc EDGE ni prostora za naključja – a tudi iluzij o popolnosti ne gojimo.
Vsaka nadgradnja, vsaka funkcionalnost in vsaka vrstica kode gre skozi preverjanje, da bi čim prej odkrili, kar bi lahko povzročilo težavo. To delo opravlja ekipa za zagotavljanje kakovosti (QA), ki s svojo natančnostjo in odgovornostjo skrbi, da morebitne napake ne ostanejo neopažene in da se jih odpravi čim hitreje.
Klavdija, QA ekipa pogosto deluje v ozadju. Kako bi opisala njen pomen za delovanje InDoc EDGE platforme?
Res je, naše delo se direktno ne vidi, a brez njega InDoc EDGE ne bi bil to, kar je.
Naš glavni cilj je, da napake odkrijemo pravočasno in da se uporabniku ob vsakem kliku zgodi točno tisto, kar pričakuje.
Napake, ki se pojavijo v poznejših fazah ali šele pri uporabniku, so zahtevnejše in tudi dražje za odpravo. Zato vsako novo funkcionalnost ali spremembo funkcionalnosti najprej temeljito preverimo, da do uporabnika pride le stabilna in preverjena rešitev. Tako poskrbimo, da so nadgradnje varne in da uporabniki lahko neprekinjeno opravljajo svoje delo.
V bistvu smo zadnja kontrolna točka pred tem, ko nekaj postane del vsakodnevne uporabe. Sigurno ne moremo zajeti vsega, lahko pa zagotovimo, da večina kritičnih napak nikoli ne pride do uporabnikov. S tem zmanjšujemo tveganja, preprečujemo izpade in zagotavljamo zanesljivost, ki jo uporabniki pričakujejo od poslovno-kritične platforme.
Torej cilj ni popolnost, ampak zanesljivost?
Tako je. Pri tako kompleksnem sistemu, kot je InDoc EDGE, popolnosti preprosto ni. A to ne pomeni, da se z njo ne ukvarjamo. Naš cilj je, da tveganja čim bolj zmanjšamo in da se znamo hitro odzvati, ko se napaka pojavi.
Pomembno je, da imamo dober vpogled v sistem in vse procese, da razumemo, kje so možni vplivi in kako jih obvladati. Vsak popravek ali nadgradnja je priložnost, da nekaj izboljšamo.
Kako v praksi poteka vaše delo, ko pride nova funkcionalnost?
Ko razvoj zaključi novo funkcionalnost, jo prevzame QA ekipa. Dobro preberemo zahtevo in moramo razumeti, kaj je bilo narejeno ter kako bi to lahko vplivalo na druge dele sistema.
Sledi ročno testiranje, kjer preverimo različne scenarije – pozitivne, negativne in vse možne robne primere. Če je možno, so testni scenariji pripravljeni vnaprej, drugače pa se pišejo sproti in so vključeni v vsako nadaljnjo testiranje verzije. Za testiranje uporabljamo različna orodja. Če je funkcionalnost primerna za avtomatizacijo, pripravimo tudi avtomatske teste, ki se avtomatsko prožijo 1x dnevno.
To pomeni, da vedno testiramo na dveh ravneh – s človeškim vpogledom in s tehnologijo, ki preverja podrobnosti. Kombinacija obojega nam daje največjo možno zanesljivost, saj ročno testiranje prinaša razumevanje uporabniške izkušnje, avtomatizirano testiranje pa zagotavlja ponovljivost in stalno preverjanje stabilnosti sistema.
“Vsaka sprememba nosi določeno tveganje. Ena vrstica kode lahko vpliva na tisoče uporabnikov ali dokumentov. Naša naloga je, da to ne pride do produkcije.”
Kaj pa, ko se kljub vsemu kaj izmuzne?
Tudi to se zgodi in to je popolnoma normalno. Ključno je, kako hitro in učinkovito odreagiraš.
Ko se odkrije napaka, jo natančno opišemo, prijavimo v sistem in jo skupaj z razvojem analiziramo. Po odpravi sledi ponovno testiranje da preverimo, ali sprememba deluje in ne vpliva na druge funkcionalnosti. Če se napaka ponavlja, prilagodimo testne scenarije, da se nam to več ne ponovi.
“Popolnosti pri tako kompleksnih sistemih ni, a pomembno je, da vsako napako odkrijemo in jo čim prej odpravimo.”
Kako dolgo običajno traja testiranje?
Odvisno od obsega spremembe. Manjše teste lahko opravimo v enem dnevu, večji in kompleksnejši lahko trajajo več dni. Točen čas težko ocenimo, saj se včasih med testiranjem odkrijejo nove težave, ki zahtevajo dodaten pregled in usklajevanje z razvojem.
Zato moraš biti pripravljen na prilagajanje in konstantno dinamiko.
Kakšen pomen ima komunikacija med QA in razvojem?
Ogromen. Sodelovanje med QA in razvojem je ključno. Z razvojem smo v stalnem stiku, sodelujemo že pri načrtovanju funkcionalnosti, izmenjujemo predloge in skupaj rešujemo neznanke. Pomembno je, da si odkrito povemo, če nekaj ni jasno, in da se stvari ne prepuščajo naključju. Na koncu imamo vsi isti cilj - da uporabnik dobi stabilen, preverjen izdelek.
Kako pa sodelujete z drugimi ekipami in s strankami?
Z drugimi ekipami sodelujemo po potrebi, največ pa s produktnima vodjema, podporo in poslovnimi rešitvami.
Tudi povratne informacije strank so pomembne. Stranke sodelujejo predvsem v fazi testiranja na demo okoljih, kjer preizkušajo svoje integracije in prilagoditve. Takrat se včasih pokažejo posebnosti, ki jih mi ne moremo vedno predvideti, ker nimamo vpogleda v zunanje sisteme.
Ko stranka prijavi napako, gre ta najprej skozi sistem podpore (PIS), kjer se določi, ali gre za napako, izboljšavo ali novo zahtevo. Te situacije so zelo koristne, ker pokažejo, kako InDoc EDGE deluje v praksi, ne le v kontroliranem testnem okolju. QA se vključi, ko je pripravljena rešitev, in preveri, ali odprava res deluje.
Kakšne so največje spremembe, ki ste jih v zadnjih letih uvedli v QA proces?
Veliko smo avtomatizirali in bolj jasno razmejili faze testiranja. Danes imamo sistem, kjer se del testov sproži avtomatsko ob vsaki spremembi v kodi, kar nam omogoča sprotno preverjanje stabilnosti sistema. Kljub temu človeški faktor ostaja ključen. Avtomatika ne more nadomestiti intuicije, ki jo razviješ z izkušnjami, torej občutka, kje se lahko nekaj zalomi in zakaj. Zato vedno kombiniramo oboje: tehnologijo in izkušene ljudi.
Zdaj pa še iz drugega zornega kota – dela v QA ekipi. Kdo se v njej najbolje znajde?
Tisti, ki razmišlja analitično in ima rad red. Tisti, ki ga zanima, zakaj nekaj deluje ali pa ne deluje. Tisti, ki je radoveden, natančen in rad raziskuje. Ključno je tudi pridobivanje novih znanj, interno in širše.
Kakšna znanja in pristop so po tvoje ključni za delo v QA ekipi?
V QA svetu ne potrebuješ nujno programerske izobrazbe, potrebuješ pa logiko, vztrajnost in pozornost do detajlov. Seveda pomaga poznavanje osnov SQL-a, poznavanje programskega ali skriptnega jezika in razumevanje, kako delujejo sistemi v ozadju, a enako pomembno je razmišljanje iz uporabniške perspektive.
Dobrodošli so vsi, ki radi rešujejo uganke in ne odnehajo, dokler ne odkrijejo vzroka.
Delo testerja ni “klikati gumbe” - je raziskovanje, razmišljanje in predvidevanje, kaj bi lahko šlo narobe in kaj lahko še izboljšamo.
In predvsem, pripravljenost se učiti. V QA se nikoli ne nehaš učiti, ker se sistem, produkt in tehnologije stalno spreminjajo.
Kako poteka uvajanje novih članov v ekipo?
Če pride nekdo brez izkušenj, potrebuje približno pol leta, da osvoji osnove, in približno leto dni, da postane samostojen. Nov član ekipe začne z osnovami testiranja in spoznavanjem logike sistema, nato pa pod mentorstvom postopoma prevzema zahtevnejše naloge.
Imamo strukturiran mentorski program, gradiva, testne scenarije in interno Wiki-dokumentacijo.
Mentorstvo ni formalnost, ampak dejanska podpora – učimo logiko, ne le postopkov.
Kaj bi svetovali nekomu, ki želi delati v QA ekipi?
Da mora biti potrpežljiv, radoveden in logičen. Mora ga zanimati, zakaj nekaj deluje in zakaj ne. Tudi če nima tehničnega zaledja, se lahko hitro nauči. Seveda če ima pravi pristop.
V QA ne iščemo popolnosti, ampak zanesljivosti, natančnosti in želje po razumevanju.
Kaj pa vas pri tem delu najbolj motivira?
Najlepši del je občutek, ko z našim delom preprečimo težavo. To, da nekaj izboljšamo, da sistem deluje bolj gladko, ali da uporabnik ne opazi, da se je sploh kaj spremenilo. Takrat veš, da si naredil nekaj prav.
»Delo je dinamično in zelo raznoliko, vsaka verzija prinese nekaj novega. In prav to me žene naprej.«
Kaj bi izpostavili kot največjo vrednost vaše ekipe?
Zanesljivost in sodelovanje. Vsak ve, da njegovo delo neposredno vpliva na izdelek. Ko QA reče “pretestirano je”, pomeni, da za tem stoji cela ekipa in ogromno preverjanj.
Ne zagotavljamo popolnosti, ampak odgovornost, odzivnost in zaupanje, ki ga sistem potrebuje, da lahko uporabniki mirno delajo naprej
