Pouzdanost nije slučajnost. Ona je rezultat načina rada

U sustavima u kojima dokumenti predstavljaju obveze, odluke i usklađenost, pogreška nije samo neugodnost. Ona može značiti propuštene rokove, pogrešne odluke i gubitak pregleda nad procesima.

“Naš je glavni cilj otkriti pogreške na vrijeme i osigurati da se korisniku pri svakom kliku dogodi upravo ono što očekuje”, objašnjava Klavdija Blatnik, voditeljica jedinice za osiguranje kvalitete programske opreme u Mikrocopu.

Klavdija Blatnik, voditeljica jedinice za osiguranje kvalitete programske opreme

Zadnja kontrolna točka prije produkcije

QA tim uključen je u svaki korak razvoja InDoc EDGE-a, a ne samo na kraju.

“Mi smo zapravo zadnja kontrolna točka prije nego što nešto postane dio svakodnevne upotrebe”, objašnjava Klavdija. “Naravno, ne možemo obuhvatiti sve, ali možemo osigurati da većina kritičnih pogrešaka nikada ne dođe do korisnika.”

Pogreške otkrivene u kasnijim fazama ili tek kod korisnika zahtjevnije su i skuplje za ispravljanje. Zato tim temeljito provjerava svaku novu ili izmijenjenu funkcionalnost prije nego što ide u produkciju.

Svaka promjena nosi rizik, čak i mala

InDoc EDGE nije statičan sustav. Sa svakom nadogradnjom, novom funkcionalnošću ili integracijom nešto se mijenja. A svaka promjena, čak i mala, može utjecati na dijelove sustava koji na prvi pogled uopće ne djeluju povezano.

Majhna sprememba, velik vpliv

Jedan redak koda može utjecati na tisuće korisnika ili dokumenata. Naš je zadatak osigurati da takve stvari ne dođu do produkcije.

Primjerice, nakon nadogradnje može se dogoditi da se pozadinski procesi ne pokrenu pravilno. Bez sustavnog testiranja takvu pogrešku često otkrije tek korisnik.

Kako u praksi izgleda testiranje nove funkcionalnosti

Kada razvoj završi novu funkcionalnost, preuzima je QA tim. “Pažljivo pročitamo zahtjev i moramo razumjeti što je napravljeno te kako bi to moglo utjecati na druge dijelove sustava”, objašnjava Klavdija.

Suradnja

Zatim slijedi ručno testiranje svih scenarija: pozitivnih, negativnih i rubnih slučajeva. Testni scenariji pripremaju se unaprijed gdje je to moguće. Ako to nije moguće, pišu se tijekom testiranja i postaju dio svih budućih testiranja verzije.

Gdje je to smisleno, tim priprema i automatizirane testove koji se pokreću jednom dnevno, neovisno o tome je li u sustavu bilo promjena ili nije.

“To znači da moguće pogreške otkrivamo kontinuirano, a ne tek pri sljedećoj nadogradnji”, dodaje Klavdija.

Ključne vrste testiranja uključuju:

Funkcionalno testiranje – provjera rade li pojedine funkcionalnosti u skladu sa zahtjevima.
Integracijsko testiranje – provjera funkcionira li sustav pravilno između povezanih modula.
Sistemsko testiranje – provjera rada aplikacije kao cjeline u stvarnom okruženju.
Regresijsko testiranje – provjera utječu li nadogradnje na dijelove sustava koji već rade.
Testiranje opterećenja – provjera odziva sustava pod većim opterećenjem.
Sigurnosno testiranje – provjera pristupa, autorizacija i zaštite podataka.

Ručno i automatizirano testiranje: kombinacija koja se ne može zamijeniti

“Automatizacija ne može zamijeniti intuiciju koja se razvija iskustvom, odnosno osjećaj gdje se nešto može zakomplicirati i zašto”, kaže Klavdija.

Zato tim uvijek kombinira oba pristupa. Ručno testiranje donosi razumijevanje korisničkog iskustva i pomaže u pronalaženju rubnih slučajeva. Automatizirano testiranje osigurava ponovljivost i stalnu provjeru stabilnosti sustava. Samo jedan pristup nije dovoljan.

Suradnja koja otkriva stvarne scenarije

Ni najbolje interno testiranje ne može simulirati sve stvarne situacije. Dio testiranja zato se odvija i u suradnji s klijentima.

Klijenti u demo okruženjima testiraju svoje procese, integracije i specifične scenarije. To često otkriva ovisnosti o drugim sustavima, posebnosti procesa i rubne slučajeve koje nije bilo moguće unaprijed predvidjeti.

To nije pogreška procesa. To je stvarnost kompleksnih sustava. Zato je pouzdanost uvijek rezultat internih provjera, stvarne upotrebe i brzog odgovora na otkrivena odstupanja.

Kada klijent prijavi pogrešku, ona najprije prolazi kroz sustav podrške, gdje se utvrđuje radi li se o pogrešci, poboljšanju ili novom zahtjevu. QA se uključuje kada je rješenje spremno i potvrđuje radi li ispravak zaista kako treba.

Kada se pogreška ipak dogodi: postupak, ne panika

“I to se događa i potpuno je normalno”, kaže Klavdija. “Ključno je koliko brzo i učinkovito reagiraš.”

Kada se pogreška otkrije, tim je precizno opiše, prijavi u sustav i zajedno s razvojem analizira uzrok. Nakon ispravka slijedi ponovno testiranje - ne samo same pogreške, nego i njezinih mogućih utjecaja na sustav.

Ako se pogreška ponavlja, prilagođavaju se testni scenariji.

Temeljito testirano s razlogom

“Kada QA kaže ‘testirano je’, to znači da iza toga stoji cijeli tim i velik broj provjera.”

Cilj nije savršenstvo, nego pouzdanost i odzivnost

“Kod tako kompleksnog sustava kao što je InDoc EDGE, savršenstvo jednostavno ne postoji”, izravna je Klavdija. “Ali to ne znači da se njime ne bavimo. Naš je cilj što više smanjiti rizike i brzo reagirati kada se pogreška pojavi.”

Za organizaciju koja svakodnevno obrađuje tisuće dokumenata to znači manje prekida, manje nepredviđenih situacija i lakše dokazivanje usklađenosti.

To nije samo bolje korisničko iskustvo. To je razlika između sustava kojem vjerujete i sustava za koji se samo nadate da radi.

Izvor: Ovaj blog nastao je na temelju razgovora s Klavdijom Blatnik, voditeljicom jedinice za osiguranje kvalitete u Mikrocopu. Cijeli intervju pročitajte na posebnoj Mikrocopovoj internetskoj stranici.