04-05 - TiKPP-Osnove Testiranja Programskog Proizvoda (4 Sati) 2 - HR

OSNOVE TESTIRANJA
PROGRAMSKOG PROIZVODA (2/2)

Prof.dr.sc. Valentina Kirinić
Sveučilište u Zagrebu, Fakultet organizacije i informatike, Varaždin
SADRŽAJ
▪ Definicija i osnovni pojmovi u testiranju
▪ Ciljevi testiranja
▪ Pozicija i uloga aktivnosti testiranja u softverskom
procesu
▪ Poveznice i razlike u odnosu na druge srodne aktivnosti
(SQM, formalna verifikacija, debuggiranje, izrada
programa)
▪ Programske greške - uzroci i posljedice
▪ Principi testiranja
ISHODI UČENJA
▪ Opisati temeljne koncepte testiranja i osiguravanja
kvalitete programskog proizvoda
▪ Usporediti vrste testiranja programskog proizvoda
POVEZNICE I
RAZLIKE U ODNOSU
NA DRUGE SRODNE
AKTIVNOSTI
POVEZNICE I RAZLIKE U ODNOSU NA DRUGE SRODNE
AKTIVNOSTI (1/11)
▪ Testiranje i upravljanje kvalitetom softvera (SQM)
▪ Vidjeti:
▪ https://www.toolsqa.com/software-testing/istqb/quality-assurance-
and-quality-control/
▪ https://www.toolsqa.com/software-testing/quality-control-and-
quality-assurance/
▪ Upravljanje kvalitetom (QM):
▪ obuhvaća sve organizacijske aktivnosti i mjere koje služe kontroli
kvalitete
▪ obično je odgovorno za definiranje politika kvalitete, ciljeva
kvalitete, planiranja kvalitete, osiguranja kvalitete i poboljšanja
kvalitete
▪ upravljanje kvalitetom je temeljna aktivnost upravljanja
▪ obavezna je u industrijama kao što su zrakoplovstvo, automobilska
industrija i zdravstvo
AKTIVNOSTI (2/11)
AKTIVNOSTI (3/11)
▪ Quality Assurance and Quality Control:
▪ oba su dijela upravljanja kvalitetom - osiguranje kvalitete kao aktivnost
prevencije nedostataka (defects) i kontrola kvalitete kao aktivnost
identifikacije nedostataka
▪ Osiguranje kvalitete (QA):
▪ je proces provjere zadovoljava li proizvod tražene specifikacije i očekivanja
klijenta
▪ osigurava da radite pravu stvar na pravi način, koristeći odgovarajuće
tehnike
▪ primarni fokus je spriječiti nedostatke u sustavu
▪ Kontrola kvalitete (QC):
▪ je aktivnost usmjerena na proizvod koja se usredotočuje na prepoznavanje
nedostataka
▪ uključuje provjeru proizvoda prema unaprijed određenom skupu zahtjeva i
potvrđivanje da proizvod ispunjava te zahtjeve
AKTIVNOSTI (4/11)
▪ Testiranje i formalna verifikacija
▪ Formalna verifikacija (NIST, n.d.): Sustavni proces koji koristi
matematičko zaključivanje i matematičke dokaze (tj., formalne
metode u matematici) kako bi se potvrdilo da sustav
zadovoljava svoja željena svojstva, ponašanje ili specifikaciju
(tj. implementacija sustava je vjeran prikaz dizajna)
▪ Formalna verifikacija (Pezzè, M., & Young, 2008):
▪ termina verifikacija u širem smislu je provjera je li program ili sustav
u skladu s nekim oblikom specifikacije; u širem smislu verifikacija
uključuje, na primjer, tehnike inspekcije i testiranje programa prema
neformalno navedenim specifikacijama
▪ izraz formalna verifikacija koristi se u znanstvenoj literaturi u puno
užem smislu za označavanje tehnika koje konstruiraju matematički
dokaz dosljednosti između nekog formalnog prikaza programa ili
dizajna i formalne specifikacije
AKTIVNOSTI (5/11)
▪ Simboličko izvršenje i tehnike formalne verifikacije
koriste se u nekoliko domena (Pezzè, M., & Young, 2008):
▪ Strogi dokazi svojstava (malih) kritičnih podsustava, kao što je
sigurnosni kernel medicinskog uređaja;
▪ Formalna provjera kritičnih svojstava (npr. sigurnosnih svojstava)
koja su posebno otporna na dinamičko testiranje;
▪ Formalna verifikacija opisa algoritama i logičkih dizajna koji su
mnogo manje složeni od njihove implementacije u
programskom kodu.
AKTIVNOSTI (6/11)
▪ Formal verification vs. testing:
▪ Testiranje samo provjerava ponašanje programa za neke ulaze, dok
se formalnom provjerom može provjeriti za sve moguće ulaze
▪ I testiranje i formalna verifikacija zahtijevaju opis očekivanog
ponašanja programa (s testnim slučajevima korištenim u testiranju i
formalnim specifikacijama korištenim u formalnoj verifikaciji)
▪ Kada se koriste zajedno, mogu pružiti temeljitiji pregled programa:
▪ Testiranje je, na primjer, učinkovito u pronalaženju jednostavnih bugova i
pogrešaka, ali ga je općenito brže i lakše izvesti
▪ Formalna verifikacija, iako je nezgrapnija za korištenje, dovoljno je moćna da
dokaže nepostojanje pogrešaka ili otkrije suptilne greške koje je lako propustiti u
testiranju ili pregledu koda
AKTIVNOSTI (7/11)
▪ Testiranje i debuggiranje
▪ Vidjeti:
▪ https://www.toolsqa.com/software-testing/istqb/testing-and-
debugging/
▪ ISTQB - Testing is not debugging:
▪ Kako bi se otklonila, greška softvera, se mora locirati - za početak,
znamo samo učinak pogreške, ali ne i njezino mjesto unutar koda
▪ Proces pronalaženja i ispravljanja pogrešaka naziva se debugging i
odgovornost je programera
▪ Debuggiranje (otklanjanje pogrešaka) često se brka s testiranjem,
iako su to dva vrlo različita zadatka
▪ Dok debuggiranje otkriva pogreške u softveru, testiranje se koristi za
otkrivanje učinka koji pogreška uzrokuje
AKTIVNOSTI (8/11)
AKTIVNOSTI (9/11)
Obilježja Testiranje Debuggiranje
Cilj Svrha testiranja je pronaći Svrha debugginga je
greške/bugove u aplikaciji. ispravljanje grešaka
pronađenih tijekom
procesa testiranja.
Izvodi Tester ili ponekad Programer radi otklanjanje
programer obavlja pogrešaka.
testiranje.
Automatizacija Testiranje može biti ručno Debuggiranje se ne može
ili automatizirano. automatizirati.
Znanje Većina testiranja ne Debuggiranje zahtijeva
programiranja zahtijeva poznavanje odgovarajuće poznavanje
izvornog koda. izvornog koda.
AKTIVNOSTI (10/11)
▪ Testiranje i izrada programa
▪ Vidjeti:
▪ Software Testing vs. Software Development: What Is The
Difference?
▪ Softversko testiranje:
▪ je faza koja se odvija nakon cijelog ciklusa razvoja softvera
▪ Izrada programa / razvoj softvera:
▪ je holistički i slojeviti proces u smislu da obuhvaća ključne faze
životnog ciklusa softverskog proizvoda – sve od dizajniranja
proizvoda i stvaranja koda, implementacije i podrške softveru
nakon isporuke
▪ cijelim procesom upravlja više stručnih timova developera,
softverskih inženjera i programera
AKTIVNOSTI (11/11)
▪ Software Testing vs. Software Development: What Is The
Difference?
Izrada programa Testiranje
Razvoj softvera je stvarni proces stvaranja softvera. Uključuje Nakon što je softver u potpunosti razvijen, spreman je za fazu
projektiranje, razvoj i implementaciju proizvoda. Ovo je faza u testiranja. Ovdje se analizira u odnosu na stvarne zahtjeve. To je
kojoj se pišu svi kodovi. također proces osmišljen za pronalaženje (po)grešaka.
Najjednostavnije rečeno, razvoj je pisanje koda za izradu Najjednostavnije rečeno, testiranje je provjera funkcionira li ovaj
softvera. kod kako se očekuje ili ne.
Razvoj softvera zahtijeva stručnost višestrukih uloga, da Višestruki timovi stručnjaka također su uključeni u proces
spomenemo samo neke – softverskih inženjera, developera, testiranja softvera - testeri softvera, voditelji testiranja, dizajneri
izdavača softvera (software publishers) i programera. testova, administratori testova i developeri automatizacije
(automation developers).
Razvoj softvera je važan jer pomaže tvrtkama da ostanu ispred Testiranje softvera ključno je jer provjerava je li isporučeni
konkurencije pomažući im u izgradnji proizvoda novog doba i proizvod u skladu sa zahtjevima. Proces čini proizvod bez grešaka
njihovom puštanju na tržište u punom sjaju. Ovi se proizvodi i poboljšava njegovu kvalitetu. To u konačnici pomaže smanjiti
mogu mijenjati i poboljšavati prema zahtjevima. troškove održavanja i poboljšati korisničko iskustvo.
PROGRAMSKE
GREŠKE - UZROCI I
POSLJEDICE
PROGRAMSKE GREŠKE - UZROCI I POSLJEDICE (1/14)
▪ ISTQB Glossary:
▪ Pogreška, kvar, neispravan rad - Error (mistake) - Ljudsko
djelovanje koje proizvodi neispravan rezultat
▪ Difference Between Error Mistake Fault Bug Failure
Defect:
▪ Pogreška je ljudska radnja koja proizvodi netočan rezultat. To je
odstupanje od stvarne i očekivane vrijednosti. Greške (mistakes)
koje napravi programer poznate su kao 'pogreške’ (errors). To se
može dogoditi zbog sljedećih razloga
▪ Nekakva zabuna u razumijevanju zahtjeva softvera
▪ Neka pogrešna procjena vrijednosti
▪ Ili/i pogrešno tumačenje bilo koje vrijednosti, itd.
▪ Predstavlja grešku koju su napravili ljudi, a greška u programu
dovodi do pogreške.
▪ ISTQB Glossary:
▪ Nedostatak, pogreška - Defect (bug, fault)- Nesavršenost ili nedostatak u proizvodu rada
kada on ne ispunjava svoje zahtjeve ili specifikacije.
▪ Difference Between Error Mistake Fault Bug Failure Defect:
▪ Nedostatak (Kvar) - Defect (Fault) - Odstupanje od zahtjeva. Softverski
nedostatak je stanje u softverskom proizvodu koje ne ispunjava zahtjeve softvera
(kao što je navedeno u specifikacijama zahtjeva) ili očekivanja krajnjeg korisnika.
Drugim riječima, nedostatak je pogreška u kodiranju ili logici koja uzrokuje
neispravan rad programa ili proizvodnju netočnog/neočekivanog rezultata. To
može biti hardver, softver, mreža, izvedba, format ili funkcionalnost.
▪ Greška (Bug) - rezultat greške kodiranja ili greške u programu koja uzrokuje da
se program ponaša na nenamjeran ili neočekivan način. To je dokaz greške u
programu. Greške proizlaze iz grešaka (mistakes) i grešaka (errors) koje su
napravili ljudi, bilo u izvornom kodu programa ili njegovom dizajnu. Obično
postoje greške u svim korisnim računalnim programima, ali dobro napisani
programi sadrže relativno malo grešaka, a te greške obično ne sprječavaju
program u obavljanju njegove zadaće.
▪ ISTQB Glossary:
▪ Zatajenje, ispad - Failure - Događaj u kojem komponenta ili
sustav ne obavlja traženu funkciju unutar navedenih ograničenja.
Defect:
▪ Zatajenje, ispad - Failure - Odstupanje softvera od njegove
namjene. To je nesposobnost sustava ili komponente da obavlja
svoje zahtijevane funkcije unutar specificiranih zahtjeva
performansi. Zatajenje se događa kada se greška izvrši.

