Zašto testiramo

Šta učimo ovog semestra

Petnaest sedmica: svaka ima tri časa teorije i tri časa praktične nastave. Danas: poglavlje 1 (Sedmica 1, označeno). Isti primjer kroz knjigu: DeliveryApp, narudžba N-1001.

Šta učimo ovog semestra

Literatura

1. J. Popović: Priručnik za test inženjere, CET i Računarski fakultet, Beograd, 2023.
2. Rakić-Skoković: Priručnik za testiranje softvera, Fakultet tehničkih nauka, Novi Sad, 2013.
3. G. J. Myers: The Art of Software Testing, 2. izdanje, John Wiley & Sons, 2004.
4. A. P. Mathur: Foundations of Software Testing, Addison-Wesley Professional, 2008.

Zašto ovo poglavlje

Ovo je prvo poglavlje, pa se ne nastavlja ni na šta: dovoljno je da ste nekad koristili aplikaciju koja nije radila kako ste očekivali. Prije prve definicije pogledaćemo pet istinitih priča. Četiri govore o greškama koje su koštale milione, rakete i dane zastoja na aerodromima. Peta govori o timu koji je pisao softver s gotovo nijednom greškom, i kako je to postigao. Iz priča izlazi pitanje na koje odgovara cijeli predmet: kako pronaći grešku prije nego što je pronađe korisnik?

U drugom dijelu poglavlja razdvajamo riječi koje se često miješaju (greška, defekt, otkaz) i objašnjavamo šta testiranje jeste, a šta nije. Zatim učimo sedam principa testiranja, koji važe za svaki projekat. U trećem dijelu upoznajemo DeliveryApp, izmišljenu aplikaciju za naručivanje hrane koju testiramo kroz cijelu knjigu, i njenih šest pravila. Na praktičnoj nastavi pravimo prvi „test” olovkom: tabelu očekivanih cijena, i poredimo je s onim što program zaista izračuna.

Riječi ovog poglavlja (1/2)

• Greška (ljudska) – ono što čovjek pogrešno uradi ili pomisli dok piše zahtjev ili kod.
• Defekt (bug) – mjesto u kodu, dokumentu ili modelu koje je pogrešno zbog ljudske greške.
• Otkaz (failure) – trenutak kad sistem u radu uradi nešto pogrešno, vidljivo korisniku.
• Testiranje – provjera softvera radi otkrivanja defekata i procjene kvaliteta, prije nego što stigne do korisnika.
• Debagovanje – traženje i popravljanje uzroka otkaza u kodu; to radi programer poslije testa.
• Test slučaj – jedan zadatak za provjeru: ulaz, koraci i očekivani rezultat.

Riječi ovog poglavlja (2/2)

• Očekivani rezultat – ono što sistem treba da uradi po pravilima; s njim poredimo stvarni rezultat.
• Test orakul – izvor iz kojeg znamo očekivani rezultat (specifikacija, ručni račun, stara verzija).
• Pokrivenost – koliki dio programa ili pravila su testovi provjerili.
• Regresija – greška koja se pojavi u nečemu što je ranije radilo, poslije neke izmjene.
• Kvalitet – koliko softver ispunjava zahtjeve i očekivanja korisnika.
• ISTQB – međunarodna organizacija koja definiše pojmove i ispite za testere.

Ciljevi poglavlja

Nakon poglavlja možete:

ispričati bar dvije priče o greškama u softveru i reći šta bi ih otkrilo; razlikovati ljudsku grešku, defekt i otkaz na primjeru; objasniti šta je testiranje i po čemu se razlikuje od debagovanja; navesti razloge zašto testiramo; nabrojati i objasniti sedam principa testiranja; izračunati zašto iscrpno testiranje nije moguće ni za malu funkciju; opisati ulogu testera u timu; navesti šest pravila DeliveryApp i izračunati cijenu narudžbe N-1001; napraviti tabelu očekivanih rezultata i uporediti je sa stvarnim rezultatima programa.

Plan poglavlja – Sedmica 1: tri časa teorije i tri časa praktične nastave

Ukratko – Priča 1 – Moljac u releju (Harvard, 1947)

