Testiranje softvera – šta to beše?

U poslednje vreme greške u softveru sve više utiču na prosečnog korisnika – npr. na aerodromskim terminalima ili u elektronskom bankarstvu. Često  čujemo da softver nije adekvatno testiran. Ali šta to tačno znači?

S vremena na vreme se pojavi zaista spektakularan problem sa softverom. Otvaranje terminala 5 na aerodromu Heathrow postalo je javno poniženje jer je sistem za upravljanje prtljagom otkazao poslušnost. Korisničkim nalozima više od 17 miliona naloga klijenata RBS-a i njenih podružnica NatWest i UlsterBank moglo se pristupiti deo dana ili tokom celog dana jer je instalacija softvera za upravljanje klijentima „pokvarila“ ceo sistem.  Jedna od najvećih austrijskih banaka je platila apanažu 21 milion evra u vaučerima svojim klijentima jer novi online bankarski softver nije radio danima.

Greške slične navedenim ne samo da štete kompanijskom brendu, nego mogu biti i veoma skupe. Cilj testiranja softvera je da se izbegnu ovakvi incidenti i njihove posledice. U nastavku ćemo istražiti temu testiranja softvera i obraditi sledeća ključna pitanja:

• Kakva je razlika između danas i juče?
• Šta se mora testirati?
• Ko bi trebalo da testira?

Možemo pretpostaviti da je u pomenutim slučajevima softver sigurno bio testiran. Banke i osiguravajuća društva vrlo dobro znaju rizike koje nosi softver koji nije testiran. Kako je onda moguće da se ovakvi problemi i dalje dešavaju? Neki tehnički problemi softvera mogu biti izazvani olujama i prirodnim katastrofama  ali svakako ne svi. Ipak, ovo ne daje objašnjenje  za povećanje broja  softverskih grešaka u pomenutim slučajevima. Testiranje je uvek sprovođeno i sve je radilo poprilično dobro. A prirodne katastrofe su poznat, iako nepredvidljiv faktor. Pitanje je zašto su onda isprobani i ispravni recepti iznenada zakazali?

Razlog je jednostavan: Programi su postali kompleksniji. I kako bi se kompleksnost na pravi način obradila, potrebno je više testiranja. Koliko tačno više? Uzmimo na primer godine 2000. i 2010. U ovom periodu  količina podataka sa kojom se barata uvećala se za faktor od 50,000. Ako je za testiranje programa 2000-te godine bilo potrebno dve nedelje, 2010-te bi bilo potrebno 100,000 nedelja – drugim rečima, oko dve hiljade godina.

Više interakcija, a ne podataka, povećava kompleksnost

Raditi i računati na ovaj način očigledno nije opcija. Na kraju krajeva, softver je danas mnogo efikasniji, razvojni alati omogućavaju da mnoge greške budu otkrivene i pre prve verzije programa, a  savremeni objektno-orijentisani dizajn softvera omogućava programerima da programiraju urednije i sa manje grešaka. Ipak, ako testiranje uvećamo samo za faktor 50 i dalje bi trebalo testirati 100 nedelja – tj. dve godine. To jednostavno nije izvodljivo.

Poređenje razlike samo u veličini i količini ne mora da znači da je softver postao kompleksniji. U stvari, jedan od vodećih argumenata za korišćenje kompjutera je taj da nije bitno da li operaciju (računanje npr.) treba ponoviti pet ili 5000 puta. Softver treba jednostavno da bude pouzdan. Dakle, nije samo povećanje kvantiteta podataka ono što uzrokuje kompleksnost, već i povećanje mogućih veza i sistema.

Osvrnimo se, recimo, na razvoj mobilne tehnologije: U Nemačkoj, Radio Telephone Network C se prva susrela sa problematičnim slučajevima, praćenih od strane digitalne mobilne mreže D-Netz koja je mnogo lakša za upravljanje. Poređenja radi, današnji pametni telefoni imaju snagu mainframe računara od pre 20 godina. Osim povećanja količine tehničkih podataka, razmislite o mogućnostima današnjih pametnih telefona . Pre svega pomislite na broj drugih sistema sa kojima se pametni telefon može povezati istovremeno. Dakle, broj mogućih veza je uzrok odgovarajućeg povećanja kompleksnosti.

Glavna razlika između danas i juče nije napredak u programskim jezicima – iako programeri više ne programiraju u Assembler-u ili COBOL-u, ovi jezici se i dalje mogu koristiti da bi se napravili dobri programi – već je razlika između broja mogućih rešenja koja postoje za određeni problem.