Defect:
in using the software during the software design and build

▪ ISTQB:
▪ Ljudska pogreška uzrokuje grešku
u dijelu koda, što zatim uzrokuje
neku vrstu vidljivog kvara sustava
koji se, idealno, otkrije tijekom
testiranja
▪ Statički testovi mogu izravno
otkriti greške u izvornom kodu
▪ Kvarovi sustava također mogu biti
uzrokovani ekološkim problemima
kao što su zračenje i magnetizam
ili fizičkim zagađenjem koje
uzrokuje kvarove hardvera i
firmvera
▪ Bug Tracking Tools:

▪ softverske aplikacije koje prate i izvlače pogrešne elemente iz
programa
▪ pomažu testeru softvera u rješavanju bilo kakvih problema koji
ometaju pravilno funkcioniranje koda
▪ veliki i složeni sustavi mogu imati stotine do tisuće grešaka u sebi
▪ ako je greška manja ili ako smeta nekritičnim sustavima, postoji
zaobilazno rješenje ili se problem također može zanemariti
▪ upravo one katastrofalne narušavaju osnovne funkcionalnosti i time
zaustavljaju izlazak proizvoda
▪ moramo imati dobar sustav praćenja bugova kako bismo se nosili s
tim zastojima
▪ alati za praćenje bugova ne samo da nadziru i prijavljuju bug
tijekom razvoja, već ih i bilježe u cijelosti za lakše buduće korištenje
▪ alati za praćenje bugova ne testiraju performanse softvera
▪ Bug Tracking Tools:

▪ Učinkovit alat za praćenje bugova mora:
▪ Pronaći i dokumentirati bugove na organiziran način
▪ Osigurati podatke o očekivanjima korisnika u odnosu na stvarnost
▪ Odrediti prioritete pogrešaka na temelju njihove ozbiljnosti
▪ Pokazati status greške
▪ Pružiti korisniku platformu za prijavu grešaka
▪ Najbolji alati za praćenje bugova: Bugzilla, Jira, Bugherd, Mantis,
ReQtest, FogBugz, DebugMe
▪ Pogreške se javljaju iz različitih razloga - neki tipični (korijenski)

uzroci su:
▪ Svi ljudi griješe!
▪ Vremenski pritisak često je prisutan u softverskim projektima i redovit je
izvor pogrešaka.
▪ Složenost zadatka koji se radi, arhitektura sustava, dizajn sustava ili izvorni
kod.
▪ Nesporazumi između sudionika u projektu - često u obliku različitog
tumačenja zahtjeva ili drugih dokumenata.
▪ Nesporazumi koji se odnose na interakciju sustava putem internih i eksternih
sučelja.
▪ Veliki sustavi često imaju ogroman broj sučelja.
▪ Složenost tehnologije koja se koristi ili novih tehnologija koje su dotad bile
nepoznate sudionicima projekta a koje se uvode tijekom projekta.
▪ Sudionici projekta nemaju dovoljno iskustva ili nemaju odgovarajuću obuku.
▪ Defects, Root Cause Analysis and Effects