• U septembru 1947. tim računara Mark II na Harvardu pronašao je moljca zaglavljenog u releju.
• Moljac je zalijepljen u dnevnik rada uz bilješku „prvi stvarni slučaj da je pronađena buba”, i stranica se čuva u muzeju Smithsonian.
• Riječ „bug” za kvar postojala je i ranije, ali od tada je simbol greške u softveru.
• Pouka je da se greške nalaze sistematskim traženjem i zapisivanjem.

Ukratko – Priča 2 – Broj koji nije stao (Ariane 5, 1996)

• Prva Ariane 5 uništena je 4. juna 1996, oko 37 sekundi nakon paljenja motora.
• Uzrok je bilo pretvaranje 64-bitnog decimalnog broja u 16-bitni cijeli, koji ne može biti veći od 32 767.
• Softver je preuzet s Ariane 4, gdje broj nikad nije bio toliko velik, i nije testiran za uslove nove rakete.
• Rezervni računar s istim softverom otkazao je zbog iste greške.
• Pouka je da se granice testiraju posebno i da se preuzet softver testira u novim uslovima.

Ukratko – Priča 3 – Četrdeset pet minuta (Knight Capital, 2012)

• Knight Capital je 1. augusta 2012. pustio novi program na osam servera, a na jednom je ostao stari kod.
• Za oko 45 minuta pogrešni nalozi koštali su firmu oko 440 miliona dolara.
• Nije provjereno da je ista verzija na svim serverima ni da stari kod više ne postoji.
• Pouka je da se testira i sama isporuka, a ne samo program.

Ukratko – Priča 4 – Jedna datoteka, milioni računara (CrowdStrike, 2024)

• Dana 19. jula 2024. pogrešna konfiguraciona datoteka firme CrowdStrike oborila je Windows računare širom svijeta.
• Microsoft je procijenio oko 8,5 miliona pogođenih uređaja; stajali su aerodromi, banke i bolnice.
• Ažuriranje je poslano svima skoro istovremeno.
• Pouka je da se testira i svaka konfiguraciona izmjena i da se izmjene šalju postepeno.

Ukratko – Priča 5 – Softver koji je letio u svemir (svemirski šatl, 1981–2011)

• Softver svemirskih šatlova (1981–2011) bio je jedan od najpouzdanijih programa ikad napisanih.
• Prema članku iz 1996, posljednje tri verzije, svaka od oko 420 000 redova, imale su po jednu grešku.
• Tajna je bila proces: zapisani zahtjevi, pregled svake izmjene, poseban tim za traženje grešaka i učenje iz svake.
• Pouka je da broj grešaka zavisi od pažnje tima, a ne od sreće.

Šta je zajedničko svim pričama

Ukratko – Šta je zajedničko svim pričama

• Nijedna greška iz priča nije bila neuhvatljiva; svaku je mogao naći dobro izabran test.
• Ariane 5 i Knight pokazuju važnost granica i provjere isporuke.
• Softver šatla pokazuje da pažljiv proces daje skoro savršen softver.
• Skupo nije bilo testiranje, nego njegova odsutnost.

1.1 Tri riječi koje se miješaju

U svakodnevnom govoru kažemo „aplikacija ima grešku” i za ono što je programer pogrešno napisao, i za ono što korisnik vidi na ekranu. Tester mora biti precizniji, jer su to tri različite stvari, u lancu:

1. Ljudska greška (error, mistake): čovjek pogrešno razumije ili pogrešno uradi. Programer pročita pravilo „za artikle od 30,00 € i više dostava je besplatna” i pomisli „preko 30 €”.
2. Defekt (defect, fault, bug): rezultat te greške ostane zapisan negdje, u kodu, dokumentu ili modelu. U kodu piše if iznos > 3000: umjesto if iznos >= 3000:.
3. Otkaz (failure): kad se defektni dio izvrši u pravim uslovima, sistem uradi nešto pogrešno, i to se vidi. Kupac naruči za tačno 30,00 € i aplikacija mu naplati 3,00 € dostave.

Primijetite da defekt može postojati godinama bez otkaza. Ako niko ne naruči za tačno 30,00 €, defekt > umjesto >= nikad se ne pokaže. Kod Ariane 5 defekt je postojao i na Ariane 4, ali otkaz se desio tek kad je raketa bila dovoljno brza. Zato testeri namjerno stvaraju uslove u kojima se defekt pokaže: biraju baš 30,00 €.

