Proces i nivoi testiranja

Šta učimo ovog semestra

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

Dana 27. marta 2008. godine na londonskom aerodromu Heathrow otvoren je novi, ogroman Terminal 5, ponos britanske avijacije, napravljen za nekoliko milijardi funti. Srce terminala bio je automatski sistem za prtljag: kilometri traka i računari koji su trebali svaki kofer odvesti do pravog aviona. Prvog jutra sistem je počeo zastajati. Radnici nisu mogli ući na vrijeme jer nisu znali gdje je parking za osoblje, nekoliko traka je stalo, a softver nije znao šta da radi s koferima koji su stigli kad ih nije očekivao. Već prvog dana otkazani su deseci letova, a putnici su putovali bez prtljaga.

Prema izvještajima iz tih dana, u prvih nekoliko dana otkazano je skoro 300 letova, a oko 15 000 kofera odvojeno je od vlasnika. Sistem je prije otvaranja testiran, ali uglavnom dio po dio. Ono što nije dovoljno testirano bilo je sve zajedno: hiljade stvarnih kofera, stvarni radnici koji prvi put rade u novoj zgradi, i sve situacije koje se dešavaju u pravom jutru na aerodromu. Jedan dio sistema radio je, drugi dio je radio, ali sistem nije radio.

Zašto ovo poglavlje

U poglavlju 1 naučili smo šta su defekt i otkaz i zašto testiramo, i napravili prvu tabelu očekivanih rezultata. Ovo poglavlje odgovara na pitanje kako je testiranje organizovano. Prvo upoznajemo test proces: korake od planiranja do izvještaja. Zatim nivoe testiranja, od jedne funkcije do cijelog sistema u rukama korisnika, i kako se slažu u V-model i u agilni rad. Na kraju vrste testova i statičko testiranje: pronalaženje defekata čitanjem, bez pokretanja programa. Na praktičnoj nastavi radimo recenziju zahtjeva DeliveryApp i nalazimo nejasnoću koja je promakla svima, pa i programerima.

Riječi ovog poglavlja (1/3)

• Test proces – dogovoren niz aktivnosti testiranja: planiranje, analiza, dizajn, implementacija, izvršavanje i završetak.
• Test baza – dokumenti iz kojih izvodimo testove (zahtjevi, pravila, modeli, kod).
• Test uslov – nešto što treba provjeriti (npr. „besplatna dostava na granici 30,00 €”).
• Test slučaj – konkretan ulaz, koraci i očekivani rezultat za jedan test uslov.
• Testni materijal (testware) – sve što testiranje proizvede: plan, test slučajevi, podaci, skripte, izvještaji.
• Nivo testiranja – grupa testova za jedan sloj sistema: komponentni, integracioni, sistemski, prihvatni.

Riječi ovog poglavlja (2/3)

• V-model – model u kojem svaka faza razvoja ima svoj par na strani testiranja.
• Funkcionalno i nefunkcionalno testiranje – provjera šta sistem radi, i kakav je dok to radi (brzina, sigurnost, upotrebljivost).
• Potvrdno testiranje – ponavljanje testa koji je pao, da se potvrdi da je defekt ispravljen.
• Regresiono testiranje – provjera da izmjena nije pokvarila nešto što je ranije radilo.
• Dim-test (smoke test) – kratak test najvažnijih funkcija, da se vidi da sistem uopšte „diše”.
• Statičko testiranje – pronalaženje defekata bez pokretanja programa: čitanjem i alatima koji analiziraju kod.

Riječi ovog poglavlja (3/3)

• Recenzija – pregled dokumenta ili koda od strane drugih ljudi, radi pronalaženja defekata.

Ciljevi poglavlja

Nakon poglavlja možete:

nabrojati aktivnosti test procesa i za svaku reći šta nastaje; izvesti iz pravila test uslove i test slučajeve i povezati ih sljedivošću; razlikovati komponentno, integraciono, sistemsko i prihvatno testiranje po cilju, osnovi, okruženju i izvršiocu; objasniti V-model i testiranje u agilnom timu; razlikovati funkcionalno i nefunkcionalno, potvrdno i regresiono testiranje i dim-test; objasniti statičko testiranje i četiri vrste recenzija; provesti recenziju zahtjeva DeliveryApp i zapisati nejasnoće; pokazati da Python zaokružuje 214,5 centi na 214 i objasniti zašto je to defekt u zahtjevu, a ne nužno u kodu.

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

2.1 Šest aktivnosti testiranja

Testiranje nije jedna radnja („pokreni program i vidi”), nego niz aktivnosti. ISTQB ih opisuje ovako, a mi ih pratimo na pravilu PP-4 DeliveryApp (od 30,00 € dostava je besplatna):

2.1 Šest aktivnosti testiranja

2.1 Šest aktivnosti testiranja

Aktivnosti se ne moraju raditi strogo jedna za drugom. U agilnom timu (2.6) one se ponavljaju u svakom sprintu, za svaku korisničku priču, a neke se preklapaju. Ali svaka se mora desiti. Najčešće se preskače analiza: tester odmah piše test slučajeve, i onda pokrije ono što mu prvo padne na pamet, a ne ono što je važno.

Sve što testiranje proizvede (plan, uslovi, slučajevi, podaci, skripte, izvještaji) zove se testni materijal (testware). Čuva se kao i kod: u Gitu, s verzijama.

Ukratko – 2.1 Šest aktivnosti testiranja

• Test proces ima aktivnosti: planiranje, praćenje i kontrola, analiza, dizajn, implementacija, izvršavanje i završetak.
• Analiza odgovara na pitanje šta provjeriti, a dizajn kako.
• U agilnom timu aktivnosti se ponavljaju za svaku priču, ali se nijedna ne preskače.
• Testni materijal se čuva kao kod, u Gitu.

2.2 Test baza, test uslov, test slučaj

Tri pojma vode od pravila do testa:

1. Test baza je ono iz čega izvodimo testove: pravila PP-1 do PP-6, korisničke priče s kriterijima prihvatanja, modeli (dijagram stanja narudžbe), API ugovor, pa i sam kod.
2. Test uslov je šta treba provjeriti, rečeno opšte. Iz PP-4: „dostava je besplatna za artikle od 30,00 € i više”; „dostava se plaća ispod 30,00 €”; „besplatna dostava gleda iznos prije popusta” (iz PP-5).
3. Test slučaj je konkretan ulaz, preduslovi, koraci i očekivani rezultat za jedan uslov.

2.2 Test baza, test uslov, test slučaj

Posljednji red je zanimljiv. Poslije popusta artikli koštaju 28,80 €, ispod 30,00 €. Da je pravilo glasilo „gleda iznos poslije popusta”, dostava bi se plaćala. PP-5 kaže „prije popusta”, pa je dostava besplatna. Bez ovog test uslova, takav detalj lako promakne i programeru i testeru.

Jedan test uslov obično ima više test slučajeva (granica i vrijednost daleko od granice), a jedan test slučaj ponekad pokriva više uslova.

Ukratko – 2.2 Test baza, test uslov, test slučaj

• Test baza su dokumenti iz kojih izvodimo testove; test uslov kaže šta provjeriti; test slučaj daje konkretan ulaz i očekivani rezultat.
• Iz PP-4 i PP-5 nastaju uslovi o besplatnoj dostavi, plaćenoj dostavi i iznosu prije popusta.
• N-1002 sa STUDENT10 ima besplatnu dostavu i ukupno 28,80 €, jer se gleda iznos prije popusta.

2.3 Sljedivost

Sljedivost znači da se za svaki test zna koje pravilo provjerava, i za svako pravilo koji ga testovi provjeravaju. Pravi se kao tabela, matrica sljedivosti:

2.3 Sljedivost

Sljedivost odgovara na tri pitanja koja tester stalno dobija:

1. „Je li ovo pravilo testirano?” Red u matrici, i odgovor u sekundi.
2. „Šta treba ponovo testirati ako se pravilo promijeni?” Ako udruženje promijeni PP-2 (dostava poskupi na 2,50 €), matrica pokazuje tačno tri test slučaja koja se mijenjaju.
3. „Koliko smo gotovi?” Broj pravila s testovima koji prolaze, prema ukupnom broju pravila.

Ukratko – 2.3 Sljedivost

• Sljedivost povezuje svako pravilo s testovima koji ga provjeravaju, i obrnuto.
• Matrica sljedivosti odgovara je li pravilo testirano, šta ponoviti kad se pravilo promijeni i koliko smo gotovi.
• Promjena PP-2 u matrici odmah pokazuje koja tri test slučaja treba izmijeniti.

Provjeri se

1. Koja aktivnost odgovara na pitanje „šta provjeriti”? Analiza.
2. Koliko je ukupno za N-1002 sa kodom STUDENT10? 28,80 €: artikli 32,00 €, popust 3,20 €, dostava besplatna jer se gleda iznos prije popusta.
3. Čemu služi matrica sljedivosti? Da se za svako pravilo vidi koji ga testovi provjeravaju, i obrnuto.

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

2.4 Četiri nivoa

Sistem se testira na više nivoa, od najmanjeg dijela do cijelog sistema u rukama korisnika. Svaki nivo ima svoj cilj, osnovu, okruženje i izvršioca:

2.4 Četiri nivoa

Na integracionom nivou razlikuju se dvije vrste: integracija komponenti (dijelovi našeg sistema: API i baza) i integracija sistema (naš sistem i tuđi: DeliveryApp i sistem plaćanja, servis mapa).

Prihvatno testiranje ima nekoliko oblika: korisničko (UAT, user acceptance testing: rade li krajnji korisnici svoj posao?), operativno (mogu li ljudi koji održavaju sistem napraviti kopiju, vratiti je, pratiti sistem?), ugovorno i regulatorno (ispunjava li ugovor i zakon, npr. o zaštiti podataka) i alfa i beta testiranje (alfa: korisnici probaju u našem okruženju; beta: odabrani korisnici koriste sistem kod sebe prije zvaničnog početka).

2.4 Četiri nivoa

Priča s Heathrowa je udžbenički primjer šta se desi kad su niži nivoi dobro pokriveni, a sistemsko i operativno prihvatno testiranje nisu urađeni u stvarnim uslovima: s pravim brojem kofera, s radnicima koji prvi put rade u zgradi, sa svim neočekivanim situacijama jednog jutra.

Slika iz života: gradnja automobila. Komponentno testiranje provjerava kočnicu na stolu. Integraciono provjerava kočnicu spojenu s papučicom i točkom. Sistemsko provjerava cijeli auto na poligonu. Prihvatno je kad kupac proba auto u svom gradu i kaže „to je to”.

Ukratko – 2.4 Četiri nivoa

• Nivoi su komponentno, integraciono, sistemsko i prihvatno testiranje, od jedne funkcije do korisnika.
• Integracija može biti komponenti (naši dijelovi) ili sistema (naš i tuđi sistem).
• Prihvatno testiranje je korisničko, operativno, ugovorno i regulatorno, te alfa i beta.
• Heathrow 2008. pokazuje cijenu slabog sistemskog i operativnog testiranja u stvarnim uslovima.

2.5 V-model

V-model crta razvoj i testiranje kao slovo V. Lijeva strana se spušta od opšteg ka detaljnom (zahtjevi korisnika, zahtjevi sistema, arhitektura, detaljan dizajn, kod), a desna se penje od detaljnog ka opštem, s testovima koji provjeravaju svaku lijevu fazu:

2.5 V-model

Najvažnija ideja V-modela nije oblik slova, nego to da se test planira i dizajnira u istom trenutku kad nastaje ono što provjerava. Kad analitičar napiše PP-4, tester odmah piše TS-4.1a i TS-4.2a. Ako pri tome pita „a šta je s tačno 30,00 €?”, nejasnoća se ispravlja dok je to samo rečenica. Ovo je princip 3 iz poglavlja 1 (rano testiranje), nacrtan.