▪ Uobičajeni čimbenici odgovorni za greške u softveru:
▪ Neadekvatni zahtjevi: Uspjeh bilo koje softverske aplikacije ovisi o razumijevanju razvojnih
timova o zahtjevima klijenata. Nejasni zahtjevi i nerazumijevanje zahtjeva dva su glavna
čimbenika koji uzrokuju greške u softveru.
▪ Pogreške u programiranju: Programeri, kao i svaka druga osoba, mogu pogriješiti u
programiranju. Neiskusni programeri ili programeri bez odgovarajućeg znanja o domeni
mogu uvesti jednostavne pogreške tijekom kodiranja. Nedostatak jednostavnih praksi
kodiranja, jediničnih testova, otklanjanja pogrešaka neki su od uobičajenih razloga zašto se
većina problema pojavljuje u fazi razvoja.
▪ Komunikacijski jaz: nedostaci se uvode u fazi razvoja ako točni zahtjevi nisu ispravno
priopćeni razvojnim timovima. Ponekad pogrešna komunikacija između programera i testera
također može dovesti do kvarova u softveru.
▪ Vremenski pritisci: Planiranje softverskih projekata nije lak posao. Kad se približi rok i dođe
kriza, greške se događaju. Ako nema dovoljno vremena za pravilan dizajn, kodiranje i
testiranje, sasvim je očito da će nedostaci biti uvedeni i propušteni tijekom testiranja
▪ Neprikladno okruženje: Neprikladno okruženje kao što je nekompatibilnost hardvera ili
softvera dovodi do kvarova u softveru. Često se testni podaci prisutni u jednom okruženju
razlikuju od drugog okruženja. Stoga neki nedostaci ostaju neotkriveni.
▪ Defects, Root Cause Analysis and Effects