Slika iz života: kuhar i recept. Kuhar pogrešno pročita „2 kašičice soli” kao „2 kašike” (ljudska greška) i tako zapiše u svesku recepata (defekt). Svaki put kad neko skuha po toj svesci, jelo je preslano (otkaz). Jelo je otkaz, sveska je defekt, a pogrešno čitanje je ljudska greška. Ako popravimo samo jelo (dosolimo vodom), sljedeće će opet biti preslano; treba popraviti svesku, i pitati se kako da se pogrešno čitanje ne ponovi.

Ukratko – 1.1 Tri riječi koje se miješaju

• Ljudska greška je pogrešno razumijevanje ili postupak; defekt je njen trag u kodu ili dokumentu; otkaz je pogrešno ponašanje koje se vidi.
• Programer pomisli „preko 30 €”, napiše > umjesto >=, i kupac s 30,00 € plati dostavu.
• Defekt može dugo postojati bez otkaza, pa testeri namjerno biraju uslove u kojima se pokazuje.
• Kao kod recepta: popravlja se sveska, a ne samo jelo.

1.2 Šta je testiranje, a šta nije

Testiranje je skup aktivnosti kojima se softver i dokumenti oko njega provjeravaju da bi se otkrili defekti i procijenio kvalitet, prije nego što softver stigne do korisnika. Međunarodna organizacija ISTQB (International Software Testing Qualifications Board), koja definiše pojmove i ispite za testere širom svijeta, naglašava da testiranje nije samo pokretanje programa. U njega spadaju i čitanje zahtjeva, pregled koda, planiranje i izvještavanje.

Česta zabuna je između testiranja i debagovanja:

1.2 Šta je testiranje, a šta nije

Tester kaže: „Za tačno 30,00 € na 5 km aplikacija naplaćuje dostavu 3,00 €; po PP-4 treba 0,00 €.” Programer zatim debaguje: pronađe red s >, ispravi ga u >=, i ponovo pokrene test da potvrdi ispravku.

Druga važna razlika je između verifikacije i validacije. Verifikacija pita: radi li softver ono što piše u specifikaciji? Validacija pita: radi li ono što korisniku zaista treba? Softver može tačno raditi po specifikaciji, a specifikacija može biti pogrešna. Testeri provjeravaju oboje.

Ukratko – 1.2 Šta je testiranje, a šta nije

• Testiranje je provjera softvera i dokumenata radi otkrivanja defekata i procjene kvaliteta.
• Testiranje uključuje i čitanje zahtjeva, preglede, planiranje i izvještaje, a ne samo pokretanje programa.
• Testiranje pokazuje da otkaz postoji; debagovanje nalazi i popravlja uzrok.
• Verifikacija provjerava prema specifikaciji, a validacija prema stvarnim potrebama korisnika.

1.3 Zašto testiramo

Četiri razloga, od najočitijeg do najvažnijeg:

1. Da nađemo defekte prije korisnika. Defekt koji nađe tester košta vrijeme jednog programera. Isti defekt koji nađe korisnik košta i nezadovoljnog kupca, i popravku pod pritiskom, a nekad i milione (Knight) ili raketu (Ariane 5).
2. Da smanjimo rizik. Testiranje ne može dokazati da grešaka nema, ali može smanjiti vjerovatnoću da se ozbiljna greška desi u radu, posebno u najvažnijim dijelovima (plaćanje, cijena).
3. Da sakupimo dokaz o kvalitetu. Naručilac, šef i ponekad zakon traže odgovor na pitanje „smijemo li ovo pustiti?”. Rezultati testova su taj odgovor, napisan brojevima.
4. Da tim uči. Svaki pronađeni defekt govori nešto o procesu: zašto je nastao i kako ga sljedeći put spriječiti, kao tim šatla.

Cijena defekta raste s vremenom. Defekt pronađen dok je pravilo samo rečenica u zahtjevu ispravlja se brisanjem riječi. Isti defekt pronađen u kodu traži izmjenu koda i testova. Pronađen kod korisnika traži sve to, plus štetu koju je već napravio. Mnoga istraživanja pokazuju da ta cijena raste i desetostruko između ranih i kasnih faza; tačan faktor zavisi od projekta, ali smjer je uvijek isti.