Ukratko – 2.5 V-model

• V-model povezuje svaku fazu razvoja s nivoom testiranja koji je provjerava.
• Zahtjevima korisnika odgovara prihvatno, zahtjevima sistema sistemsko, arhitekturi integraciono, a kodu komponentno testiranje.
• Test se dizajnira kad nastaje ono što provjerava, pa se nejasnoće otkriju rano.

2.6 Testiranje u agilnom timu

U agilnom timu (Scrum, poglavlje 2 udžbenika Projektovanje informacionih sistema) sistem se pravi u kratkim sprintovima od dvije sedmice, a svaki sprint mora dati inkrement koji radi. Testiranje se zato ne ostavlja „za kraj projekta”, nego se radi u svakom sprintu, za svaku priču:

• tester učestvuje u pisanju kriterija prihvatanja priče, prije programiranja (tri amigosa: vlasnik proizvoda, programer i tester zajedno pregledaju priču);
• programer piše jedinične testove uz kod;
• tester piše i automatizuje testove višeg nivoa i istražuje (poglavlje 3);
• priča nije gotova dok ne prođe testove iz Definicije gotovog;
• automatski testovi se pokreću pri svakoj izmjeni (CI, poglavlje 14), kao zaštita od regresije.

Ovaj pristup se zove i pomjeranje ulijevo (shift left): na vremenskoj liniji projekta testiranje se pomjera s kraja prema početku. Postoji i pomjeranje udesno (shift right): testiranje i praćenje sistema i poslije isporuke, u radu, kroz nadzor i postepenu isporuku (CrowdStrike, poglavlje 1).

2.6 Testiranje u agilnom timu

Ni u agilnom timu nivoi ne nestaju. Komponentni, integracioni, sistemski i prihvatni testovi postoje i dalje, samo se rade u malim komadima, stalno.

Ukratko – 2.6 Testiranje u agilnom timu

• U agilnom timu testira se u svakom sprintu, za svaku priču, od kriterija prihvatanja do automatskih testova.
• Pomjeranje ulijevo znači testirati ranije, a pomjeranje udesno pratiti i testirati i poslije isporuke.
• Nivoi testiranja ostaju, samo se rade u malim komadima.

Provjeri se

1. Na kojem nivou je test „API upisuje narudžbu u bazu”? Integraciono (integracija komponenti).
2. Šta je beta testiranje? Odabrani korisnici koriste sistem kod sebe prije zvaničnog početka.
3. Šta znači pomjeranje ulijevo? Testiranje počinje ranije, već pri pisanju zahtjeva.

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

2.7 Vrste testova

Nivo kaže gdje testiramo. Vrsta kaže šta testiramo:

2.7 Vrste testova

2.7 Vrste testova

Razlika između potvrdnog i regresionog testiranja važna je i često se brka. Potvrdno testiranje provjerava isto mjesto: test koji je pao sada prolazi. Regresiono provjerava sva ostala mjesta: da popravka česme nije poplavila kupatilo. Programer koji ispravi > u >= u PP-4 može slučajno promijeniti i nešto drugo; regresioni testovi to uhvate. Zato se regresioni testovi skoro uvijek automatizuju i pokreću pri svakoj izmjeni (poglavlje 4).

Dim-test (smoke test) je kratak skup od nekoliko testova najvažnijih funkcija, koji se pokrene odmah poslije isporuke nove verzije. Ime dolazi iz elektronike: kad se novi uređaj prvi put uključi, prvo se gleda da li se dimi. Da je Knight Capital imao dim-test koji provjerava da li svih osam servera radi istu verziju, priča iz poglavlja 1 bi bila kraća.

Ukratko – 2.7 Vrste testova