▪ Analiza temeljnog uzroka - Root Cause Analysis (RCA) - proces od 4
koraka i 4 pitanja koja treba postaviti:
▪ ŠTO? Prvi korak je identificirati ŠTO je problem.
▪ Ako nam nije jasna izjava problema, nikada nećemo moći pronaći glavni uzrok. npr. Kupci su prijavili da
ne mogu naručiti.
▪ KADA? Sljedeći korak je saznati KADA se problem pojavio.
▪ Za naš trenutačni primjer, kada su kupci pokušavali naručiti, dobili su poruku o pogrešci "Narudžbe se
ne mogu obraditi". To se dogodilo između 15.30 i 16 sati, a poruka o pogrešci dolazi kada kupci kliknu
na gumb za narudžbu.
▪ ZAŠTO? Sljedeći korak je utvrditi ZAŠTO se problem pojavio.
▪ Na temelju informacija identificiranih u ŠTO i KADA, provodi se detaljna analiza kako bi se identificirao
temeljni uzrok. Za naš trenutni primjer, temeljni uzrok bio je taj što sustavi plaćanja nisu radili između
15.30 i 16.00. Što je pak ometalo narudžbe.
▪ KAKO? Posljednji korak za analizu temeljnog uzroka je saznati KAKO možemo
osigurati da se problem više neće pojaviti.
▪ Za naš trenutni primjer, možemo osigurati da postoji mehanizam upozorenja koji može slati e-poštu
kada bilo koji od sustava ne radi. Korisnicima može pomoći prikazivanje poruke na web-mjestu da
postoje problemi s narudžbom i da tim radi na njihovom rješavanju. Osigurat će da nema utjecaja na
korisničko iskustvo, a tehnički tim dobiva pravodobna upozorenja kako bi ispravio problem.
▪ Životni ciklus
nedostatka/buga- Defect
Life Cycle (Bug Life cycle):
▪ je putovanje koje nedostatak
prolazi tijekom svog životnog
vijeka
▪ razlikuje se od organizacije do
organizacije i također od
projekta do projekta budući da
je njime upravlja proces
testiranja softvera, a također
ovisi o alatima koji se koriste
▪ Defect Life Cycle:

▪ Novi: Kada se nedostatak zabilježi i objavi prvi put. Njegovo stanje je dato
kao novo.
▪ Dodijeljen: Nakon što tester objavi bug, voditelj testera odobrava bug i
dodjeljuje ga timu developera/razvojnih programera. Mogu postojati dva
scenarija, prvo da se nedostatak može izravno dodijeliti programeru koji
posjeduje funkcionalnost kvara. Drugo, također se može dodijeliti voditelju
razvoja i nakon što ga odobri voditelj razvoja, on ili ona mogu dalje
prenijeti nedostatak razvojnom programeru.
▪ Otvoren: njegovo stanje kada razvojni programer počne analizirati i raditi
na otklanjanju nedostatka.
▪ Popravljen: Kada programer izvrši potrebne izmjene koda i potvrdi
promjene, on/ona može postaviti status pogreške kao "Popravljeno". Ovo je
također pokazatelj za voditelja razvojnog programera da su nedostaci u
statusu Fiksirano defekti koji će biti dostupni testeru za testiranje u
nadolazećoj verziji.

▪ Ponovno testiran: U ovoj fazi tester ponovno testira izmijenjeni kod koji
mu je programer dao kako bi provjerio je li nedostatak ispravljen ili ne.
Nakon što se najnovija verzija prenese u okruženje, glavni razvojni
programer premješta sve popravljene nedostatke na ponovno testiranje. To
je pokazatelj timu za testiranje da su nedostaci spremni za testiranje.
▪ Ponovno otvoren: Ako bug i dalje postoji čak i nakon što ga je programer
ispravio, tester mijenja status u "ponovno otvoren". Bug još jednom prolazi
kroz životni ciklus.
▪ Odgođen: Bug, promijenjen u odgođeno stanje znači da se očekuje da će
bug biti ispravljen u sljedećim izdanjima. Razlozi za promjenu buga u ovo
stanje imaju mnogo čimbenika. Neki od njih su prioritet pogreške možda je
nizak, nedostatak vremena za izdanje ili pogreška možda neće imati veći
učinak na softver.
▪ Odbijen: ako razvojni programer smatra da pogreška nije originalna,
programer odbacuje pogrešku. Tada se stanje buga mijenja u "odbijeno".

▪ Duplikat: Ako se bug ponavlja dvaput ili dva buga spominju isti
koncept buga, tada se status nedavnog/najnovijeg buga mijenja u
"duplikat".
▪ Zatvoren: Kad se pogreška ispravi, testira je tester. Ako tester
smatra da greška više ne postoji u softveru, tester mijenja status
greške u "zatvoreno". Ovo stanje znači da je greška ispravljena,
testirana i odobrena.
▪ Nije bug/poboljšanje: Stanje navedeno kao "Nije
bug/poboljšanje" ako nema promjena u funkcionalnosti aplikacije.
Na primjer: ako korisnik traži neku promjenu u izgledu i polju
aplikacije kao što je promjena boje nekog teksta, onda to nije
greška, već samo neka promjena u izgledu aplikacije.
PRINCIPI
TESTIRANJA
PRINCIPI TESTIRANJA (1/10)
▪ What are the Software Testing Principles?:


▪ 1. Testiranje pokazuje prisutnost nedostataka, a ne
njihovu odsutnost:
▪ Svrha testiranja softvera je otkrivanje nedostataka softvera.
Testiranje softvera može dokazati prisutnost nedostataka, ali
nikakvo testiranje ne može dokazati da softver nema
nedostataka. Čak ni više faza testiranja i nekoliko rundi testiranja
ne mogu jamčiti da je softver 100% bez grešaka. Učinkovite
tehnike testiranja smanjuju vjerojatnost preostalih neotkrivenih
nedostataka u softveru, ali, čak i ako se nedostaci ne pronađu, to
nije dokaz ispravnosti.
▪ 2. Iscrpno testiranje je nemoguće
▪ Iscrpno testiranje je proces testiranja funkcionalnosti softvera u
kojem se pokreću svi mogući ulazi i njihove kombinacije zajedno s
različitim preduvjetima.
▪ Umjesto pokušaja iscrpnog testiranja, analiza rizika i određivanje
poslovnih prioriteta trebali bi se koristiti za minimiziranje napora
testiranja što dodatno pomaže u uštedi troškova, vremena, resursa
itd. Procjena rizika pomaže u odlučivanju koliko je testiranja
dovoljno. Uzima u obzir: razinu rizika, uključujući tehničke i poslovne
rizike povezane s proizvodom i projektna ograničenja kao što su
proračun i vrijeme.
▪ Poslovni prioriteti pomažu u fokusiranju na kritična područja, a
testni napori mogu se rasporediti na temelju ovih prioriteta.