Ukratko – 1.3 Zašto testiramo

• Testiramo da nađemo defekte prije korisnika, smanjimo rizik, sakupimo dokaz o kvalitetu i naučimo iz grešaka.
• Testiranje ne dokazuje da grešaka nema, ali smanjuje vjerovatnoću ozbiljnih otkaza.
• Cijena ispravke defekta raste što se kasnije otkrije.

Provjeri se

1. Šta je otkaz? Trenutak kad sistem u radu uradi nešto pogrešno što se vidi.
2. Ko debaguje, a ko testira? Programer debaguje (nalazi i popravlja uzrok), a tester pokazuje da otkaz postoji.
3. Može li defekt postojati bez otkaza? Da; dok se defektni dio ne izvrši u pravim uslovima, otkaza nema.

Odgovori: tipka R ili klik na zamućeno polje.

Dio 2 – Sedam principa testiranja

ISTQB opisuje sedam principa koji važe za svako testiranje, od male aplikacije do rakete. Svaki od njih štedi vrijeme jer sprečava pogrešna očekivanja.

1.4 Principi 1 i 2: šta testiranje može, a šta ne

Princip 1: Testiranje pokazuje prisustvo defekata, ne njihovo odsustvo. Ako test padne, sigurno znamo da defekt postoji. Ako svi testovi prođu, znamo samo da u onome što smo testirali nismo našli defekt. Zato tester nikad ne kaže „nema grešaka”, nego „za ovih 40 slučajeva sistem radi po pravilima”.

Princip 2: Iscrpno testiranje je nemoguće. Iscrpno znači isprobati sve moguće ulaze. Pogledajmo samo jednu funkciju DeliveryApp, cijena_dostave(udaljenost, iznos). Ako bi iznos bio cijeli broj centi od 5,00 € do 100,00 €, to je 10 000 − 500 + 1 = 9501 vrijednost. Ako bi udaljenost bila zaokružena na desetinku kilometra od 0 do 10 km, to je 101 vrijednost. Svih kombinacija je

Čemu služi. Račun pokazuje da već jedna mala funkcija ima skoro milion kombinacija, a mi smo je pojednostavili: udaljenost u stvarnosti nije zaokružena (3,01 km, 3,001 km…), iznos može biti veći od 100 €, a tu su i kod popusta, stanje narudžbe i redoslijed koraka. Za cijelu aplikaciju broj mogućih ulaza je praktično beskonačan. Zato tester bira testove pametno: tehnikama koje biraju malo slučajeva koji otkriju mnogo defekata (poglavlja 5 do 9) i prema riziku (poglavlje 14).

Ukratko – 1.4 Principi 1 i 2: šta testiranje može, a šta ne

• Testiranje pokazuje prisustvo defekata, ali ne može dokazati njihovo odsustvo.
• Iscrpno testiranje je nemoguće: samo cijena_dostave ima 9501 × 101 = 959 601 pojednostavljenih kombinacija.
• Zato se testovi biraju tehnikama i prema riziku.

1.5 Principi 3, 4 i 5: kada i gdje tražiti

Princip 3: Rano testiranje štedi vrijeme i novac. Testiranje počinje što ranije: već čitanje zahtjeva je test. Kad tester pročita PP-4 i pita „a šta je s tačno 30,00 €?”, nađen je defekt u zahtjevu prije nego što je napisan ijedan red koda. Ovo se zove i „pomjeranje ulijevo” (shift left), jer se na vremenskoj liniji projekta testiranje pomjera prema početku.

Princip 4: Defekti se grupišu. Defekti nisu ravnomjerno raspoređeni. Često je mali dio programa odgovoran za veliki dio defekata: dijelovi koji su složeni, često mijenjani ili pisani pod pritiskom. U DeliveryApp je to vjerovatno obračun cijene, s mnogo pravila i granica. Dobar tester troši više vremena tamo gdje su defekti već nađeni, jer ih tamo vjerovatno ima još.