Zamislimo, analogno tome, da pokušavamo da pređemo reku široku 10-tak metara bez upotrebe čamca i bez kvašenja. U prošlosti je postojalo jedno rešenje: sistem analitičari bi potražili mesta gde bi velike stene mogle da se iskoriste kako bi se preko njih preskočilo na drugu stranu reke. Danas postoji 10 mostova na reci, a to je 10 različitih načina kako bi se mogao rešiti problem. Na kraju , softverski arhitekta bi trebao da izabere jedno konkretno rešenje koje zadovoljava razne kvalitativne kriterijume. Recimo da postoji betonski most za automobile (deo autoputa) i drveni mostić za pešake. Da biste koristili autoput, morate sagraditi priključne puteve. Iako je jednostavan drveni most sasvim dovoljan za rešenje problema prelaska reke, a građenje priključnih puteva zahteva više truda, softverski arhitekta bi mogao radije izabrati upotrebu betonskog mosta jer bi i drugi ljudi možda želeli da pređu reku.

Nemoguće je testirati svaku kombinaciju

Evo još jednog primera: pre 40 godina, kada bi putnici kupovali kartu za voz sa aparata za karte, trebalo je da odgovore na niz uzastopnih pitanja. Odakle polazite? Dokle biste želeli da putujete? Koliko imate godina? Da li imate pravo na sniženu cenu? U kojoj klasi želite da putujete? I tako dalje… Ako bi u toku odgovaranja na pitanja otkrili da nemaju dovoljno novca, putnici bi otkazali transakciju i počeli ponovo iz početka.

Na današnjim aparatima za karte, putnici će pronaći pitanja sakrivena u raznim poljima. Umesto unošenja svojih godina, oni biraju standardne karte, karte u pola cene, ili druge opcije. Umesto unošenja cele destinacije, unosi se prvih nekoliko slova, i tada se prikazuju samo moguće destinacije. Iako polja za unošenje sugerišu da se informacija može uneti bilo kojim redosledom, to baš i nije moguće. Na primer, ako su putnici izabrali kartu sa popustom onda ne mogu naknadno izabrati prvu ili višu klasu. Dakle, umesto pojavljivanja greške koja govori, “Prva klasa se mora odabrati pre nego što se odlučite za popust,” putnici će videti poruku poput, “Morate kupiti svoju kartu za prvu klasu”

U ovom slučaju, jasno je da su programeri napravili neke male greške u procesu prebacivanja prvobitno linearne, jednostavne ulazne sekvence u grafički sistem unosa. Recimo da računar mora da obradi pet različitih unosa unetih bilo kojim redosledom. To znači da postoji 120 različitih kombinacija unosa. To znači da je krajnje razumljivo da nije bilo moguće testirati sve opcije pre nego što je softver implementiran. U prošlosti, bilo je moguće da se testira svaka pojedinačna funkcija a zatim da se testira i ceo proces. Sada je neophodno testirati interakciju između pojedinačnih funkcija. Broj ovih interakcija zavisi direktno od broja mogućih kombinacija sekvenci, koje vrlo lako mogu dostići sedmocifren broj. Ako uzmemo pametne telefone na primer, broj mogućih kombinacija prevazilazi primer aparata za karte za nekoliko redova veličine.

2000-te godine na konferenciji u Nemačkoj je iznet podatak da je broj mogućih stanja u programu veličine Excel 4 otprilike 10^80. To je nezamisliva cifra. Još je neverovatnija kada pomislite da je Stiven Hoking 2000-te godine procenio broj jedinstvenih čestica u Univerzumu na 10^160. Obe cifre deluju sumnjivo. Ali čak iako ih smanjimo na jedan procenat jednog procenta to je i dalje neverovatnih 10^66. Jasno je da je nemoguće je testirati svaki pojedinačni slučaj koji bi se mogao desiti. U stvari, to je baš ono što je austrijska banka – pomenuta na početku teksta – rekla svojim korisnicima.

Dakle, ako je nemoguće testirati sve, koji delovi programa moraju biti testirani? Ovo je jedan od prvih zadataka kada govorimo o testiranju softvera: utvrđivanje koji bi test scenariji trebali da budu korišćeni. Mnoge kompanije koriste programere za testiranje rada drugih programera. Alternativno, traže od zaposlenih u poslovnom odeljenju da testiraju softver, s’ obzirom da ti zaposleni u suštini najbolje i znaju kako bi program trebao da funkcioniše.

Ko šta testira?

Uobičajeno, programeri testiraju da li su zadovoljeni zahtevi. Ako određeni zahtev može biti izvršen i dobijen je zadovoljavajući rezultat, test slučaj je u redu. Ako su test slučajevi odabrani tako da je svakom zahtevu dodeljen bar jedan test slučaj, program se smatra testiranim i trebalo bi da radi kada svi test slučajevi pokažu zadovoljavajuće rezultate. Poslovno odeljenje, sa druge strane, ne koncentriše se na opšte zahteve, već na zahteve koji su njima bitni. A budući da su ovi testeri upoznati sa određenim klijentima, transakcijama, računima, politikom rada firme, kao i kombinacijom proizvoda koji su povremeno izazivali probleme u prošlosti, oni mogu takođe da rafinišu proces testiranja. Ovo se u praksi zove testiranje bazirano na iskustvu i veliko je poboljšanje u odnosu na način kada se koriste samo programeri.

