7 principles software testing
Sedam principa testiranja softvera: Uključujući više detalja o klasteru kvara, Paretoovom principu i paradoksu pesticida.
Siguran sam da su svi svjesni ' Sedam principa testiranja softvera '.
Ovi temeljni principi testiranja pomažu ispitnim timovima da iskoriste svoje vrijeme i napore kako bi postupak testiranja bio učinkovit. U ovom ćemo članku detaljno naučiti dva principa t.j. Skupljanje defekata, Paretov princip i paradoks pesticida .
Što ćete naučiti:
- Sedam principa testiranja softvera
Sedam principa testiranja softvera
Prije detaljnog uvida u ta dva principa, hajde da ukratko shvatimo sedam principa testiranja softvera.
Istražimo !!
# 1) Ispitivanje pokazuje prisutnost nedostataka
Svaka aplikacija ili proizvod pušta se u proizvodnju nakon dovoljne količine testiranja od strane različitih timova ili prolazi kroz različite faze poput testiranja integracije sustava, testiranja prihvaćanja korisnika i beta testiranja itd.
Tako jeste li ikada vidjeli ili čuli od bilo kojeg tima za testiranje da su softver u potpunosti testirali i da u njemu nema kvara ? Umjesto toga, svaki tim za testiranje potvrđuje da softver udovoljava svim poslovnim zahtjevima i da funkcionira prema potrebama krajnjeg korisnika.
U industriji testiranja softvera nitko neće reći da postoji bez nedostatka u softveru, što je sasvim točno, jer testiranje ne može dokazati da softver ne sadrži pogreške ili nedostatke.
Međutim, cilj ispitivanja je pronaći sve više skrivenih nedostataka pomoću različitih tehnika i metoda. Testiranje može otkriti neotkrivene nedostatke, a ako se ne pronađu nedostaci, to ne znači da je softver bez nedostataka.
Primjer 1 :
Razmotrimo bankarsku aplikaciju, ta je aplikacija temeljito testirana i podvrgava se različitim fazama testiranja poput SIT-a, UAT-a itd., A trenutno u sustavu nisu utvrđene greške.
Međutim, možda postoji mogućnost da u proizvodnom okruženju stvarni kupac isproba funkcionalnost koja se rijetko koristi u bankarskom sustavu, a testeri su previdjeli tu funkcionalnost, stoga do danas nisu pronađeni nedostaci ili programeri nikada nisu dodirnuli kôd .
Primjer 2:
Na televiziji smo vidjeli nekoliko oglasa o sapunima, pastama za zube, sprejevima za pranje ruku ili dezinficijensima itd.
Razmislite o oglasu za pranje ruku koji na televiziji kaže da se 99% klica može ukloniti ako se koristi to posebno pranje ruku. To jasno dokazuje da proizvod nije 100% bez klica. Stoga u našem konceptu testiranja možemo reći da niti jedan softver nema nedostataka.
# 2) Rano testiranje
Ispitivači se trebaju uključiti u ranoj fazi životnog ciklusa razvoja softvera (SDLC). Tako se mogu identificirati nedostaci tijekom faze analize zahtjeva ili bilo koji nedostaci u dokumentaciji. Troškovi otklanjanja takvih nedostataka vrlo su manji u usporedbi s onima koji su pronađeni tijekom kasnijih faza ispitivanja.
Razmotrite donju sliku koja pokazuje kako se trošak popravljanja kvara povećava kako se testiranje kreće prema proizvodnji uživo.
[slika izvor ]
Gornja slika pokazuje da su troškovi potrebni za otklanjanje kvara utvrđenog tijekom Analize zahtjeva manji i nastavlja se povećavati kako krećemo prema fazi ispitivanja ili održavanja.
Sad je pitanje koliko bi rano trebalo započeti testiranje ?
Nakon što se zahtjevi dovrše, testeri se moraju uključiti za testiranje. Testiranje treba izvršiti na dokumentima sa zahtjevima, specifikacijama ili bilo kojoj drugoj vrsti dokumenta, tako da ako se zahtjevi pogrešno definiraju, onda se mogu odmah popraviti, a ne popravljati u fazi razvoja.
# 3) Iscrpno ispitivanje nije moguće
Tijekom stvarnog testiranja nije moguće testirati sve funkcionalnosti sa svim važećim i nevaljanim kombinacijama ulaznih podataka. Umjesto ovog pristupa, ispitivanje nekoliko kombinacija razmatra se na temelju prioriteta pomoću različitih tehnika.
Iscrpno testiranje trajat će neograničeno, a većina tih napora je neučinkovita. Također, vremenski trakovi projekta neće dopustiti testiranje tolikog broja kombinacija. Stoga se preporučuje testiranje ulaznih podataka pomoću različitih metoda poput ekvivalentne particije i analize granične vrijednosti.
Na primjer ,Ako pretpostavimo da imamo polje za unos koje prihvaća samo abecede, posebne znakove i brojeve od 0 do 1000. Zamislite koliko bi se kombinacija pojavilo za testiranje, nije moguće testirati sve kombinacije za svaku vrstu unosa.
Napori na testiranju potrebni za testiranje bit će ogromni, a također će utjecati na vremenski raspored i troškove projekta. Stoga se uvijek govori da iscrpno testiranje praktički nije moguće.
# 4) Testiranje ovisi o kontekstu
Na tržištu je dostupno nekoliko domena poput bankarstva, osiguranja, medicine, putovanja, oglašavanja itd., A svaka domena ima niz aplikacija. Također za svaku domenu, njihove aplikacije imaju različite zahtjeve, funkcije, različitu svrhu testiranja, rizik, tehnike itd.
Različite se domene testiraju različito, stoga se testiranje temelji isključivo na kontekstu domene ili aplikacije.
Na primjer ,testiranje bankarske aplikacije razlikuje se od testiranja bilo koje aplikacije za e-trgovinu ili oglašavanje. Rizik povezan sa svakom vrstom aplikacije različit je, pa nije učinkovito koristiti istu metodu, tehniku i vrstu ispitivanja za testiranje svih vrsta aplikacija.
# 5) Skupljanje nedostataka
Tijekom ispitivanja može se dogoditi da je većina pronađenih nedostataka povezana s malim brojem modula. Razlozi za to mogu biti višestruki, poput modula koji mogu biti složeni, kodiranje povezano s takvim modulima itd.
Ovo je Pareto princip testiranja softvera gdje se 80% problema nalazi u 20% modula. Kasnije ćemo u ovom članku saznati više o klasterizaciji nedostataka i Paretoovom principu.
# 6) Paradoks pesticida
Načelo Pesticide Paradox kaže da ako se isti niz testnih slučajeva izvodi iznova i iznova tijekom određenog vremenskog razdoblja, tada taj niz testova nije dovoljno sposoban za prepoznavanje novih nedostataka u sustavu.
Da bi se prevladao taj „Paradoks pesticida“, skup testnih slučajeva treba redovito pregledavati i revidirati. Ako je potrebno, može se dodati novi skup testnih slučajeva, a postojeći testni slučajevi mogu se izbrisati ako više ne mogu pronaći nedostatke u sustavu.
# 7) Odsutnost pogreške
Ako je softver u potpunosti testiran i ako prije izdavanja nisu pronađene nikakve pogreške, možemo reći da je softver 99% bez nedostataka. Ali što ako se ovaj softver testira na pogrešne zahtjeve? U takvim slučajevima čak i pronalaženje nedostataka i njihovo ispravljanje na vrijeme ne bi pomoglo jer se ispitivanje vrši na pogrešnim zahtjevima koji nisu prema potrebama krajnjeg korisnika.
Na primjer, pretpostavimo da je aplikacija povezana s web stranicama e-trgovine i zahtjevima u vezi s funkcionalnošću 'Košarica ili košarica' koja je pogrešno protumačena i testirana. Ovdje čak ni pronalazak više nedostataka ne pomaže premještanju aplikacije u sljedeću fazu ili u proizvodno okruženje.
Ovo je sedam principa softverskog testiranja.
Sada istražimo Grupiranje defekata, Paretov princip i paradoks pesticida u detalj .
Grupiranje nedostataka
Tijekom testiranja bilo kojeg softvera, testeri se uglavnom susreću sa situacijom u kojoj je većina pronađenih nedostataka povezana s nekom određenom funkcionalnošću, a ostale funkcionalnosti imat će manji broj nedostataka.
Grupiranje nedostataka znači mali broj modula koji sadrže većinu nedostataka. U osnovi, nedostaci se ne distribuiraju jednoliko po cijeloj aplikaciji, već su nedostaci koncentrirani ili centralizirani u dvije ili tri funkcionalnosti.
Ponekad je to moguće zbog složenosti aplikacije, kodiranje može biti složeno ili nezgodno, programer može pogriješiti što može utjecati samo na određenu funkcionalnost ili modul.
Grupiranje nedostataka temelji se na “ Paretov princip ”Koji je poznat i kao Pravilo 80-20 . To znači da je 80% pronađenih nedostataka posljedica 20% modula u aplikaciji. Koncept Pareto principa u početku je definirao talijanski ekonomist - Vilfrodo Pareto .
Ako testeri pogledaju 100 nedostataka, tada neće biti jasno postoji li temeljno značenje protiv tih 100 nedostataka. Ali ako je tih 100 nedostataka kategorizirano prema nekim određenim kriterijima, testerima će možda biti jasno da veliki broj nedostataka pripada samo nekoliko specifičnih modula.
Na primjer ,razmotrimo donju sliku koja je testirana za jednu od bankarskih aplikacija i pokazuje da je većina nedostataka povezana s funkcionalnošću 'Overdraft'. Ostale funkcije, kao što su Sažetak računa, Prijenos sredstava, Stalne upute itd., Imaju ograničen broj nedostataka.
[slika izvor ]
Gornja slika navodi da postoji 18 nedostataka oko funkcionalnosti prekoračenja od ukupno 32 nedostatka, što znači da se 60% nedostataka nalazi u modulu 'Prekoračenje'.
Stoga se testeri tijekom izvođenja uglavnom koncentriraju na to područje kako bi pronašli sve više nedostataka. Preporuča se da ispitivači imaju sličan fokus i na ostale module tijekom testiranja.
Kada se isti kôd ili modul testira, iznova i iznova, koristeći skup testnih slučajeva nego tijekom početnih iteracija, tada je broj kvarova velik, međutim, nakon neke iteracije, broj grešaka značajno će se smanjiti. Skupljanje oštećenja ukazuje na to da se područje podložno oštećenjima mora temeljito ispitati tijekom regresijskog ispitivanja.
Paradoks pesticida
Kada se utvrdi da jedan od modula ima više nedostataka, tada testeri ulažu dodatne napore kako bi testirali taj modul.
Nakon nekoliko iteracija testiranja, kvaliteta koda se poboljšava i broj nedostataka počinje padati jer većinu nedostataka otklanja razvojni tim, jer su programeri također oprezni prilikom kodiranja određenog modula u kojem su testeri pronašli više nedostataka.
Stoga se u jednom trenutku većina nedostataka otkrije i popravi tako da se u tom modulu ne pronađu novi nedostaci.
Međutim, ponekad se može dogoditi da, iako budete vrlo oprezni tijekom kodiranja na određenom modulu (ovdje u našem slučaju, “ Prekoračenje ”Modul), programer može zanemariti ostale module da bi ga pravilno kodirao ili bi promjene napravljene u tom modulu mogle imati negativan utjecaj na ostale funkcije kao što su Sažetak računa, Prijenos sredstava i Trajne upute.
Kada testeri koriste isti skup testnih slučajeva za izvršavanje modula u kojem je pronađena većina nedostataka (modul prekoračenja), nakon što programeri otklone te nedostatke, ti testni slučajevi nisu mnogo učinkoviti za pronalaženje novih nedostataka. Kao krajnji kraj protoka prekoračenja, modul se temeljito testira, a programeri su oprezno napisali kôd za taj modul.
Potrebno je revidirati i ažurirati ove test slučajeve. Također je dobra ideja dodati nove testove kako bi se moglo naći novih i više nedostataka u različitim područjima softvera ili aplikacije.
Preventivne metode paradoksa pesticida
Dvije su mogućnosti pomoću kojih možemo spriječiti paradoks pesticida kao što je prikazano u nastavku:
do) Napišite novi set test slučajeva koji će se fokusirati na različita područja ili module (osim ranijih modula sklonih defektima - Primjer: 'Prekoračenje računa') softvera.
b) Pripremite nove test slučajeve i dodajte postojećim test slučajevima.
U metoda A ”, Testeri mogu pronaći više nedostataka u ostalim modulima u kojima nisu bili fokusirani tijekom ranijeg testiranja ili programeri nisu bili posebno oprezni tijekom kodiranja.
U našem gornjem primjeru testeri mogu pronaći više nedostataka u modulima Sažetak računa, Prijenos sredstava ili Trajne upute pomoću novog skupa test slučajeva.
Ali može se dogoditi da testeri zanemare raniji modul ( Primjer: “Prekoračenje računa”) gdje je većina grešaka pronađena u ranijoj iteraciji, a to bi mogao predstavljati rizik jer je ovaj modul (prekoračenje) možda ubrizgan s novim nedostacima nakon kodiranja ostalih modula.
U metoda B ”, Novi testni slučajevi su pripremljeni tako da se u ostalim modulima mogu naći nove potencijalne greške.
Ovdje u našem primjeru, novostvoreni testni slučajevi moći će vam pomoći u prepoznavanju nedostataka u modulima kao što su Sažetak računa, Prijenos sredstava i Stalne upute. Međutim, testeri ne mogu zanemariti ranije module sklone defektima ( Primjer: “Overdraft”) jer su ti novi testni slučajevi spojeni sa postojećim testnim slučajevima.
Postojeći testni slučajevi bili su više usmjereni na modul “Overdraft”, a novi testni slučajevi bili su usmjereni na ostale module. Stoga se svi skupovi testnih slučajeva izvršavaju barem jednom, čak i kada se dogodi promjena koda na bilo kojem modulu. To će osigurati da se izvrši pravilna regresija i da se kvar može prepoznati zbog ove promjene koda.
Korištenjem drugog pristupa, ukupan broj testnih slučajeva značajno raste i rezultira s više napora i vremena potrebnih za izvršenje. To će očito utjecati na vremenske rokove projekta, a što je najvažnije i na proračun projekta.
Stoga da bi se prevladao ovaj problem, suvišni testovi mogu se pregledati, a zatim ukloniti. Mnogo je testnih slučajeva koji postaju beskorisni nakon dodavanja novih testnih slučajeva i modificiranja postojećih testnih slučajeva.
Potrebno je provjeriti koji testni slučajevi nisu uspjeli kako bi se identificirali nedostaci u posljednjih 5 ponavljanja (pretpostavimo 5 ponavljanja) i koji testni slučajevi nisu puno važni. Također može biti slučaj da pojedinačni protok obuhvaćen u nekoliko test slučajeva može biti pokriven u drugim testnim slučajevima od kraja do kraja, a oni test slučajevi koji imaju jedan protok mogu se ukloniti.
To će, pak, smanjiti ukupan broj testnih slučajeva.
Na primjer ,imamo 50 testnih slučajeva koji pokrivaju jedan određeni modul i vidjeli smo da od ovih 50 testnih slučajeva 20 testnih slučajeva nije uspjelo otkriti novi kvar u posljednjih nekoliko iteracija testiranja (pretpostavimo 5 iteracija). Stoga ovih 20 testnih slučajeva treba temeljito pregledati, a mi moramo provjeriti koliko su ti testni slučajevi važni i prema tome se može donijeti odluka hoće li se 20 testnih slučajeva zadržati ili ukloniti.
Prije uklanjanja bilo kojeg test slučaja, provjerite je li protok funkcionalnosti obuhvaćen tim test slučajevima pokriven drugim test slučajem. Ovaj se postupak mora pratiti u svim modulima kako bi se ukupan broj testnih slučajeva značajno smanjio. To će osigurati smanjenje ukupnog broja testnih slučajeva, ali i dalje postoji 100% pokrivenost potrebama.
To znači da svi preostali testni slučajevi pokrivaju sve poslovne zahtjeve, stoga nema kompromisa u kvaliteti.
Zaključak
Testiranje softvera važan je korak u SDLC-u jer se provjerava radi li softver prema potrebi krajnjeg korisnika ili ne.
Ispitivanjem se utvrđuje što je više moguće nedostataka. Stoga, kako bi se testiranje moglo izvršiti učinkovito i učinkovito, svi bi trebali biti svjesni i doista razumjeti sedam principa softverskog testiranja, a poznati su i kao stupovi za testiranje.
Većina testera implementirala je i iskusila ove principe tijekom stvarnog testiranja.
najbolji softver za oporavak podataka za vanjski tvrdi disk
Općenito, pojam načelo znači pravila ili zakone kojih se treba pridržavati. Dakle, svi u industriji testiranja softvera moraju slijediti ovih sedam principa, a ako netko ignorira bilo koje od ovih načela, projekt to može koštati ogromno.
Sretno čitanje !!
Preporučena literatura
- Najbolji alati za testiranje softvera 2021. [Alati za automatizaciju ispitivanja kvalitete]
- Posao za QA pomoćnika za testiranje softvera
- Tečaj za testiranje softvera: Koji bih se institut za testiranje softvera trebao pridružiti?
- Odabir testiranja softvera za vašu karijeru
- Ispitivanje softvera Posao pisca tehničkog sadržaja Posao slobodnjaka
- Što je tehnika ispitivanja na temelju nedostataka?
- Neka zanimljiva pitanja za ispitivanje softverskog testiranja
- Povratne informacije i kritike o tečaju softverskog testiranja