Princip 5: Testovi se troše. Ako se isti testovi ponavljaju iznova, s vremenom prestanu nalaziti nove defekte, jer programeri ispravljaju upravo ono što ti testovi provjeravaju. Ovo se nekad zvalo i paradoks pesticida: kao što insekti postanu otporni na isti otrov, tako i softver „postane otporan” na iste testove. Testovi se zato redovno pregledaju i dopunjuju novim slučajevima.

Slika iz života za princip 4: ribar. Ako je na jednom mjestu na rijeci ulovio pet riba, tamo će opet zabaciti udicu, a ne nasumično po cijeloj rijeci.

Ukratko – 1.5 Principi 3, 4 i 5: kada i gdje tražiti

• Rano testiranje štedi: pitanje o granici u zahtjevu nalazi defekt prije koda.
• Defekti se grupišu u složenim i često mijenjanim dijelovima, pa se tamo traži više.
• Testovi se troše: isti testovi s vremenom prestanu nalaziti nove defekte, pa se dopunjuju.

1.6 Principi 6 i 7: kontekst i zabluda

Princip 6: Testiranje zavisi od konteksta. Softver svemirskog šatla i aplikacija za naručivanje hrane ne testiraju se isto. Za šatl greška može ubiti posadu, pa se testira svaka grana koda. Za DeliveryApp greška u boji dugmeta je sitnica, ali greška u cijeni je ozbiljna. Tester bira tehnike, dubinu i alate prema tome šta je u pitanju.

Princip 7: Zabluda o odsustvu defekata. Ni softver bez ijednog poznatog defekta nije uspjeh ako ne radi ono što korisniku treba. Ako DeliveryApp savršeno računa cijenu, ali je naručivanje toliko zbunjujuće da kupci zovu restoran telefonom, sistem nije dobar. Ovo je opet razlika između verifikacije i validacije: testiramo i da li je sistem ispravno napravljen i da li je napravljen pravi sistem.

1.6 Principi 6 i 7: kontekst i zabluda

Ukratko – 1.6 Principi 6 i 7: kontekst i zabluda

• Testiranje zavisi od konteksta: šatl i aplikacija za hranu testiraju se različito.
• Softver bez poznatih defekata nije uspjeh ako ne radi ono što korisniku treba.
• Sedam principa štedi vrijeme jer sprečava pogrešna očekivanja od testiranja.

Provjeri se

1. Šta tester smije reći kad svi testovi prođu? Da za testirane slučajeve sistem radi po pravilima, a ne da grešaka nema.
2. Koliko pojednostavljenih kombinacija ima cijena_dostave? 9501 × 101 = 959 601.
3. Šta znači da se testovi troše? Ponavljani isti testovi s vremenom prestanu nalaziti nove defekte.

Odgovori: tipka R ili klik na zamućeno polje.

1.7 Tester u timu

Tester nije „neprijatelj programera” ni policajac koji traži krivca. Tester i programer imaju isti cilj: da korisnik dobije softver koji radi. Razlika je u pogledu. Programer gleda kako nešto napraviti; tester gleda šta bi moglo poći naopako. Oba pogleda su potrebna, i zato je dobro da kod ne testira samo onaj ko ga je napisao: autor teško vidi grešku u vlastitom razmišljanju, kao što pisac teško vidi slovnu grešku u vlastitom tekstu.

Dobar tester ima nekoliko osobina:

• radoznalost – voli pitati „a šta ako…?” (šta ako je udaljenost 0? negativna? 10,0001?);
• sumnjičavost prema očitom – „to sigurno radi” je rečenica koja ga natjera da provjeri;
• preciznost – izvještaj o defektu piše tako da ga drugi može ponoviti u minuti;
• takt – piše o defektu, a ne o osobi: „za 30,00 € dostava je 3,00 €, treba 0,00 €”, a ne „opet si pogriješio”.

Tester ne mora biti posebna osoba. U mnogim timovima programeri pišu automatske testove za svoj kod, a testeri se bave težim stvarima: istraživanjem, sistemskim testovima, rizikom. Ali pogled testera mora postojati u timu, bez obzira ko ga nosi.

Ukratko – 1.7 Tester u timu

• Tester i programer imaju isti cilj; tester gleda šta bi moglo poći naopako.
• Autor teško vidi grešku u vlastitom razmišljanju, pa je dobro da testira i neko drugi.
• Dobar tester je radoznao, sumnjičav prema očitom, precizan i taktičan.
• Pogled testera mora postojati u timu, ma ko ga nosio.