▪ 3. Rano testiranje štedi vrijeme i novac:
▪ Da bi se nedostatak otkrio rano u životnom ciklusu softvera,
mora se započeti s aktivnostima statičkih i dinamičkih testiranja
što je ranije moguće jer je mnogo jeftinije promijeniti proizvod
na početku životnog ciklusa razvoja nego u završnim fazama
projekta. Programeru je potrebno manje vremena i truda da
popravi nedostatke otkrivene u ranim fazama budući da je mali
dio modula potrebno modificirati. Nakon što je kod napisan,
programeri i testeri često pokreću niz testova kako bi mogli
identificirati i ispraviti nedostatke u softveru.
▪ 4. Nedostaci se grupiraju (cluster) zajedno:
▪ Grupiranje (clustering) nedostataka u testiranju softvera znači da mali modul
ili funkcionalnost sadrži većinu pogrešaka ili ima najviše operativnih kvarova.
Fenomen koji su primijetili mnogi ispitivači je da se nedostaci grupiraju. To
se može dogoditi zato što je jedno područje koda posebno lukavo i
komplicirano ili zato što promjena softvera i drugih proizvoda obično
uzrokuje regresijske nedostatke. Testeri koriste ove informacije kada rade
procjenu rizika za planiranje testova i usredotočit će se na te grupe/klastere.
Prema Paretovu načelu (Pravilo 80-20), "80% nedostataka dolazi iz 20%
modula, a preostalih 20% nedostataka raspoređeno je na preostalih 80%
modula". Dakle, treba naglasiti testiranje u 20% modula gdje se susrećemo s
80% grešaka.
▪ Grupa/klaster nedostataka mijenja se tijekom vremena, kako funkcionalnost
postaje stabilnija. Tim za testiranje trebao bi uvijek biti u potrazi za novim
klasterima.
▪ 5. Pazite se paradoksa pesticida (Pesticide paradox):
▪ Paradoks pesticida u testiranju softvera je proces ponavljanja istih
testnih slučajeva uvijek iznova, na kraju ti testni slučajevi više neće
pronalaziti nove nedostatke. Ako uvijek iznova koristimo iste
pesticide, oni više neće ubijati insekte. Zatim, kako bi se prevladao
ovaj paradoks pesticida, potrebno je redovito pregledavati testne
slučajeve i dodavati nove testne podatke/unose ili ih ažurirati kako
bi se pronašlo više nedostataka. Kako se klaster grešaka čisti,
moramo se usredotočiti na drugo mjesto, na sljedeći skup rizika. S
vremenom se naš fokus može promijeniti s pronalaženja pogrešaka
u kodiranju na traženje nedostataka u zahtjevima i projektnim
dokumentima, a zatim poboljšati procese kako bi se spriječili
nedostaci u proizvodu.
▪ 6. Testiranje ovisi o kontekstu
▪ To znači da testni pristup ovisi o kontekstu softvera. Na primjer,
način na koji testirate POS (Point of Sale) sustav u fizičkim
trgovinama razlikovat će se od načina na koji ćete testirati
bankomat. Slično tome, testiranje mobilne aplikacije zahtijeva
drugačiji pristup testiranju od testiranja web aplikacije za stolna
računala.
▪ Profil rizika svakog softvera se razlikuje, pa se stoga razlikuju i
tehnike testiranja i pokušaji testiranja. Softver za kontrolu leta imao
bi vrlo mali apetit za otvorene nedostatke u usporedbi s aplikacijom
za e-trgovinu. Softver za kontrolu leta ne može si dopustiti
neotkrivene nedostatke, jer se može pokazati opasnim po život, pa
bi stoga mogli biti potrebni dodatni napori testiranja.
▪ 7. Odsutnost pogrešaka je zabluda
▪ Prema prvom i drugom principu testiranja, nemoguće je provesti sve
moguće testove i pronaći sve moguće nedostatke. Nadalje, pogrešno je
uvjerenje da je pronalaženje i popravljanje velikog broja nedostataka ključ
uspjeha sustava. Na primjer, ponekad 99% softvera bez grešaka može ostati
neupotrebljivo ako se u softver ugrade pogrešni zahtjevi. Softver koji
razvijamo ne samo da mora imati minimalne nedostatke, već mora
zadovoljiti potrebe poslovanja, inače postaje neupotrebljiv.
▪ Testiranje softvera vitalni je element u životnom ciklusu razvoja softvera
(SDLC) i može dati izvrsne rezultate ako se izvede ispravno i učinkovito.
Nažalost, testiranje softvera je često manje formalno jer ne slijedimo najbolje
prakse, metodologije, principe, standarde za optimalno testiranje softvera.
Da bi se postigli ciljevi testiranja, neophodna je maksimalna implementacija
principa testiranja u stvarnom razvoju softvera. To se može postići samo ako
svi uključeni u projekt moraju biti upoznati s osnovnim principima testiranja
softvera.
▪ Predložena dobri principi (načela) testiranja (Lewis, 2017):

