U posljednje vrijeme greške u softveru sve više utiču na prosječ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 vrijeme 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 dio dana ili tokom cijelog dana jer je instalacija softvera za upravljanje klijentima „pokvarila“ cijeli 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 izbjegnu ovakvi incidenti i njihove posljedice. U nastavku ćemo istražiti temu testiranja softvera i obraditi sljedeć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 uvijek 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 primjer 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 dvije nedelje, 2010-te bi bilo potrebno 100,000 nedelja – drugim riječima, oko dvije 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 prije 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 Njemač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 prije 20 godina. Osim povećanja količine tehničkih podataka, razmislite o mogućnostima današnjih pametnih telefona.
Prije 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 ili se u nekim specifičnim slučajevima još uvijek koriste da bi se napravili dobri programi – već je razlika između broja mogućih rješenja koja postoje za određeni problem.
Zamislimo, analogno tome, da pokušavamo da pređemo rijeku široku 10-tak metara bez upotrebe čamca i bez kvašenja. U prošlosti je postojalo jedno rješenje: sistem analitičari bi potražili mjesta gde bi velike stijene mogle da se iskoriste kako bi se preko njih preskočilo na drugu stranu rijeke.
Danas postoji 10 mostova na rijeci, a to je 10 različitih načina kako bi se mogao riješiti problem. Na kraju , softverski arhitekta bi trebao da izabere jedno konkretno rješenje koje zadovoljava razne kvalitativne kriterijume. Recimo da postoji betonski most za automobile (dio autoputa) i drveni mostić za pješake.
Da biste koristili autoput, morate sagraditi priključne puteve. Iako je jednostavan drveni most sasvim dovoljan za rješenje problema prelaska rijeke, a građenje priključnih puteva zahtjeva više truda, softverski arhitekta bi mogao radije izabrati upotrebu betonskog mosta jer bi i drugi ljudi možda željeli da pređu rijeku.
Nemoguće je testirati svaku kombinaciju
Evo još jednog primjera: prije 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. Umjesto unošenja svojih godina, oni biraju standardne karte, karte u pola cijene, ili druge opcije. Umjesto unošenja cijele 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 unijeti bilo kojim redoslijedom, 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, umjesto pojavljivanja greške koja govori, “Prva klasa se mora odabrati prije nego što se odlučite za popust,” putnici će vidjeti 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 unešenih bilo kojim redoslijedom. 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 prije 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 cijeli poslovni 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 primjer, broj mogućih kombinacija prevazilazi primjer aparata za karte za nekoliko redova veličine.
2000-te godine na konferenciji u Njemačkoj je iznešen podatak da je broj mogućih stanja u programu veličine Excel 4 otprilike 10^80. To je nezamisliva cifra. Još je nevjerovatnija kada pomislite da je Stiven Hoking 2000-te godine procjenio broj jedinstvenih čestica u Univerzumu na 10^160.
Obe cifre djeluju sumnjivo. Ali čak iako ih smanjimo na jedan procenat jednog procenta to je i dalje nevjerovatnih 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 djelovi 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 odjeljenju 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 zahtjevi. Ako određeni zahtjev 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 zahtjevu dodjeljen 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 odjeljenje, sa druge strane, ne koncentriše se na opšte zahtjeve, već na zahtjeve 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 provjerava zahtjeve? Često se ne pravi poređenje između konačnih specifikacija i specifikacija dizajna. Ovaj problem potiče od ljudi koji postavljaju zahtjeve. Č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 zahtjevima. A ljudi koji su postavljali zahtjeve imali su drugačiju ideju kako bi to izgledalo i funkcionisalo.
Dodatno, čest je slučaj da zahtjevi nedostaju ili nisu kompletni. Ovakvi zahtjevi mogu da se previde u fazi testiranja i od strane programera i od strane poslovnog odjeljenja zato što su previše očigledni i svi misle da se podrazumjevaju.
Vraćajući se opet na primjer 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 redoslijedom.
Ako tastere pritisnu drugačijim redoslijedom 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 zahtjev nedostaje u specifikacijama dizajna.
Profesionalni testeri ne prihvataju ni potvrdu programera ni potvrdu poslovnog odjeljenja. Oni sebe pokušavaju da stave u ulogu korisnika. Ovo je mjesto gdje počinje proces kreativnog razmišljanja testera. Oni pokušavaju da zamisle i predvide pogrešne poteze korisnika.
Evo primjera: 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 podsjetnik: Provjerite da li vam je CAPS LOCK isključen. U prošlosti, kada ovaj podsjetnik 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 zabiljež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 neizbjež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 gdje 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 provjeravaju da li je narušeno neko definisano poslovno pravilo.
Autor: Hans Hartmann, test director u Objentis
Još malo o vrstama testiranja
Testiranje jedinice (Unit test)
Testiranje jedinice verifikuje funkcionisanje u izolaciji softverskih dijelova koji se nezavisno mogu testirati. U zavisnosti od konteksta, to mogu biti individulani podprogrami ili veće komponente kreirane od tijesno povezanih jedinica. Testiranje jedinice se precizno definiše standardom IEEE Standard for Software Unit Testing (IEEE1008-87), koji takođe opisuje integralni pristup sistematičnom i dokumentovanom testiranju jedinice. Tipično, testiranje jedinice se dešava sa pristupom kodu koji se testira i sa podrškom alata za debagovanje, a može uključivati programere koji su pisali kod.
Integraciono testiranje
Integraciono testiranje je proces verifikovanja interakcije između softverskih komponenti. Klasične strategije integralnog testiranja, kao što su top-down ili bottom-up, se koriste kod tradicionalnog, hijerarhijski strukturiranog softvera. Moderene sistematične integrativne strategije su više arhitektonski struktuirane, što implicira integrisanje softverskih komponenti ili podsistema na bazi identifikovanih funkcionalnih dijelova. Integraciono testiranje je kontinualna aktivnost, u svakoj fazi u kojoj softver-inženjeri moraju umjesto posmatranja na nižem nivou da se koncentrišu na perspektivu na integralnom nivou. Osim za male, jednostavnije softvere, sistematične, integralne test strategije se obično izvode putem testiranja svih komponenata zajedno u istom trenutku.
Sistemsko testiranje
Sistemsko Testiranje se bavi ponašanjem cijelog sistema. Većina funkcionalnih otkaza trebalo bi da su već identifikovani tokom testiranja jedinice i integracionog testiranja. Sistemsko testiranje se obično razmatra prikladnim za poređenje sistema sa nefunkcionlanim sistemskim zahtjevima, kao što su bezbjednost, brzina, preciznost ili pouzdanost. Spoljašnji interfejs ka drugim aplikacijama, pomoćnim programima, hardverskim uređajima, ili operativnim okruženjima se takođe razmatra na ovom nivou.
Ciljevi testiranja (eng. Objectives of Testing)
Testiranje se sprovodi u pogledu specifičnih ciljeva, koji su navedeni više ili manje eksplicitno. Navođenje ciljeva u preciznim, kvantitativnim terminima dozvoljava uspostavljanje kontrole nad test procesom. Testiranje može imati za cilj verifikaciju različitih osobina. Test slučajevi mogu biti dizajnirani radi provjere da li su funkcionalni zahtjevi korektno implementirani, što se u literaturi različito naziva: conformance testing, correctness testing, ili functional testing. Nekoliko drugih nefunkcionalnih osobina takođe se mogu testirati uključujući performanse, pouzdanost, upotrebljivost, između mnogih drugih.
Test prihvatljivosti
Test prihvatljivosti provjerava ponašanje sistema prema zahtjevima kupaca, bez obzira kako oni bili iskazani. Kupac podnosi ili specificira tipične zadatke radi provjere da li su njihovi zahtjevi ispunjeni. Ova aktivnost testiranja može, ali i ne mora, da uključuje razvojni tim sistema.
Instalaciono testiranje
Uobičajeno se, nakon kompletiranja softverskog dijela i testa prihvatljivosti, softver verifikuje po instalaciji u ciljnom okruženju. Instalaciono testiranje može se posmatrati kao sistemsko testiranje sprovedeno prema zahtjevima hardverske konfiguracije. Instalacione procedure mogu takođe biti predmet provjere.
Alfa i Beta testiranje
Prije puštanja u prdukciju softverskog rješenja, nekada se predaje maloj grupi potencijalnih korisnika radi probnog rada:
- in-house (alfa testiranje) ili
- external (beta testiranje)
Ovi korisnici izvještavaju o problemima sa proizvodom. Korišćenje alfa i beta testiranja je često nekontrolisano i nije uvijek referenca u test planu.
Funkcionalno testiranje
Često se u literaturi koriste i nazivi Functional Testing /Conformance Testing / Correctness testing. Funkcionalno testiranje ima za cilj procjenu da li je posmatrano ponašanje testiranog softvera u skladu sa svojim specifikacijama.
Regresiono testiranje (eng. Regression Testing)
Prema IEEE610.12-90, regresiono testiranje je selektivno retestiranje sistema ili komponenti radi verifikacije da modifikacije nisu prouzrokovale neželjene efekte. Praktično, ideja je da se pokaže da softver koji je prethodno prošao test i dalje prolazi. Prema Beizer-u to je bilo koje ponavljanje testa sa namjerom da pokaže da je ponašanje softvera nepromjenjeno, osim prema zahtjevu. Balans (eng. trade-off) mora da se napravi između osiguranja datog regresionim testiranjem svaki put kada se napravi promjena i resursa neophodnih za to. Regresiono testiranje može da se sprovede na svakom test nivou. Regresioni testovi su potrebni kada testirani sistem treba da zamjeni postojeći sistem. Regresioni testovi garantuju da je performansa novog sistema barem jednaka performansi starog. Regresioni testovi se uvijek koriste prilikom faznog razvoja.
Testiranje performansi
Testiranje performansi namjenjeno je za verifikaciju da softver zadovoljava specifikovane zahtjeve za performansama, kao što su na primjer, kapacitet i vrijeme odziva. Specifična vrsta testiranja performansi je testiranje volumena u kojem se testiraju unutrašnja programska ili sistemska ograničenja.
Ostala testiranja
Stress testiranje iskušava softver na maksimalno dizajnirano opterećenje, ali i preko toga.
Back-to-back testing predstavlja primjenu jednog skupa testova na dve implementirane verzije softverskog proizvoda u cilju poređenja dobijenih rezultata.
Recovery testing ima za cilj verifikaciju mogućnosti restartovanja softvera nakon pada.
Configuration testing se koristi u slučajevima kada je softver izgrađen za različite korisnike; testiranje konfiguracije analizira softver pod različitim specifikovanim konfiguracijama.
Testiranje korisničkih funkcija
Ovaj proces evaluira koliko je jednostavno za krajnje korisnike da savladaju i koriste softver, uključujući korisničku dokumentaciju. Ovo testiranje i provjera treba da odgovori na pitanje: Koliko su efikasne softverske funkcije u podršci korisničkim zahtjevima? Sa druge strane sistem mora da posjeduje i efikasan način oporavka od korisničkih grešaka.
NAPOMENA: Ako želite da promovišete link u ovom članku, javite mi.
Ako vam se ovaj članak dopao, lajkujte FB stranicu DM Spot, Twitter ili LinkedIn i budite obavješteni kad novi članak bude objavljen.