Međutim, i kod ovog načina testiranja postoje slabosti: Ko proverava zahteve? Često se ne pravi poređenje između konačnih specifikacija i specifikacija dizajna. Ovaj problem potiče od ljudi koji postavljaju zahteve. Često ne mogu da vizualizuju ponašanje softvera koji će na kraju biti napravljen. Na kraju krajeva, finalni proizvod može sadržati grešku koja se već nalazila u zahtevima. A ljudi koji su postavljali zahteve imali su drugačiju ideju kako bi to izgledalo i funkcionisalo.

Dodatno, čest je slučaj da zahtevi nedostaju ili nisu kompletni. Ovakvi zahtevi mogu da se previde u fazi testiranja i od strane programera i od strane poslovnog odeljenja zato što su previše očigledni i svi misle da se podrazumevaju. Vraćajući se opet na primer aparata za karte, jasno je da testeri pretpostavljaju da će korisnici znati da pokrenu aparat i da će znati proces rada. A činjenica je da program ne govori korisnicima da prvo treba da pritisnu određeno dugme, plus korisnici su u mogućnosti da pritisnu tastere drugačijim redosledom. Ako tastere pritisnu drugačijim redosledom od zamišljenog, neće moći da obave proces na pravi način, ali neće dobiti ni poruku o grešci zato što taj zahtev nedostaje u specifikacijama dizajna.

Profesionalni testeri ne prihvataju ni potvrdu programera ni potvrdu poslovnog odeljenja. Oni sebe pokušavaju da stave u ulogu korisnika. Ovo je mesto gde počinje proces kreativnog razmišljanja testera. Oni pokušavaju da zamisle i predvide pogrešne poteze korisnika. Evo primera: Lozinke se uopšteno sastoje od malih i velikih slova (case-sensitive). Danas ako korisnici unesu pogrešnu lozinku, obično im izađe poruka kao podsetnik: Proverite da li vam je CAPS LOCK isključen. U prošlosti, kada ovaj podsetnik nije bio normalna pojava, korisnici su često mislili da oni stvarno ne unose ispravnu lozinku, tj. nisu znali u čemu je problem. Možda su pokušavali iznova i iznova dok ne prime novu poruku koja glasi: Vaša lozinka je blokirana. Molimo kontaktirajte sistem administratora.

Ovo se događa danas u svakom softveru i pojavljuje u raznim oblicima – korisnici prave greške koje narušavaju neko pravilo o kom ništa ne znaju. Dobri programi će korisnicima javiti  odgovarajuću grešku i poruku koja ih upućuje na pomoć u vezi sa tom greškom. Ipak, ako su programeri pretpostavili da korisnici poznaju pravila, oni neće kreirati ovakve vrste poruka. Program će „odbijati dalju saradnju“, a korisnik neće znati razlog.

65,000 grešaka u Windows-u NT

Šta danas konkretno može da se postigne testiranjem softvera? Za Windows NT operativni sistem, koji je mali u poređenju sa današnjim sistemima, Microsoft je zabeležio oko 65000 grešaka. Sistem je smatran profesionalnim (C2 sertifikat) i Microsoft se potrudio da otkrije i što je više moguće grešaka.  Iz ekonomskih razloga, međutim, jednostavno nije moguće pronaći sve greške. Uprkos profesionalnom testiranju, otprilike je tri do četiri procenta grešaka ostalo u finalnoj verziji, onoj koja ja otišla ka korisnicima. U ovom slučaju, iznosi oko 2,000 grešaka.

Operativni sistemi su veliki, ali čak i u komercijalnim aplikacijama broj grešaka može da bude između 1,000 i 4,000. Kako je nemoguće pronaći sve greške, veoma je bitno tražiti one sa kojima će se korisnici neizbežno  susresti. Zbog ovoga, testeri bi trebalo da istraže tipične slučajeve i načine korišćenja softvera, iz ugla korisnika. U softverskim projektima gde se postojećem softveru dodaju nove funkcionalnosti, scenariji korišćenja često nisu poznati, a ni detaljno opisani. U ovom slučaju, profesionalni testeri će sami sastaviti listu scenarija korišćenja i postaraće se da opišu i dokumentuju sva povezana poslovna pravila što detaljnije. Za svaki scenario upotrebe, postoji jedan test slučaj u skladu sa odgovarajućim poslovnim pravilom. Ovakvi scenariji proveravaju da li je narušeno neko definisano poslovno pravilo.

NAPOMENA: Tekst je objavljen uz saglasnost autora g. Hansa Hartmann-a iz kompanije Objentis