1.8 Upoznajemo DeliveryApp

Kroz cijelu knjigu testiramo jedan izmišljeni sistem: DeliveryApp, aplikaciju za naručivanje hrane u jednom malom gradu. U njoj naručuju kupci (K-01 do K-05) iz tri restorana: R-1 Picerija, R-2 Roštilj i R-3 Salatarnica, a hranu nose dostavljači D-1 do D-4. Isti sistem se projektuje u predmetu Projektovanje informacionih sistema.

DeliveryApp mora poštovati šest poslovnih pravila (oznaka PP):

1.8 Upoznajemo DeliveryApp

Jelovnik u primjerima:

1.8 Upoznajemo DeliveryApp

1.8 Upoznajemo DeliveryApp

Narudžba N-1001, rukom

Kupac K-01 naručuje iz Picerije R-1 dvije pizze Margarita i jedan sok, na adresu 4,2 km od restorana:

1. Artikli: 2 × 9,50 + 2,50 = 21,50 €.
2. PP-1: 21,50 € nije manje od 5,00 €; narudžba se prima.
3. PP-3: 4,2 km je između 0 i 10 km; adresa je u zoni.
4. PP-4: 21,50 € je manje od 30,00 €; dostava se plaća.
5. PP-2: preko 3 km je 1,2 km, a to su dva započeta kilometra; dostava je 2,00 + 2 × 0,50 = 3,00 €.
6. Ukupno: 21,50 + 3,00 = 24,50 €. Sa kodom STUDENT10: popust 2,15 €, ukupno 22,35 €.

1.8 Upoznajemo DeliveryApp

1.8 Upoznajemo DeliveryApp

Dvije verzije koda

Kod DeliveryApp je napisan u Pythonu i nalazi se u folderu primjeri/deliveryapp/. Postoje dvije verzije:

• deliveryapp.py – ispravna verzija;
• deliveryapp_v0.py – prva verzija, koju su programeri napisali u žurbi. U njoj je nekoliko defekata, namjerno ostavljenih za vježbu.

Koliko defekata ima prva verzija i gdje su, ne otkrivamo. Tražićemo ih kroz knjigu tehnikama koje učimo, kao pravi testeri, a u poglavlju 8 pokušaćemo ih naći sve. Iznosi su u kodu zapisani u centima (2450 znači 24,50 €), da bi se izbjegle greške zaokruživanja decimalnih brojeva.

Ukratko – 1.8 Upoznajemo DeliveryApp

• DeliveryApp je izmišljena aplikacija za naručivanje hrane s tri restorana, pet kupaca i četiri dostavljača.
• Šest pravila PP-1 do PP-6 su izvor skoro svakog testa u knjizi.
• N-1001 košta 24,50 €, a sa kodom STUDENT10 22,35 €.
• Ispravna verzija je deliveryapp.py, a prva verzija s namjerno ostavljenim defektima deliveryapp_v0.py.

1.9 Test orakul: odakle znamo tačan odgovor

Test ima smisla samo ako znamo šta je tačno. Pokrenuti program i vidjeti da je ispisao „24,00 €” ne govori ništa, ako ne znamo da treba „24,50 €”. Izvor iz kojeg dobijamo očekivani rezultat zove se test orakul (po proročištu u staroj Grčkoj, koje je „znalo” odgovor).

Za DeliveryApp orakuli su:

1. specifikacija, odnosno pravila PP-1 do PP-6;
2. ručni račun po pravilima, kao za N-1001;
3. tabela očekivanih rezultata koju tester napravi unaprijed;
4. ponekad druga verzija sistema za koju vjerujemo da je tačna (npr. stara verzija koja je radila godinama).

Evo početka tabele očekivanih rezultata za cijenu dostave, izračunate rukom, prije pokretanja ijednog programa:

1.9 Test orakul: odakle znamo tačan odgovor

1.9 Test orakul: odakle znamo tačan odgovor

Primijetite kako su izabrani: većina redova je na granici nekog pravila (3 km, 10 km, 30,00 €, 5,00 €). Upravo tamo se, kao kod Ariane 5, najčešće kriju defekti. Kako se ovakve vrijednosti biraju sistematski, uči poglavlje 8.

