Zanesljivost ni naključje. Je rezultat načina dela.
V sistemih, kjer dokumenti predstavljajo obveznosti, odločitve in skladnost, napaka ni le neprijetnost. Pomeni zamujene roke, napačne odločitve, izgubo pregleda nad procesi. »Naš glavni cilj je, da napake odkrijemo pravočasno in da se uporabniku ob vsakem kliku zgodi točno tisto, kar pričakuje,« razlaga Klavdija Blatnik, Vodja enote za zagotavljanje kakovosti programske opreme v Mikrocopu.
Zadnja kontrolna točka pred produkcijo
QA ekipa je vključena v vsak korak razvoja InDoc EDGE, ne samo na koncu. »V bistvu smo zadnja kontrolna točka pred tem, ko nekaj postane del vsakodnevne uporabe,« pojasnjuje Klavdija. »Sigurno ne moremo zajeti vsega, lahko pa zagotovimo, da večina kritičnih napak nikoli ne pride do uporabnikov.«
Napake, odkrite v poznih fazah ali šele pri stranki, so zahtevnejše in dražje za odpravo. Zato ekipa vsako novo ali spremenjeno funkcionalnost temeljito preveri, preden gre v produkcijo.
Vsaka sprememba nosi tveganje - tudi majhna
InDoc EDGE ni statičen sistem. Ob vsaki nadgradnji, novi funkcionalnosti ali integraciji se kaj spremeni. In vsaka sprememba, četudi majhna, lahko vpliva na dele sistema, ki na prvi pogled sploh niso povezani.
"Ena vrstica kode lahko vpliva na tisoče uporabnikov ali dokumentov. Naša naloga je, da to ne pride do produkcije."
Na primer: ob nadgradnji se lahko zgodi, da se procesi v ozadju ne sprožijo pravilno. Brez sistematičnega testiranja takšno napako pogosto odkrije šele uporabnik.
Kako v praksi poteka testiranje nove funkcionalnosti
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,« razlaga Klavdija.
Sledi ročno testiranje vseh scenarijev - pozitivnih, negativnih in robnih primerov. Testni scenariji so pripravljeni vnaprej, kjer je to mogoče, sicer se pišejo sproti in so del vseh prihodnjih testiranj verzije.
Kjer je to smiselno, ekipa pripravi tudi avtomatizirane teste, ki se prožijo enkrat dnevno, ne glede na to, ali je bila sprememba v sistemu ali ne. »To pomeni, da morebitne napake odkrijemo sprotno, ne šele ob naslednji nadgradnji,« dodaja Klavdija.
- Funkcionalno testiranje – ali posamezne funkcionalnosti delujejo skladno z zahtevami
- Integracijsko testiranje – ali pravilno deluje med povezanimi moduli
- Sistemsko testiranje – delovanje aplikacije kot celote v realnem okolju
- Regresijsko testiranje – ali posodobitve ne vplivajo na že delujoče dele sistema
- Obremenitveno testiranje – odziv sistema pod večjo obremenitvijo
- Varnostno testiranje – preverjanje dostopov, avtorizacij in zaščite podatkov
Ročno in avtomatizirano: kombinacija, ki je ne moremo nadomestiti
»Avtomatika ne more nadomestiti intuicije, ki jo razviješ z izkušnjami - občutka, kje se lahko nekaj zalomi in zakaj,« pravi Klavdija. Zato ekipa vedno kombinira oba pristopa.
Ročno testiranje prinaša razumevanje uporabniške izkušnje in iskanje robnih primerov. Avtomatizirano testiranje zagotavlja ponovljivost in stalno preverjanje stabilnosti. Samo eden od pristopov ni dovolj.
Sodelovanje, ki razkrije realne scenarije
Tudi najboljše interno testiranje pa ne more simulirati vseh realnih situacij. Del testiranja poteka tudi v sodelovanju s strankami.
Stranke v demo okoljih testirajo svoje procese, integracije in specifične scenarije. To pogosto razkrije odvisnosti od drugih sistemov, posebnosti v procesih in robne primere, ki jih ni bilo mogoče predvideti
To ni napaka procesa. To je realnost kompleksnih sistemov. Zato je zanesljivost vedno rezultat:
notranjih preverjanj,
realne uporabe,
hitrega odziva na odkrita odstopanja.
Ko stranka prijavi napako, gre ta najprej skozi sistem podpore, kjer se določi, ali gre za napako, izboljšavo ali novo zahtevo. QA se vključi, ko je rešitev pripravljena, in potrdi, ali popravek res deluje.
Ko se napaka vseeno zgodi: postopek, ne panika
»Tudi to se zgodi in to je popolnoma normalno,« pravi Klavdija. »Ključno je, kako hitro in učinkovito odreagiraš.«
Ko je napaka odkrita, jo ekipa natančno opiše, prijavi v sistem in skupaj z razvojem analizira vzrok. Po odpravi sledi ponovno testiranje - ne samo napake, ampak tudi njenih možnih vplivov na sistem. Če se napaka ponavlja, se prilagodijo testni scenariji.
"Ko QA reče 'pretestirano je', pomeni, da za tem stoji cela ekipa in ogromno preverjanj."
Cilj ni popolnost ampak zanesljivost in odzivnost
»Pri tako kompleksnem sistemu, kot je InDoc EDGE, popolnosti preprosto ni,« je neposredna Klavdija. »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.«
Za organizacijo, ki obdeluje tisoče dokumentov na dan, to pomeni manj prekinitev, manj nepredvidenih situacij in lažje dokazovanje skladnosti. To ni samo boljša uporabniška izkušnja - to je razlika med sistemom, ki mu zaupate, in sistemom, pri katerem samo upate, da deluje.
Vir: Ta blog je nastal na osnovi pogovora s Klavdijo Blatnik, vodjo enote zagotavljanja kakovosti v Mikrocopu. Celoten intervju si preberite na posebni spletni strani Mikrocop.