Poglavlje 3: Manuelno testiranje
Priča za početak. U ljeto 1994. godine Thomas Nicely, profesor matematike na koledžu Lynchburg u američkoj državi Virginia, radio je na istraživanju o prostim brojevima. Računao je zbir recipročnih vrijednosti (1/p) za ogroman broj parova prostih brojeva, na nekoliko računara. Primijetio je nešto što ne bi primijetio niko ko ne računa pažljivo: rezultati na jednom novom računaru s procesorom Intel Pentium malo su se razlikovali od rezultata drugih računara. Mjesecima je isključivao druge uzroke: svoj program, kompajler, operativni sistem. Na kraju je bio siguran: sam procesor pogrešno dijeli neke brojeve. Kasnije je postao poznat primjer: 4 195 835 / 3 145 727 tačno je oko 1,33382, a pogrešni Pentium davao je oko 1,33374. Nicely je 24. oktobra 1994. o tome pisao Intelu, a zatim i kolegama. Intel je prvo tvrdio da će greška običnog korisnika pogoditi rijetko i nudio zamjenu samo onima koji dokažu da im treba. Pod pritiskom javnosti, u decembru je ponudio zamjenu svakome, a u januaru 1995. objavio trošak od 475 miliona dolara. Grešku nije našao automatski test, nego čovjek koji je pažljivo posmatrao rezultate i nije prihvatio „vjerovatno je u redu”. To je duh manuelnog i istraživačkog testiranja.
U poglavlju 2 naučili smo kako je testiranje organizovano: proces, nivoi, vrste i recenzije. Ovo poglavlje uči testiranje koje radi čovjek, bez alata za automatizaciju: manuelno testiranje. Prvo pišemo jasne test slučajeve koje bilo ko može ponoviti. Zatim učimo da napišemo izvještaj o defektu po kojem programer može naći problem za minutu, i pratimo život defekta od prijave do zatvaranja. Na kraju učimo istraživačko testiranje, u kojem tester istovremeno uči sistem i traži greške, kao profesor Nicely. Na praktičnoj nastavi testiramo web stranicu DeliveryApp: prvo po test slučajevima, pa slobodnim istraživanjem prve verzije, i prijavljujemo defekte.
Literatura. Osnovna literatura predmeta:
- J. Popović: Priručnik za test inženjere, CET i Računarski fakultet, Beograd, 2023.
- Rakić-Skoković: Priručnik za testiranje softvera, Fakultet tehničkih nauka, Novi Sad, 2013.
- G. J. Myers: The Art of Software Testing, 2. izdanje, John Wiley & Sons, 2004.
- A. P. Mathur: Foundations of Software Testing, Addison-Wesley Professional, 2008.
Riječi ovog poglavlja.
- Manuelno testiranje – testiranje koje izvodi čovjek, korak po korak, bez skripti za automatizaciju.
- Test slučaj – opis jednog testa: preduslovi, koraci, podaci i očekivani rezultat.
- Test scenarij – opis jedne situacije korištenja koju treba provjeriti, od koje nastaje više test slučajeva.
- Test svita – grupa test slučajeva koja se izvršava zajedno (npr. svi testovi korpe).
- Izvještaj o defektu – zapis o otkazu: šta je urađeno, šta je očekivano, šta se desilo, kako ponoviti.
- Ozbiljnost (severity) – koliko defekt šteti sistemu ili korisniku.
- Prioritet (priority) – koliko hitno defekt treba ispraviti.
- Životni ciklus defekta – stanja kroz koja prolazi prijavljeni defekt: novi, dodijeljen, ispravljen, potvrđen, zatvoren.
- Istraživačko testiranje – testiranje u kojem tester istovremeno uči sistem, osmišljava testove i izvršava ih.
- Povelja sesije (charter) – kratak cilj jedne sesije istraživanja: šta, čime i zašto.
- Sesija – vremenski ograničen blok istraživačkog testiranja, obično 60 do 90 minuta.
- Heuristika – iskustveno pravilo koje pomaže da se smisli dobar test (npr. „probaj nulu”).
- Kontrolna lista – spisak stvari koje treba provjeriti, bez detaljnih koraka.
Ciljevi poglavlja. Nakon poglavlja možete: reći kada manuelno testiranje ima smisla, a kada ne; napisati test slučaj s preduslovima, koracima, podacima i očekivanim rezultatom; razlikovati test scenarij, test slučaj i test svitu; napisati izvještaj o defektu koji se može ponoviti; razlikovati ozbiljnost i prioritet na primjerima; opisati životni ciklus defekta; objasniti istraživačko testiranje i napisati povelju sesije; koristiti heuristike za smišljanje testova; testirati web stranicu DeliveryApp po test slučajevima i istraživanjem i prijaviti defekte na GitHubu.
Plan poglavlja – Sedmica 3: tri časa teorije i tri časa praktične nastave
| Čas | Sadržaj | Na času |
|---|---|---|
| Teorija 1 | 3.1–3.3 Manuelno testiranje; test slučaj; scenarij i svita | TS-KOR-01: dodaj dvije Margarite |
| Teorija 2 | 3.4–3.6 Izvještaj o defektu; ozbiljnost i prioritet; životni ciklus | „Količina −1” kao izvještaj |
| Teorija 3 | 3.7–3.9 Istraživačko testiranje; povelja i sesija; heuristike | Nicely 1994; 45 minuta istraživanja |
| Praksa 1–3 | Web stranica DeliveryApp: test slučajevi, istraživanje v0, izvještaji | GitHub Issues s defektima |
Dio 1 – Test slučaj
3.1 Kada testira čovjek
Manuelno testiranje je testiranje koje izvodi čovjek: otvori aplikaciju, klikne, upiše, pogleda rezultat i uporedi ga s očekivanim. U poglavlju 4 učimo automatizovano testiranje, gdje to radi program. Oba su potrebna, za različite stvari:
| Manuelno ima smisla | Automatizovano ima smisla |
|---|---|
| nova funkcija koja se još mijenja svaki dan | stabilna pravila koja se provjeravaju pri svakoj izmjeni |
| procjena izgleda i upotrebljivosti („je li jasno?”) | račun s mnogo kombinacija (granice dostave) |
| istraživanje: „šta bi moglo poći naopako?” | regresija: „je li sve što je radilo i dalje radi?” |
| jednokratna provjera (npr. prije prezentacije) | test koji se ponavlja stotine puta |
| situacije koje je teško automatizovati (stvarni telefon na suncu) | provjera performansi s 200 korisnika |
Manuelno testiranje nije „lošije” testiranje. Čovjek primijeti ono što skripta ne vidi: da je poruka nejasna, da dugme izgleda kao da je neaktivno, da je nešto „čudno”, kao profesor Nicely. Ali čovjek se umara, preskoči korak i ne može hiljadu puta dnevno ponoviti isto. Zato dobar tim manuelno testira ono što traži ljudsko oko i rasuđivanje, a automatizuje ono što se ponavlja.
Ukratko.
- Manuelno testiranje izvodi čovjek, korak po korak.
- Ima smisla za nove funkcije, upotrebljivost, istraživanje i jednokratne provjere.
- Automatizovano ima smisla za stabilna pravila, mnogo kombinacija i regresiju.
- Čovjek primijeti ono što skripta ne vidi, ali se umara i ne ponavlja hiljadu puta.
3.2 Anatomija test slučaja
Test slučaj je opis jednog testa, napisan tako da ga bilo ko može izvesti i dobiti isti rezultat. Dobar test slučaj ima ove dijelove:
| Dio | Značenje | Primjer |
|---|---|---|
| ID | jedinstvena oznaka | TS-KOR-01 |
| Naslov | šta provjerava, jednom rečenicom | Dodavanje dvije Margarite i soka daje 24,50 € na 4,2 km |
| Pravilo / zahtjev | odakle je očekivani rezultat (sljedivost) | PP-2, PP-4; kriterij prihvatanja priče „vidjeti cijenu dostave” |
| Preduslovi | stanje prije testa | stranica otvorena, korpa prazna |
| Podaci | konkretne vrijednosti | udaljenost 4,2 km; kod prazan |
| Koraci | numerisane radnje | 1. Kliknuti „+” uz Pizza Margarita dva puta. 2. Kliknuti „+” uz Sok jednom. 3. Pogledati pregled. |
| Očekivani rezultat | šta mora biti, prema pravilu | Artikli 21,50 €; Dostava 3,00 €; Ukupno 24,50 €; dugme „Naruči” aktivno |
| Stvarni rezultat | šta se desilo (upisuje se pri izvršavanju) | … |
| Status | prošao / pao / blokiran / nije izvršen | … |
Pravila za dobar test slučaj:
- Jedan cilj. Test „korpa, popust, dostava i otkazivanje” je četiri testa; kad padne, ne zna se šta.
- Konkretni podaci. „Unesi neku udaljenost” nije test; „unesi 4,2” jeste.
- Očekivani rezultat iz pravila, zapisan prije izvršavanja (test orakul, poglavlje 1).
- Ponovljivost. Drugi tester, sutra, na drugom računaru, mora dobiti isti rezultat. Zato preduslovi kažu i stanje (prazna korpa).
- Nezavisnost. Test ne smije zavisiti od toga da je neki drugi test izvršen prije njega; ako zavisi, to piše u preduslovima.
Slika iz života: test slučaj je recept. Recept „pomiješaj malo brašna i jaja i peci dok ne bude gotovo” ne daje isti kolač dvaput. Recept „250 g brašna, 3 jaja, 180 °C, 35 minuta” daje.
Ukratko.
- Test slučaj ima ID, naslov, pravilo, preduslove, podatke, korake, očekivani i stvarni rezultat i status.
- Dobar test slučaj ima jedan cilj, konkretne podatke, očekivani rezultat iz pravila, ponovljiv je i nezavisan.
- Kao recept s tačnim količinama: daje isti rezultat svaki put.
3.3 Scenarij, slučaj i svita
Tri riječi opisuju tri veličine:
- Test scenarij je situacija koju treba provjeriti, rečena opšte, često iz ugla korisnika: „Kupac naručuje hranu i plaća.” Od jednog scenarija nastaje više test slučajeva.
- Test slučaj je jedan konkretan put kroz scenarij (3.2).
- Test svita (test suite) je grupa test slučajeva koji se izvršavaju zajedno, npr. „svi testovi korpe” ili „dim-test” iz poglavlja 2.
Za web stranicu DeliveryApp, scenarij „Kupac pravi narudžbu iz Picerije R-1” daje, na primjer:
| ID | Naslov | Podaci | Očekivano |
|---|---|---|---|
| TS-KOR-01 | N-1001 na 4,2 km | 2 × Margarita, 1 × Sok; 4,2 km | Ukupno 24,50 € |
| TS-KOR-02 | ista narudžba sa kodom | isto; kod STUDENT10 | Popust 2,15 €; Ukupno 22,35 € |
| TS-KOR-03 | premala narudžba | 1 × Sok; 2 km | poruka o najmanjoj narudžbi; „Naruči” neaktivno |
| TS-KOR-04 | izvan zone | 2 × Margarita; 11 km | poruka „izvan zone dostave (najviše 10 km)”; „Naruči” neaktivno |
| TS-KOR-05 | besplatna dostava | 2 × Capricciosa, 3 × Margarita (50,50 €); 5 km | Dostava 0,00 €; poruka „Dostava je besplatna” |
| TS-KOR-06 | uklanjanje stavke | dodati pa ukloniti Margaritu | korpa prazna; artikli 0,00 € |
| TS-NAR-01 | otkazivanje prije pripreme | narudžba u stanju NOVA | stanje OTKAZANA, poruka o povratu novca |
| TS-NAR-02 | otkazivanje u pripremi | prihvati, počni pripremu, otkaži | poruka „Nije moguće…”; stanje ostaje U_PRIPREMI |
Ovih osam slučajeva su test svita „Narudžba – osnovno”. Na praktičnoj nastavi izvršavamo ih na web stranici.
Ukratko.
- Test scenarij je situacija rečena opšte; test slučaj je jedan konkretan put kroz nju; test svita je grupa slučajeva koji se izvršavaju zajedno.
- Scenarij „kupac pravi narudžbu iz R-1” daje osam slučajeva, od N-1001 do otkazivanja u pripremi.
- Svita se izvršava kao cjelina i daje sliku stanja jedne funkcije.
Provjeri se.
- Kada je manuelno testiranje bolji izbor od automatizovanog? – Za nove funkcije koje se još mijenjaju, za procjenu upotrebljivosti, za istraživanje i za jednokratne provjere.
- Zašto test slučaj mora imati konkretne podatke? – Da bi bio ponovljiv: drugi tester mora dobiti isti rezultat.
- Koja je razlika između test scenarija i test slučaja? – Scenarij je situacija rečena opšte, a test slučaj jedan konkretan put kroz nju s podacima i očekivanim rezultatom.
Dio 2 – Izvještaj o defektu
3.4 Izvještaj koji se može ponoviti
Kad test padne, tester piše izvještaj o defektu (bug report). Cilj izvještaja je jedan: da programer ponovi otkaz za minutu, bez dopisivanja s testerom. Izvještaj koji kaže „korpa ne radi” je beskoristan; programer ne zna šta je urađeno, šta je očekivano, ni šta se desilo.
Dobar izvještaj ima:
| Dio | Primjer |
|---|---|
| ID i naslov | DEF-07: Količina u korpi može postati negativna (−1 × Margarita) |
| Okruženje | stranica web/index.html?v=0, Chrome 129, Windows 11 |
| Preduslovi | korpa prazna |
| Koraci za ponavljanje | 1. Otvoriti stranicu. 2. Kliknuti „−” uz Pizza Margarita jednom. |
| Očekivani rezultat | količina ostaje 0; korpa prazna (količina ne može biti negativna) |
| Stvarni rezultat | u korpi piše „−1 × Pizza Margarita −9,50 €”; artikli −9,50 € |
| Dokaz | snimak ekrana def-07.png |
| Ozbiljnost | srednja: pogrešan iznos, ali narudžba se ne može platiti (poruka o minimumu) |
| Prioritet | visok: lako se desi i zbunjuje kupca |
| Učestalost | uvijek (10 od 10 pokušaja) |
Pet pravila pisanja:
- Naslov kaže šta i gdje, kratko i konkretno. Ne „bug!!!”, nego „Količina u korpi može postati negativna”.
- Najmanji broj koraka koji izaziva otkaz. Ako se isto desi u dva koraka, ne opisuje se deset.
- Očekivano s izvorom. „Količina ne može biti negativna” je zdrav razum; „dostava 0,00 € po PP-4” je pravilo.
- Jedan defekt, jedan izvještaj. Dva različita problema u jednom izvještaju znače da će jedan biti zaboravljen.
- Činjenice, ne mišljenja o ljudima. Ne „programer je opet zaboravio”, nego šta se desilo.
Česta zabluda. „Ako sam ga našao, programer će ga lako naći i sam.” Programer nije bio pored vas kad se desilo. Ne zna koji preglednik koristite, šta je bilo u korpi, ni koje dugme ste pritisnuli prvo. Bez tačnih koraka, odgovor je često „kod mene radi” i izvještaj se zatvara.
Ukratko.
- Izvještaj o defektu omogućava programeru da ponovi otkaz za minutu.
- Ima naslov, okruženje, preduslove, korake, očekivani i stvarni rezultat, dokaz, ozbiljnost, prioritet i učestalost.
- Naslov kaže šta i gdje, koraka je što manje, očekivano ima izvor, a jedan izvještaj opisuje jedan defekt.
- Izvještaj opisuje činjenice, a ne ljude.
3.5 Ozbiljnost i prioritet
Dvije oznake se često miješaju, a znače različito:
- Ozbiljnost (severity) kaže koliko defekt šteti: da li ruši sistem, daje pogrešan novac, ili je samo kozmetički.
- Prioritet (priority) kaže koliko je hitno ispraviti ga, uzimajući u obzir i štetu i koliko često se dešava, i poslovne razloge.
Obično idu zajedno, ali ne uvijek:
| Defekt | Ozbiljnost | Prioritet | Zašto |
|---|---|---|---|
| dostava se naplaćuje za 30,00 € (treba 0,00 €) | visoka (pogrešan novac) | visok | dešava se često; kupci gube novac |
| ime „DeliveryApp” na početnom ekranu napisano „Zalgoaj” | niska (kozmetika) | visok | vidi ga svaki kupac; sramota pred sutrašnjim otvaranjem |
| mjesečni izvještaj za administratora pada za mjesec s 31 danom | visoka (funkcija ne radi) | srednji | izvještaj se pravi jednom mjesečno, postoji zaobilazni put |
| poravnanje teksta u podnožju stranice pomjereno za 2 piksela | niska | nizak | skoro niko ne primijeti |
Ozbiljnost obično određuje tester (koliko šteti), a prioritet vlasnik proizvoda ili vođa tima (koliko je hitno, s obzirom na sve ostalo). Česte skale su: ozbiljnost kritična, visoka, srednja, niska; prioritet visok, srednji, nizak.
Ukratko.
- Ozbiljnost kaže koliko defekt šteti, a prioritet koliko je hitno ispraviti ga.
- Kozmetička greška u imenu aplikacije može imati nisku ozbiljnost i visok prioritet.
- Rijetko korišten izvještaj koji pada može imati visoku ozbiljnost i srednji prioritet.
- Ozbiljnost obično određuje tester, a prioritet vlasnik proizvoda.
3.6 Životni ciklus defekta
Prijavljen defekt prolazi kroz stanja, slično narudžbi u DeliveryApp. Tipičan životni ciklus defekta:
- Novi – tester ga je prijavio.
- Dodijeljen – vođa tima ga je pregledao, odredio prioritet i dodijelio programeru.
- Ispravljen – programer je promijenio kod i označio da je ispravljeno.
- Potvrđen – tester je ponovio test (potvrdno testiranje, poglavlje 2) i test prolazi; defekt se zatvara.
- Ponovo otvoren – ako test i dalje pada, defekt se vraća programeru.
Postoje i bočni izlazi: odbijen (nije defekt, nego pogrešno razumijevanje pravila), duplikat (već je prijavljen), odgođen (pravi je defekt, ali se ispravlja u nekom kasnijem izdanju).
stateDiagram-v2
[*] --> Novi
Novi --> Dodijeljen: pregled i prioritet
Novi --> Odbijen: nije defekt
Novi --> Duplikat: već prijavljen
Dodijeljen --> Ispravljen: programer ispravio
Dodijeljen --> Odgođen: kasnije izdanje
Ispravljen --> Zatvoren: potvrdni test prolazi
Ispravljen --> PonovoOtvoren: test i dalje pada
PonovoOtvoren --> Ispravljen: nova ispravka
Zatvoren --> [*]Na GitHubu se ovaj ciklus vodi kroz Issues i oznake (labels): defekt, ozbiljnost: visoka, prioritet: visok, a stanja kroz kolone table (Novi, U radu, Za potvrdu, Zatvoreno). Dobra navika je da se u izmjeni koda (pull request, poglavlje 14) napiše „Ispravlja #7”, pa GitHub sam poveže ispravku s izvještajem.
Ukratko.
- Defekt prolazi stanja: novi, dodijeljen, ispravljen, potvrđen i zatvoren, ili ponovo otvoren.
- Bočni izlazi su odbijen, duplikat i odgođen.
- Zatvara se tek kad potvrdni test prolazi.
- Na GitHubu ciklus se vodi kroz Issues, oznake i kolone table.
Provjeri se.
- Šta je glavni cilj izvještaja o defektu? – Da programer može ponoviti otkaz za minutu, bez dopisivanja.
- Može li defekt imati nisku ozbiljnost i visok prioritet? – Da, npr. pogrešno napisano ime aplikacije na početnom ekranu dan prije otvaranja.
- Kada se defekt zatvara? – Kad potvrdni test, ponovljen poslije ispravke, prolazi.
Dio 3 – Istraživačko testiranje
3.7 Učiti, smišljati i testirati istovremeno
Test slučajevi iz 3.2 su unaprijed napisani: tester zna šta će raditi prije nego što počne. To je dobro za ponovljivost, ali ima manu: provjerava samo ono čega se neko sjetio unaprijed. Profesor Nicely nije imao test slučaj „podijeli 4 195 835 sa 3 145 727”. Primijetio je neslaganje dok je radio, i onda ga istraživao.
Istraživačko testiranje (exploratory testing) je testiranje u kojem tester istovremeno uči sistem, smišlja testove i izvršava ih. Svaki rezultat utiče na sljedeći test: „Ako je količina mogla postati −1, šta je s ukupnom cijenom? A ako sada dodam dvije pizze, da li se −1 sabira?” Ovaj način rada otkriva defekte koje niko nije predvidio, i obično ih otkriva brzo.
Istraživačko testiranje nije nasumično klikanje. Ima strukturu:
- povelju (charter): jasan cilj sesije;
- vremensko ograničenje: sesija od 60 do 90 minuta, bez prekida;
- bilješke: šta je probano, šta je primijećeno, koja pitanja su otvorena;
- izvještaj na kraju: nađeni defekti, pitanja i ideje za nove test slučajeve.
Ovaj oblik se zove testiranje u sesijama (session-based testing).
Povelja ima jednostavan oblik: „Istraži 〈cilj〉 s 〈sredstvima〉 da otkriješ 〈vrstu informacije〉.” Primjeri za DeliveryApp:
- „Istraži korpu s dodavanjem i uklanjanjem u neobičnom redoslijedu da otkriješ greške u količinama i zbiru.”
- „Istraži polje za udaljenost s neobičnim unosima (zarez, prazno, slova, vrlo veliki brojevi) da otkriješ greške u provjeri unosa.”
- „Istraži otkazivanje s različitim stanjima narudžbe da otkriješ prekršaje pravila PP-6.”
Ukratko.
- Istraživačko testiranje istovremeno uči sistem, smišlja testove i izvršava ih.
- Otkriva defekte kojih se niko nije sjetio unaprijed, kao Nicely 1994.
- Nije nasumično: ima povelju, vremensko ograničenje, bilješke i izvještaj.
- Povelja glasi „Istraži 〈cilj〉 s 〈sredstvima〉 da otkriješ 〈informaciju〉.”
3.8 Heuristike: kako smisliti dobar test
Iskusni testeri imaju u glavi spisak heuristika: iskustvenih pravila „šta obično pokvari program”. Nekoliko najkorisnijih, na DeliveryApp:
| Heuristika | Šta probati | U DeliveryApp |
|---|---|---|
| Granice | tačno na granici, malo ispod, malo iznad | 3 km, 3,01 km; 30,00 €, 29,99 €; 10 km, 10,01 km |
| Nula i prazno | 0, prazno polje, ništa u korpi | udaljenost 0; prazan kod; naruči s praznom korpom |
| Negativno | broj manji od nule | udaljenost −1; „−” na praznoj korpi |
| Previše | vrlo velike vrijednosti, vrlo dug tekst | 999 pizza; kod od 500 znakova |
| Pogrešan tip | slova gdje se očekuje broj, zarez umjesto tačke | udaljenost „četiri”, „4,2” umjesto „4.2” |
| Pogrešan redoslijed | uraditi korake drugim redom | otkazati prije nego što restoran prihvati; promijeniti kod poslije narudžbe |
| Ponavljanje | ista radnja dvaput brzo | dvaput kliknuti „Naruči” |
| Prekid | prekinuti usred posla | osvježiti stranicu usred narudžbe; isključiti internet |
| Velika i mala slova, razmaci | ista vrijednost napisana drugačije | „student10”, „ STUDENT10 ”, „Student10” |
| Promjena okruženja | drugi preglednik, mali ekran, uvećan tekst | telefon, tablet; zum 200 % |
Druga korisna tehnika su ture (tours), po ideji da se aplikacija obilazi kao turistički grad, svaki put s drugom temom:
- tura novca: pratite svaki cent od korpe do ukupnog iznosa;
- tura granica: obiđite sve granice iz pravila;
- tura prekida: na svakom koraku probajte nazad, osvježi, zatvori;
- tura „zločesti kupac”: radite sve što kupac ne bi trebao (negativno, prazno, dvaput).
Kad sesija završi, njeni najbolji nalazi postaju novi test slučajevi (i kasnije automatski testovi), da se isti defekt ne vrati. Tako istraživanje i unaprijed napisani testovi rade zajedno.
Ukratko.
- Heuristike su iskustvena pravila za smišljanje testova: granice, nula, negativno, previše, pogrešan tip, redoslijed, ponavljanje, prekid, velika i mala slova, okruženje.
- Ture obilaze aplikaciju s temom: novac, granice, prekidi, „zločesti kupac”.
- Najbolji nalazi istraživanja postaju novi test slučajevi.
3.9 Kontrolne liste i kada prestati
Između detaljnih test slučajeva i slobodnog istraživanja je kontrolna lista: spisak stvari koje treba provjeriti, bez detaljnih koraka. Npr. kontrolna lista prije svakog izdanja web stranice DeliveryApp:
Kontrolna lista je brza i dobra za iskusne testere; manje je ponovljiva od test slučajeva, ali mnogo brža za pisanje i održavanje.
Kada prestati? Testiranje se nikad ne završava „jer više nema grešaka” (princip 1). Prestaje se kad su ispunjeni izlazni kriteriji dogovoreni u planu (poglavlje 14), na primjer: svi test slučajevi visokog prioriteta izvršeni; nema otvorenih defekata visoke ozbiljnosti; svaka povelja iz plana istražena bar jednom; nova sesija istraživanja dva puta zaredom nije našla ništa novo.
Ukratko.
- Kontrolna lista je spisak stvari za provjeru bez detaljnih koraka: brža, ali manje ponovljiva od test slučajeva.
- Testiranje ne prestaje kad „nema grešaka”, nego kad su ispunjeni dogovoreni izlazni kriteriji.
- Primjer kriterija: izvršeni svi važni test slučajevi i nema otvorenih ozbiljnih defekata.
Provjeri se.
- Šta je povelja sesije? – Kratak cilj sesije istraživanja: šta istražiti, čime i šta otkriti.
- Navedite tri heuristike i primjer za svaku. – Npr. granice (3 km i 3,01 km), nula i prazno (udaljenost 0, prazan kod), ponavljanje (dvaput kliknuti „Naruči”).
- Šta se dešava s nalazima istraživanja? – Najbolji postaju novi test slučajevi, a kasnije i automatski testovi.
Praktična nastava – testiramo web stranicu DeliveryApp
Cilj je izvršiti test svitu na ispravnoj verziji web stranice, zatim istraživati prvu verziju i prijaviti defekte kao GitHub Issues. Radi se u parovima.
Korak 1 – Pokretanje stranice
- U terminalu, u folderu
primjeri/deliveryapp/web/, pokrenite mali web server koji dolazi uz Python:
python -m http.server 8080- Otvorite u pregledniku
http://localhost:8080/. To je ispravna verzija. - Prva verzija s greškama je na
http://localhost:8080/?v=0(u naslovu piše „verzija v0”).
Korak 2 – Test svita na ispravnoj verziji (45 minuta)
- U repozitoriju
deliveryapp-testovinapravite fajltest-slucajevi.mdi u njega prepišite osam test slučajeva iz 3.3, svaki u punom obliku iz 3.2 (ID, naslov, pravilo, preduslovi, podaci, koraci, očekivani rezultat). Za TS-KOR-05 provjerite rukom: 2 × 11,00 + 3 × 9,50 = 50,50 €. - Dodajte još četiri svoja test slučaja, svaki iz druge heuristike (3.8).
- Izvršite svih 12 na ispravnoj verziji. Upišite stvarni rezultat i status. Ako neki pada na ispravnoj verziji, prvo provjerite svoj očekivani rezultat; ako je on tačan, prijavili ste defekt i u ispravnoj verziji.
Korak 3 – Ista svita na prvoj verziji (30 minuta)
Izvršite istih 12 test slučajeva na ?v=0. Za svaki test koji pada zabilježite stvarni rezultat. Ne pokušavajte još da pogodite uzrok u kodu; to je posao debagovanja.
Korak 4 – Sesija istraživanja (45 minuta)
- Izaberite jednu povelju iz 3.7 (ili napišite svoju) i zapišite je na vrh fajla
sesija-1.md. - Uključite štopericu na 45 minuta i istražujte prvu verziju (
?v=0) po toj povelji, uz heuristike iz 3.8. Partner zapisuje bilješke: vrijeme, šta je probano, šta je primijećeno. - Na kraju napišite kratak izvještaj sesije: povelja, trajanje, nađeni defekti, otvorena pitanja, i bar dvije ideje za nove test slučajeve.
Korak 5 – Izvještaji o defektima na GitHubu (30 minuta)
- Za svaki otkaz iz koraka 3 i 4 otvorite GitHub Issue po obrascu iz 3.4 (naslov, okruženje, preduslovi, koraci, očekivano s pravilom, stvarno, dokaz, ozbiljnost, prioritet, učestalost). Dodajte snimak ekrana.
- Napravite oznake
defekt,ozbiljnost: visoka/srednja/niskaiprioritet: visok/srednji/nizaki dodijelite ih. - Napravite tablu s kolonama Novi, Dodijeljen, Ispravljen, Zatvoren (GitHub Projects) i stavite defekte u kolonu Novi.
- Razmijenite repozitorije s drugim parom: oni pokušaju ponoviti svaki vaš defekt samo po izvještaju. Koliko ih je uspjelo ponoviti iz prvog pokušaja? Doradite izvještaje koje nisu mogli ponoviti.
Korak 6 – AI kao pomoćnik (opcionalno)
Dajte AI asistentu opis stranice (jelovnik, korpa, udaljenost, kod, otkazivanje) i pravila PP-1 do PP-6 i zatražite pet povelja za istraživačke sesije. Ocijenite ih: da li su konkretne („Istraži … s … da otkriješ …”) ili opšte („testiraj sve”)? Izaberite jednu i izvedite je kao drugu sesiju. U AI razgovor ne lijepite snimke ekrana s ličnim podacima; ovdje su svi podaci izmišljeni.
Rezultat koji se predaje: test-slucajevi.md sa 12 test slučajeva i rezultatima za obje verzije, sesija-1.md s poveljom, bilješkama i izvještajem, i link na GitHub Issues s izvještajima o defektima, oznakama i tablom.
Vježbe
Vježba za studenta 1 – popravi test slučaj.
Prepišite u dobar test slučaj: „Provjeri da korpa radi kako treba sa popustom i da je sve ok.”
Rješenje. ID: TS-KOR-02. Naslov: Kod STUDENT10 daje 10 % popusta na N-1001. Pravilo: PP-5. Preduslovi: stranica otvorena, korpa prazna. Podaci: 2 × Margarita, 1 × Sok, 4,2 km, kod STUDENT10. Koraci: 1. Dodati dvije Margarite. 2. Dodati jedan Sok. 3. Upisati 4.2 u udaljenost. 4. Upisati STUDENT10 u kod. Očekivano: Artikli 21,50 €, Popust 2,15 €, Dostava 3,00 €, Ukupno 22,35 €.
Vježba za studenta 2 – popravi izvještaj o defektu.
Prepišite: „Kod ne radi!!! Probao sam više puta, popust je nula. Hitno popraviti.”
Rješenje. Naslov: Kod popusta napisan malim slovima ne daje popust. Okruženje: index.html?v=0, Chrome. Preduslovi: korpa prazna. Koraci: 1. Dodati 2 × Margarita i 1 × Sok. 2. Udaljenost 4.2. 3. Kod student10. Očekivano: popust 2,15 €, ukupno 22,35 € (PP-5: velika ili mala slova). Stvarno: popust 0,00 €, ukupno 24,50 €. Ozbiljnost: srednja. Prioritet: visok (mnogo studenata kuca malim slovima). Učestalost: uvijek.
Vježba za studenta 3 – ozbiljnost i prioritet.
Odredite ozbiljnost i prioritet i obrazložite: a) aplikacija se ruši kad kupac s iPhonea doda više od 20 jela; b) u engleskom prevodu jelovnika piše „Ćevapi” bez objašnjenja; c) restoran ne dobija obavještenje o novoj narudžbi; d) boja dugmeta „Naruči” nije ista kao na dizajnu.
Rješenje. a) ozbiljnost visoka (pad), prioritet srednji ili visok, zavisno od toga koliko često neko naruči više od 20 jela; b) niska, nizak (kozmetika i prevod); c) kritična, visok (narudžba se gubi, a to je glavna funkcija); d) niska, nizak (osim ako je kontrast ispod WCAG granice; tada srednja).
Vježba za studenta 4 – povelja.
Napišite povelju za sesiju istraživanja polja „Kod popusta”.
Rješenje. „Istraži polje za kod popusta s različitim zapisima koda (velika i mala slova, razmaci, slični kodovi, prazno, vrlo dug tekst, specijalni znakovi) da otkriješ greške u prepoznavanju koda i u iznosu popusta.”
Vježba za studenta 5 – heuristike.
Za polje „Udaljenost (km)” napišite šest testnih vrijednosti, svaku iz druge heuristike, s očekivanim rezultatom (artikli 21,50 €).
Rješenje. Granica: 3 → dostava 2,00 €. Malo iznad granice: 3.01 → 2,50 €. Nula: 0 → 2,00 €. Negativno: −1 → poruka „izvan zone”, „Naruči” neaktivno. Previše: 1000 → „izvan zone”. Pogrešan tip: „četiri” ili prazno → stranica ne smije pokazati cijenu; očekivana poruka o neispravnoj udaljenosti (ako je nema, to je nalaz za izvještaj).
Sažetak u pet rečenica
- Profesor Nicely je 1994. pažljivim posmatranjem rezultata našao grešku u dijeljenju procesora Pentium, koja je Intel koštala 475 miliona dolara, a to je duh manuelnog i istraživačkog testiranja.
- Manuelno testiranje izvodi čovjek i ima smisla za nove funkcije, upotrebljivost i istraživanje, dok se ono što se ponavlja automatizuje.
- Dobar test slučaj ima jedan cilj, konkretne podatke, preduslove, korake i očekivani rezultat iz pravila, pa ga bilo ko može ponoviti, a test slučajevi se grupišu u scenarije i svite.
- Izvještaj o defektu omogućava programeru da ponovi otkaz za minutu, ozbiljnost i prioritet znače različito, a defekt prolazi životni ciklus od novog do zatvorenog poslije potvrdnog testa.
- Istraživačko testiranje u sesijama s poveljom, heuristikama i turama nalazi defekte kojih se niko nije sjetio unaprijed, a najbolji nalazi postaju novi test slučajevi.