Ukratko – 1.9 Test orakul: odakle znamo tačan odgovor

• Test orakul je izvor očekivanog rezultata: specifikacija, ručni račun, tabela ili provjerena verzija.
• Očekivani rezultat se zapisuje prije pokretanja programa, iz pravila.
• Dobra tabela ima mnogo slučajeva na granicama pravila (3 km, 10 km, 5,00 €, 30,00 €).

Provjeri se

1. Kolika je dostava za 3,1 km i artikle od 10,00 €? 2,50 €, jer je započet jedan kilometar preko 3 km.
2. Šta je test orakul? Izvor iz kojeg znamo očekivani rezultat, npr. pravila ili ručni račun.
3. Zašto se očekivani rezultat ne uzima iz programa? Jer bi test tada provjeravao samo da program radi isto kao on sam.

Odgovori: tipka R ili klik na zamućeno polje.

Praktična nastava – prvi test olovkom i Pythonom

Cilj je da svaki student napravi tabelu očekivanih rezultata za DeliveryApp rukom, zatim pokrene obje verzije koda i uporedi rezultate. Ovo je najjednostavnije testiranje: bez alata za testiranje, samo pravila, olovka i Python.

Korak 1 – Priprema

1. Instalirajte Python 3 (u učionici je instaliran) i VS Code sa ekstenzijom Python.
2. Preuzmite folder primjeri/deliveryapp/ iz repozitorija udžbenika (ili ga dobijte od nastavnika) i otvorite ga u VS Codeu.
3. Napravite GitHub repozitorij deliveryapp-testovi za svoje rezultate tokom semestra i u njega dodajte README.md s imenom i predmetom.

Korak 2 – Tabela očekivanih rezultata (rukom)

U fajl ocekivano.md napravite tabelu od najmanje 15 redova kao u 1.9: ID, ulaz, očekivani rezultat i račun po pravilu. Neka tabela obuhvati:

• bar pet udaljenosti na granicama i oko njih (0; 3; 3,01; 10; 10,01 km);
• bar tri iznosa oko granica (4,99; 5,00; 29,99; 30,00 €);
• ukupnu cijenu za N-1001 bez koda i sa kodom STUDENT10;
• kod napisan malim slovima (student10) i kod s razmacima (" STUDENT10 ");
• popust na 80,00 € (očekivano 5,00 €, jer je to gornja granica);
• pokušaj otkazivanja narudžbe u stanju U_PRIPREMI (očekivano: odbijeno, PP-6).

Sve rezultate izračunajte olovkom ili kalkulatorom, prije pokretanja programa.

Korak 3 – Pokretanje ispravne verzije

U terminalu VS Codea, u folderu deliveryapp, pokrenite Python interaktivno (python) i isprobajte:

>>> from deliveryapp import cijena_dostave, popust, ukupno, eur
>>> eur(cijena_dostave(4.2, 2150))
'3,00 €'
>>> eur(ukupno([(950, 2), (250, 1)], 4.2))
'24,50 €'
>>> eur(ukupno([(950, 2), (250, 1)], 4.2, "STUDENT10"))
'22,35 €'
>>> cijena_dostave(11, 1000)
Traceback (most recent call last):
  ...
ValueError: udaljenost izvan zone dostave

Za svaki red svoje tabele zapišite stvarni rezultat u novu kolonu. Iznosi u funkcijama su u centima: 10,00 € je 1000, a 29,99 € je 2999. Da li se ispravna verzija slaže sa svim vašim očekivanjima? Ako se ne slaže, prvo provjerite svoj račun: i tester može pogriješiti.

Za otkazivanje:

Korak 3 – Pokretanje ispravne verzije

>>> from deliveryapp import Narudzba
>>> n = Narudzba("N-1001")
>>> n.promijeni("PRIHVAĆENA"); n.promijeni("U_PRIPREMI")
>>> n.promijeni("OTKAZANA")
Traceback (most recent call last):
  ...
ValueError: nedozvoljen prelaz U_PRIPREMI -> OTKAZANA

Korak 4 – Pokretanje prve verzije

Ponovite isto s prvom verzijom: umjesto from deliveryapp import … napišite from deliveryapp_v0 import …. Zapišite stvarne rezultate u treću kolonu.

