Manuelno testiranje

Šta učimo ovog semestra

Petnaest sedmica: svaka ima tri časa teorije i tri časa praktične nastave. Danas: poglavlje 3 (Sedmica 3, 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.

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.

Zašto ovo poglavlje

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.

Riječi ovog poglavlja (1/3)

• 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.

Riječi ovog poglavlja (2/3)

• 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”).

Riječi ovog poglavlja (3/3)

• 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

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:

3.1 Kada testira čovjek

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 – 3.1 Kada testira čovjek

• 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:

3.2 Anatomija test slučaja

3.2 Anatomija test slučaja

Pravila za dobar test slučaj:

1. Jedan cilj. Test „korpa, popust, dostava i otkazivanje” je četiri testa; kad padne, ne zna se šta.
2. Konkretni podaci. „Unesi neku udaljenost” nije test; „unesi 4,2” jeste.
3. Očekivani rezultat iz pravila, zapisan prije izvršavanja (test orakul, poglavlje 1).
4. Ponovljivost. Drugi tester, sutra, na drugom računaru, mora dobiti isti rezultat. Zato preduslovi kažu i stanje (prazna korpa).
5. 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 – 3.2 Anatomija test slučaja

• 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:

3.3 Scenarij, slučaj i svita

3.3 Scenarij, slučaj i svita

Ovih osam slučajeva su test svita „Narudžba – osnovno”. Na praktičnoj nastavi izvršavamo ih na web stranici.

Ukratko – 3.3 Scenarij, slučaj i svita

• 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

1. 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.
2. Zašto test slučaj mora imati konkretne podatke? Da bi bio ponovljiv: drugi tester mora dobiti isti rezultat.
3. 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.

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

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:

3.4 Izvještaj koji se može ponoviti

3.4 Izvještaj koji se može ponoviti

Pet pravila pisanja:

1. Naslov kaže šta i gdje, kratko i konkretno. Ne „bug!!!”, nego „Količina u korpi može postati negativna”.
2. Najmanji broj koraka koji izaziva otkaz. Ako se isto desi u dva koraka, ne opisuje se deset.
3. Očekivano s izvorom. „Količina ne može biti negativna” je zdrav razum; „dostava 0,00 € po PP-4” je pravilo.
4. Jedan defekt, jedan izvještaj. Dva različita problema u jednom izvještaju znače da će jedan biti zaboravljen.
5. Činjenice, ne mišljenja o ljudima. Ne „programer je opet zaboravio”, nego šta se desilo.

Ukratko – 3.4 Izvještaj koji se može ponoviti

• 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:

3.5 Ozbiljnost i prioritet

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 – 3.5 Ozbiljnost i prioritet

• 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:

1. Novi – tester ga je prijavio.
2. Dodijeljen – vođa tima ga je pregledao, odredio prioritet i dodijelio programeru.
3. Ispravljen – programer je promijenio kod i označio da je ispravljeno.
4. Potvrđen – tester je ponovio test (potvrdno testiranje, poglavlje 2) i test prolazi; defekt se zatvara.
5. 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).

3.6 Životni ciklus defekta

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 – 3.6 Životni ciklus defekta

• 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

1. Šta je glavni cilj izvještaja o defektu? Da programer može ponoviti otkaz za minutu, bez dopisivanja.
2. Može li defekt imati nisku ozbiljnost i visok prioritet? Da, npr. pogrešno napisano ime aplikacije na početnom ekranu dan prije otvaranja.
3. Kada se defekt zatvara? Kad potvrdni test, ponovljen poslije ispravke, prolazi.

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

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:

3.7 Učiti, smišljati i testirati istovremeno

• 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 – 3.7 Učiti, smišljati i testirati istovremeno

• 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:

3.8 Heuristike: kako smisliti dobar test

3.8 Heuristike: kako smisliti dobar test

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 – 3.8 Heuristike: kako smisliti dobar test

• 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:

• [ ] stranica se otvara u Chromeu, Firefoxu i na telefonu;
• [ ] N-1001 daje 24,50 €;
• [ ] poruke o greškama su na bosanskom i kažu šta uraditi;
• [ ] sva dugmad su dovoljno velika i imaju natpis;
• [ ] tekst je čitljiv uz zum 200 %;
• [ ] otkazivanje u pripremi nije moguće.

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.

3.9 Kontrolne liste i kada prestati

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 – 3.9 Kontrolne liste i kada prestati

• 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

1. Šta je povelja sesije? Kratak cilj sesije istraživanja: šta istražiti, čime i šta otkriti.
2. 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”).
3. Šta se dešava s nalazima istraživanja? Najbolji postaju novi test slučajevi, a kasnije i automatski testovi.

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

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

1. U terminalu, u folderu primjeri/deliveryapp/web/, pokrenite mali web server koji dolazi uz Python:

python -m http.server 8080

1. Otvorite u pregledniku http://localhost:8080/. To je ispravna verzija.
2. 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)

1. U repozitoriju deliveryapp-testovi napravite fajl test-slucajevi.md i 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 €.
2. Dodajte još četiri svoja test slučaja, svaki iz druge heuristike (3.8).
3. 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)

1. Izaberite jednu povelju iz 3.7 (ili napišite svoju) i zapišite je na vrh fajla sesija-1.md.
2. 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.
3. 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)

1. 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.
2. Napravite oznake defekt, ozbiljnost: visoka/srednja/niska i prioritet: visok/srednji/nizak i dodijelite ih.
3. Napravite tablu s kolonama Novi, Dodijeljen, Ispravljen, Zatvoren (GitHub Projects) i stavite defekte u kolonu Novi.
4. 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žba za studenta 1 – popravi test slučaj.

Vježba za studenta 1 – popravi test slučaj. – rješenje

Vježba za studenta 2 – popravi izvještaj o defektu.

Vježba za studenta 2 – popravi izvještaj o defektu. – rješenje

Vježba za studenta 3 – ozbiljnost i prioritet.

Vježba za studenta 3 – ozbiljnost i prioritet. – rješenje

Vježba za studenta 4 – povelja.

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

Vježba za studenta 5 – heuristike.

Vježba za studenta 5 – heuristike. – rješenje

Sažetak u pet rečenica

1. 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.
2. Manuelno testiranje izvodi čovjek i ima smisla za nove funkcije, upotrebljivost i istraživanje, dok se ono što se ponavlja automatizuje.
3. 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.
4. 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.
5. 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.

Pitanja za ponavljanje

1. Kako je Thomas Nicely pronašao grešku u Pentiumu i šta je pouka za testere?
2. Kada ima smisla manuelno, a kada automatizovano testiranje?
3. Koje dijelove ima test slučaj?
4. Navedite pet pravila dobrog test slučaja.
5. Koja je razlika između test scenarija, test slučaja i test svite?
6. Šta sadrži dobar izvještaj o defektu?
7. Zašto je „korpa ne radi” loš izvještaj?
8. Objasnite razliku između ozbiljnosti i prioriteta i dajte primjer gdje se razlikuju.
9. Opišite životni ciklus defekta.
10. Šta je istraživačko testiranje i po čemu se razlikuje od nasumičnog klikanja?
11. Kako izgleda povelja sesije? Napišite jednu za DeliveryApp.
12. Navedite šest heuristika za smišljanje testova.
13. Šta su ture u istraživačkom testiranju?
14. Šta je kontrolna lista i kada testiranje prestaje?