• Vrste testova su funkcionalno i nefunkcionalno, bijela i crna kutija, potvrdno i regresiono testiranje i dim-test.
• Potvrdno testiranje provjerava da je defekt ispravljen, a regresiono da izmjena nije pokvarila ništa drugo.
• Dim-test brzo provjerava najvažnije funkcije odmah poslije isporuke.

2.8 Statičko testiranje

Do sada smo testirali pokretanjem programa: to je dinamičko testiranje. Ali mnogo defekata može se naći bez pokretanja, čitanjem dokumenata i koda ili alatima koji kod analiziraju. To je statičko testiranje, i ono je najjeftinije, jer nalazi defekte najranije, često prije nego što kod uopšte postoji.

Statičko testiranje nalazi stvari koje dinamičko teško nalazi:

• nejasnoće i protivrječnosti u zahtjevima (šta je s tačno 3 km? kako se zaokružuje popust?);
• nedostajuće zahtjeve (šta ako restoran ne odgovori?);
• odstupanja od standarda u kodu (nazivi, struktura);
• mrtav kod i nekorištene varijable (Knight Capital!);
• sigurnosne slabosti u kodu (lozinka zapisana u kodu, SQL zalijepljen iz unosa).

2.8 Statičko testiranje

Primjer iz DeliveryApp pokazuje snagu statičkog testiranja. PP-5 kaže da STUDENT10 daje 10 % popusta. Recenzent pita: 10 % od 21,45 € je 2,145 €; da li je popust 2,14 € ili 2,15 €? U pravilu to ne piše. A kod DeliveryApp koristi Pythonovu funkciju round, koja zaokružuje „na parno” (banker's rounding): broj tačno na pola zaokruži prema parnom broju. Zato je popust(2145, "STUDENT10") jednako 214 centi (2,14 €), a popust(2155, "STUDENT10") jednako 216 centi (2,16 €). Većina ljudi bi u školi naučila da se 214,5 zaokružuje na 215.

Je li to defekt u kodu? Ne nužno. To je defekt u zahtjevu: pravilo ne kaže kako se zaokružuje, pa programer nije imao po čemu da odluči. Kupac koji ručno izračuna 2,15 € i vidi 2,14 € mogao bi pomisliti da ga aplikacija vara za cent. Statičko testiranje je ovo našlo čitanjem, a ispravka je jedna rečenica u PP-5 („popust se zaokružuje na cijeli cent, pola centa naviše”) i jedan red koda.

2.8 Statičko testiranje

Ukratko – 2.8 Statičko testiranje

• Statičko testiranje nalazi defekte bez pokretanja programa: čitanjem dokumenata i koda i alatima za analizu.
• Nalazi nejasnoće u zahtjevima, nedostajuće zahtjeve, mrtav kod i sigurnosne slabosti.
• Python round zaokružuje na parno: popust na 21,45 € je 2,14 €, a na 21,55 € 2,16 €.
• To je defekt u zahtjevu PP-5, koji ne kaže kako se zaokružuje, pronađen čitanjem.

2.9 Recenzije

Recenzija je pregled dokumenta ili koda od strane drugih ljudi, radi pronalaženja defekata i poboljšanja. Recenzije se razlikuju po formalnosti:

2.9 Recenzije

Bez obzira na vrstu, dobra recenzija ima nekoliko pravila:

2.9 Recenzije

1. Jasan cilj („nađi nejasnoće u PP-1 do PP-6”), a ne „pogledaj malo”.
2. Lista za pregled: pitanja koja se postavljaju svakom pravilu (je li jasno, provjerljivo, potpuno, bez protivrječnosti; šta je na granicama; kako se zaokružuje; šta je s praznim i negativnim vrijednostima).
3. Priprema: učesnici čitaju unaprijed, sami.
4. Kritikuje se dokument, ne autor: „PP-5 ne kaže kako se zaokružuje”, a ne „ti nisi napisao kako se zaokružuje”.
5. Zapis: svaki nalaz se zapiše s mjestom, opisom i ozbiljnošću, i prati se do ispravke.

Lista za pregled pravila DeliveryApp, koju koristimo na praktičnoj nastavi:

2.9 Recenzije

Ukratko – 2.9 Recenzije

• Recenzija je pregled dokumenta ili koda od drugih ljudi; vrste su neformalna, prolaz, tehnička recenzija i inspekcija.
• Dobra recenzija ima jasan cilj, listu za pregled, pripremu, kritiku dokumenta a ne autora, i zapis nalaza.
• Lista za pravila DeliveryApp pita za granice, zaokruživanje, prazne i negativne vrijednosti, protivrječnosti, nedostatke i provjerljivost.

Provjeri se

1. Po čemu se statičko razlikuje od dinamičkog testiranja? Statičko ne pokreće program, nego čita i analizira; dinamičko pokreće program.
2. Koliki je popust na 21,45 € u kodu DeliveryApp? 214 centi (2,14 €), jer round zaokružuje na parno.
3. Koja je razlika između potvrdnog i regresionog testiranja? Potvrdno provjerava da je defekt ispravljen, a regresiono da izmjena nije pokvarila ništa drugo.

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

Praktična nastava – recenzija zahtjeva DeliveryApp

Cilj je provesti pravu recenziju pravila DeliveryApp, zapisati nalaze, potvrditi jedan nalaz u kodu i napraviti matricu sljedivosti. Radi se u grupama od četiri studenta, a rezultati idu u repozitorij deliveryapp-testovi.

Korak 1 – Priprema (20 minuta, svako sam)

1. Pročitajte pravila PP-1 do PP-6 i nefunkcionalne zahtjeve NZ-1 do NZ-5 iz SADRZAJ.md (ili uvoda knjige).
2. Uz listu za pregled iz 2.9, svako za sebe zapiše najmanje pet pitanja ili nalaza. Ne razgovarajte još; cilj je da svako nađe svoje.

Korak 2 – Sastanak recenzije (40 minuta)

1. Podijelite uloge: moderator (vodi i pazi na vrijeme), autor (brani pravila kao da ih je napisao, objašnjava namjeru), zapisničar i recenzent.
2. Prođite pravila redom. Za svaki nalaz zapisničar upisuje u recenzija.md:

Vrste: nejasnoća, nedostaje, protivrječnost, neprovjerljivo. Ozbiljnost: niska, srednja, visoka.

1. Na kraju moderator pročita sve nalaze i grupa za svaki odluči: prihvaćeno (pravilo treba izmijeniti), objašnjeno (pravilo je jasno, nalaz je pogrešno čitanje) ili otvoreno pitanje za naručioca.

Korak 3 – Potvrda nalaza u kodu (20 minuta)

Provjerite nalaz o zaokruživanju u Pythonu:

>>> from deliveryapp import popust
>>> popust(2145, "STUDENT10")
214
>>> popust(2155, "STUDENT10")
216
>>> round(214.5), round(215.5), round(2.5), round(3.5)
(214, 216, 2, 4)

Zapišite u recenzija.md zašto je ovo defekt u zahtjevu i šta bi trebalo promijeniti i u pravilu i u kodu. (U Pythonu se zaokruživanje „pola naviše” za pozitivne cijele cente može napisati kao (iznos * procenat + 50) // 100; provjerite da za 2145 daje 215.)

Korak 4 – Test uslovi i matrica sljedivosti (40 minuta)

1. Za svako od pravila PP-1 do PP-6 napišite bar dva test uslova i za svaki uslov bar jedan test slučaj s konkretnim ulazom i očekivanim rezultatom, u tabeli kao u 2.2.
2. Napravite matricu sljedivosti kao u 2.3. Dodajte kolonu „Nivo” (komponentni, integracioni, sistemski, prihvatni) i za svaki test slučaj odlučite na kojem nivou bi se najprirodnije izvršio.
3. Za NZ-1 i NZ-4 napišite po jedan test uslov i recite na kojem nivou i kojom vrstom testa (funkcionalno ili nefunkcionalno) se provjeravaju.

Korak 5 – Dim-test (15 minuta)

Napišite listu od pet koraka dim-testa koji bi se pokretao odmah poslije svake nove verzije DeliveryApp. Za svaki korak navedite očekivani rezultat (npr. „N-1001 u pregledu korpe pokazuje 24,50 €”).

Korak 6 – AI kao recenzent (opcionalno)

Dajte AI asistentu pravila PP-1 do PP-6 i zatražite: „Kao recenzent zahtjeva, nađi nejasnoće, nedostatke i protivrječnosti.” Uporedite s nalazima svoje grupe. Koji nalaz je našao AI, a grupa nije, i obrnuto? Provjerite svaki AI nalaz: je li zaista nejasnoća, ili AI nije pažljivo pročitao pravilo (npr. tvrdi da nije rečeno šta je s tačno 30,00 €, iako PP-4 kaže „i više”)?

Rezultat koji se predaje: recenzija.md s najmanje deset nalaza i odlukama, potvrdom nalaza o zaokruživanju, tabelom test uslova i slučajeva, matricom sljedivosti s nivoima i dim-testom od pet koraka.

Vježba za studenta 1 – aktivnosti procesa.

Vježba za studenta 1 – aktivnosti procesa. – rješenje

Vježba za studenta 2 – nivo testiranja.

Vježba za studenta 2 – nivo testiranja. – rješenje

Vježba za studenta 3 – potvrdno ili regresiono.

Vježba za studenta 3 – potvrdno ili regresiono. – rješenje

Vježba za studenta 4 – test uslov za PP-5.

Vježba za studenta 4 – test uslov za PP-5. – rješenje

Vježba za studenta 5 – zaokruživanje.

Vježba za studenta 5 – zaokruživanje. – rješenje

Sažetak u pet rečenica

1. Heathrow 2008. pokazuje da dijelovi mogu raditi, a sistem ne, ako se ne testira sve zajedno u stvarnim uslovima.
2. Test proces ima planiranje, praćenje i kontrolu, analizu, dizajn, implementaciju, izvršavanje i završetak, a iz test baze nastaju test uslovi i test slučajevi povezani matricom sljedivosti.
3. Nivoi testiranja su komponentni, integracioni, sistemski i prihvatni, a V-model svakoj fazi razvoja daje par na strani testiranja koji se dizajnira u isto vrijeme.
4. Vrste testova su funkcionalni i nefunkcionalni, bijela i crna kutija, potvrdni i regresioni te dim-test, a u agilnom timu se testira u svakom sprintu.
5. Statičko testiranje nalazi defekte čitanjem, kao nejasnoću u PP-5 o zaokruživanju (popust na 21,45 € u kodu je 2,14 €), a recenzije s listom za pregled kritikuju dokument, ne autora.

Pitanja za ponavljanje

1. Šta se desilo na otvaranju Terminala 5 na Heathrowu i šta nije bilo dovoljno testirano?
2. Navedite aktivnosti test procesa i šta nastaje u svakoj.
3. Koja je razlika između test baze, test uslova i test slučaja?
4. Zašto je za N-1002 sa kodom STUDENT10 dostava besplatna?
5. Šta je matrica sljedivosti i na koja tri pitanja odgovara?
6. Navedite četiri nivoa testiranja i za svaki cilj, izvršioca i primjer.
7. Koje vrste prihvatnog testiranja postoje?
8. Šta je V-model i koja je njegova najvažnija ideja?
9. Kako se testira u agilnom timu? Šta znače pomjeranje ulijevo i udesno?
10. Koja je razlika između potvrdnog i regresionog testiranja?
11. Šta je dim-test i kako bi pomogao Knight Capitalu?
12. Šta je statičko testiranje i šta nalazi?
13. Objasnite nalaz o zaokruživanju popusta: šta vraća kod i zašto je to defekt u zahtjevu?
14. Navedite vrste recenzija i pravila dobre recenzije.