▪ Nužan dio testnog slučaja je definicija očekivanog izlaza ili
rezultata
▪ Programeri bi trebali izbjegavati pokušaje testiranja vlastitih
programa
▪ Organizacija koja izrađuje programe ne bi trebala testirati vlastite
programe
▪ Temeljito provjerite rezultate svakog testa
▪ Testni slučajevi moraju biti napisani za nevažeće i neočekivane,
kao i važeće i očekivane ulazne uvjete
▪ Predložena dobri principi (načela) testiranja (Lewis, 2017)

(nastavak):
▪ Ispitivanje programa da se vidi ne radi li ono što bi trebao činiti
samo je pola bitke; druga polovica provjerava radi li program
ono što ne bi trebao
▪ Izbjegavajte jednokratne testne slučajeve osim ako program nije
doista jednokratni program
▪ Nemojte planirati napor testiranja pod taktičkom pretpostavkom
da greške neće biti pronađene
▪ Vjerojatnost postojanja više grešaka u dijelu programa
proporcionalna je broju grešaka koje su već pronađene u tom
dijelu
Literature (Additional sources)
▪ Lewis, W. E. (2017). Software testing and continuous

quality improvement. CRC press.
▪ Pezzè, M., & Young, M. (2008). Software testing and
analysis: process, principles, and techniques. John Wiley
& Sons.

04-05 - TiKPP-Osnove Testiranja Programskog Proizvoda (4 Sati) 2 - HR

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

04-05 - TiKPP-Osnove Testiranja Programskog Proizvoda (4 Sati) 2 - HR

Uploaded by

Copyright:

Available Formats

OSNOVE TESTIRANJA

PROGRAMSKOG PROIZVODA (2/2)

▪ Difference Between Error Mistake Fault Bug Failure

in using the software during the software design and build

▪ Bug Tracking Tools:

▪ Bug Tracking Tools:

▪ Pogreške se javljaju iz različitih razloga - neki tipični (korijenski)

▪ Defects, Root Cause Analysis and Effects

▪ Defects, Root Cause Analysis and Effects

▪ Defect Life Cycle:

▪ Defect Life Cycle:

▪ Defect Life Cycle:

▪ What are the Software Testing Principles?:

▪ What are the Software Testing Principles?:

▪ What are the Software Testing Principles?:

▪ Predložena dobri principi (načela) testiranja (Lewis, 2017):

▪ Predložena dobri principi (načela) testiranja (Lewis, 2017)

▪ Lewis, W. E. (2017). Software testing and continuous

You might also like