Korak 5 – Neslaganja

1. Označite svaki red u kojem se stvarni rezultat prve verzije razlikuje od očekivanog. To su otkazi.
2. Za svaki otkaz napišite jednu rečenicu po obrascu: „Za ulaz … očekivano je … (pravilo …), a program vraća … .”
3. Prebrojite otkaze. Da li mislite da je svaki otkaz drugi defekt, ili isti defekt može dati više otkaza? (Odgovor ćemo potvrditi u poglavlju 8.)

Korak 6 – AI kao pomoćnik (opcionalno)

Dajte AI asistentu pravila PP-1 do PP-6 i zatražite deset dodatnih slučajeva za vašu tabelu „koji bi mogli otkriti greške”. Za svaki predloženi slučaj sami izračunajte očekivani rezultat po pravilima; AI-jevom očekivanom rezultatu ne vjerujte bez provjere. Zapišite bar jedan slučaj u kojem je AI izračunao pogrešno, ako ga nađete.

Rezultat koji se predaje: link na repozitorij deliveryapp-testovi s fajlom ocekivano.md: tabela od najmanje 15 redova s kolonama za očekivani rezultat, stvarni rezultat ispravne i stvarni rezultat prve verzije, te spisak otkaza zapisanih po obrascu iz koraka 5.

Vježba za studenta 1 – greška, defekt ili otkaz.

Vježba za studenta 1 – greška, defekt ili otkaz. – rješenje

Vježba za studenta 2 – iscrpno testiranje.

Vježba za studenta 2 – iscrpno testiranje. – rješenje

Vježba za studenta 3 – tabela očekivanih rezultata.

Vježba za studenta 3 – tabela očekivanih rezultata. – rješenje

Vježba za studenta 4 – princip.

Vježba za studenta 4 – princip. – rješenje

Vježba za studenta 5 – izvještaj bez krivca.

Vježba za studenta 5 – izvještaj bez krivca. – rješenje

Sažetak u pet rečenica

1. Moljac iz 1947, Ariane 5 iz 1996, Knight Capital iz 2012. i CrowdStrike iz 2024. pokazuju da male greške prave velike štete, a softver šatla pokazuje da pažljiv proces daje skoro savršen softver.
2. Ljudska greška ostavlja defekt u kodu ili dokumentu, a defekt izaziva otkaz tek kad se izvrši u pravim uslovima, pa testeri namjerno biraju takve uslove.
3. Testiranje otkriva defekte i procjenjuje kvalitet, uključujući čitanje zahtjeva i preglede, a debagovanje nalazi i popravlja uzrok.
4. Sedam principa kaže da testiranje pokazuje prisustvo, a ne odsustvo defekata, da je iscrpno testiranje nemoguće, da rano testiranje štedi, da se defekti grupišu, da se testovi troše, da sve zavisi od konteksta i da softver bez defekata nije uspjeh ako ne koristi korisniku.
5. DeliveryApp ima šest pravila i dvije verzije koda, N-1001 košta 24,50 €, a svaki test traži očekivani rezultat zapisan unaprijed iz pravila, odnosno test orakul.

Pitanja za ponavljanje

1. Šta se desilo s računarom Mark II 1947. i odakle riječ „debagovanje”?
2. Zašto je uništena Ariane 5 i koja je pouka za testere?
3. Šta je pošlo naopako kod Knight Capitala?
4. Koje su dvije pouke iz događaja s CrowdStrikeom 2024?
5. Kako je tim softvera svemirskog šatla postigao skoro savršen softver?
6. Objasnite razliku između ljudske greške, defekta i otkaza na primjeru besplatne dostave.
7. Šta je testiranje? Po čemu se razlikuje od debagovanja?
8. Koja je razlika između verifikacije i validacije?
9. Navedite četiri razloga zašto testiramo.
10. Navedite sedam principa testiranja.
11. Zašto je iscrpno testiranje nemoguće? Izračunajte primjer za cijena_dostave.
12. Koje osobine ima dobar tester i kako piše o defektu?
13. Navedite šest pravila DeliveryApp i izračunajte cijenu N-1001.
14. Šta je test orakul i zašto se očekivani rezultat zapisuje prije pokretanja?