Izveštaj o bugu (defektu)

Transcription

1 Testiranje softvera

2 Poređenjem stvarnog i očekivanog rezultata, tester procenjuje da li se sistem ispravno ponaša. Incident (anomalija) je neočekivan događaj koji zahteva dalju istragu. Incident može biti otkaz sistema uzrokovan defektom (bugom) u sistemu. Incident može i ne mora biti zaveden u obliku izveštaja o bugu. Defekt je stvarni problem koji treba da bude rešen. Što se ranije bug otkrije i ispravi, niži su ukupni troškovi obezbeđivanja kvaliteta sistema.

3 Sistem za praćenje defekata treba da sadrži informaciju o tome u kojoj fazi razvoja softvera je defekt stvoren i u kojoj fazi je detektovan. Ako su te dve faze iste, onda to znači da defekt nije propagirao. Ako netačan zahtev promakne prilikom statičkog testiranja zahteva (requirements review) i kao takav bude implementiran od strane developera, testiran od strane testera i prijavljen tek prilikom korisničkog testiranja, sav rad na tom zahtevu je protraćeno vreme (a može dovesti i do gubitka poverenja korisnika).

4 Izveštaj o bugu (defektu) Parametri koji se beleže u izveštaju o bugu treba da obezbede dovoljno informacija tako da je izveštaj upotrebljiv. Upotrebljiv izveštaj je: Kompletan sve neophodne informacije su unete u izveštaj; Koncizan izveštaj ne sadrži suvišne informacije;

5 Tačan informacije date u izveštaju su tačne i jasno opisuju stvarne i očekivane rezultate kao i tačne korake pomoću kojih se bug može reprodukovati; Objektivan izveštaj predstavlja profesionalno napisano iznošenje činjenica.

6 Izveštaj o bugu treba da sadrži različita polja. Što su polja bolje definisana, to je lakše da se naprave izveštaji o defektu kao i da se što lakše naprave test izveštaji. Podaci u poljima treba da se validiraju kako bi se izbegle greške pri unosu i kako bi se obezbedilo efektivno izveštavanje. Izveštaji o bugovima se pišu za greške otkrivene tokom funkcionalnog i nefunkcionalnog testiranja.

7 Informacije u ovim izveštajima uvek treba da budu orijentisane ka jasnom prikazu scenarija tokom kog je defekt otkriven, uključujući i korake i podatke za reprodukovanje, kao i očekivane i stvarne rezultate. Ako je moguće u izveštaj treba uključiti logove i snimke scenarija u kom se defekt desio. Neophodno je i navesti podatke o sistemu (okruženje, operacioni sistem, verziju bilda, verziju hardvera, itd.).

8 Iako je primarni cilj kreiranja izveštaja o bugu je popravka problema, informacije u izveštaju takođe potpomažu odgovarajuću klasifikaciju, procenu rizika i ukoliko je neophodno, poboljšanje procesa testiranja.

9 Primer novog izveštaja o bugu sa najčešće korišćenim poljima

10 Klasifikacija defekata Odgovarajuća klasifikacija defekata je suština izveštavanja u procesu testiranja. Klasifikovanjem se defekti grupišu na osnovu čega se procenjuje efikasnost testiranja i razvoja softvera. Ozbiljnost defekta (severity) Prioritet

11 Ozbiljnost defekta (severity) označava do koje mreže određeni defekt ugrožava softver, odnosno njegov uticaj (impact) na sistem Postoje različite podele, najčešća se zasniva na sledećim tipovima: Critical Major Moderate Minor Cosmetic

12 Critical (showstopper) defekt koji rezultira prekidom rada kompletnog sistema, ili neke od njegovih komponenti, i izaziva značajnu korupciju podataka. Specificirana funkcionalnost je neupotrebljiva, i nije moguće alternativnom metodom postići zahtevane rezultate Ugrožena je osnovna funkcionalnost programa, neupotrebljiv je za krajnje korisnike

13 Major defekt koji rezultira prekidom rada kompletnog sistema, ili neke od njegovih komponenti, i izaziva značajnu korupciju podataka. Specificirana funkcionalnost je neupotrebljiva Postoji mogućnost da se alternativnom metodom postignu zahtevani rezultati

14 Moderate defekt ne izaziva prekid rada sistema, ali izaziva nekorektno i netačno ponašanje, odnosno ima nekompletne ili nekonzistentne rezultate Minor defekt ne izaziva prekid rada sistema, ne utiče na upotrebljivost sistema Cosmetic defekt je zapravo poboljšanje sistema u vidu promena u izgledu aplikacije (look and feel)

15 Prioritet defekata označava redosled u kojem se oni popravljaju Prioritet postavlja tester, i označava vremenski okvir u kome developer treba da popravi defekt Ukoliko je prioritet visok (high) developer mora da ga ispravi što je pre moguće Prioritet se postavlja na osnovu korisničkih zahteva iz specifikacije

16 Najčešći tipovi prioriteta: Low defekt je iritantan i treba biti popravljen, ali popravka može biti odložena dok se ne isprave ozbiljniji defekti Medium defekt treba biti popravljen u normalnom toku aktivnosti razvoja softvera. Može sačekati sledeći build (verziju) High defekt mora biti rešen što je pre moguće, jer ozbiljno utiče na upotrebljivost proizvoda. Sistem se ne može koristiti ukoliko se ispravka ne izvrši

17 Važni primeri scenarija vezanih za upotrebu ozbiljnosti i prioriteta defekta High prio & high severity greška koja ugrožava osnovnu funkcionalnost programa, i korisnici ne mogu da koriste sistem. Primer, sajt studentskih servisa, prilikom ažuriranja podataka i ocena, ne dozvoljava snimanje promene High prio & low severity slovna greška na naslovnoj strani, ili u naslovu aplikacije

18 High severity & low prio greška koja ugrožava funkcionalnost aplikacije i ne dozvoljava određenu upotrebu sistema, ali koju krajnji korisnik retko koristi (klik na link koji se ne upotrebljava često) Low prio & low severity Kozmetičke greške, ili slovne greške u okviru paragrafa, ali ne na naslovnoj strani, nazivu aplikacije

19 Uobičajena klasifikacija defekata podrazumeva: Projektna aktivnost pri kojoj je defekt primećen (inspekcija, audit, kodiranje, testiranje, itd.) Faza projekta u kom je defekt kreiran (ukoliko je to poznato) kreiranje zahteva, dizajn, detaljni dizajn, kodiranje, itd. Faza projekta u kom je defekt primećen

20 Mogući uzrok defekta greška u zahtevima, dizajnu, interfejsu, kodu, podacima, itd. Mogućnost reprodukcije (ponavljanja) desio se samo jednom, dešava se povremeno, potpuno reproducibilan, itd. Simptom pucanje aplikacije, beskonačno dugo učitavanje ekrana, greška na korisničkom interfejsu, sistemska greška, problemi u performansama, itd.

21 Kada se defekt istraži, moguća je dalja klasifikacija: Uzrok greška koja je prouzrokovala defekt, recimo, greška u procesu, u kodu, korisnička greška, greška u testiranju, problem u konfiguraciji sistema, greška u podacima, problem u dokumentaciji, itd. Izvor produkt u kom se desila greška, recimo, zahtevi, dizajn, arhitektura, dizajn baze, korisnička dokumentacija, dokumentacija vezana za testiranje, itd. Tip logički problem, računarski problem, vremenski problem, rukovođenje podacima, poboljšanja, itd.

22 Kada je defekt popravljen (ili je njegova popravka odložena ili ga nije moguće reprodukovati), još informacija za dodatnu klasifikaciju je dostupno, kao što su: Rešenje izmena u kodu, izmena u dokumentaciji, odlaganje, nije defekt, duplikat, itd; Akcija kojom je defekt ispravljen pregled zahteva, pregled koda, jedinično testiranje, priprema podataka, dokumentacija o konfiguraciji, nema izmena, itd. Defekti se često sortiraju prema ozbiljnosti (severity) i prioritetu (priority).

23 Pisanje izveštaja o testiranju Kada se izvršavanje testa završi, rezultati treba da se zabeleže, proslede zainteresovanim stranama (vođama projekata, klijentima, itd.) ili da se arhiviraju. Poznati defekti koji su prihvaćeni ili je njihova popravka odložena treba da budu navedeni u izveštaju kako bi ih korisnici imali u vidu prilikom korišćenja sistema. Izveštaj o testiranju treba kreirati nakon svakog izvršavanja određenog skupa testova i rezultati treba da budu jasno zavedeni.

24 Pisanje izveštaja o testiranju Uvodni deo izveštaja treba da sadrži sve relevantne podatke tog izvršavanja: - ime aplikacije koja se testira, - iteraciju, - informacije o softveru i hardveru, - tip uređaja, - datume testiranja, - vrstu testiranja, - podatke o okruženju, l - linkove ka skupu testova i rezultatima, - imena lica odgovornih za testiranje, itd.

25 Pisanje izveštaja o testiranju Zaključak izveštaja obično sadrži grafički prikaz rezultata i trendova javljanja defekata. Ponekad može da sadrži poređenje sa rezultatima dobijenih tokom prethodnih izvršavanja istog skupa testova što može biti korisno za određivanje uticaja izmena u kvalitetu softvera tokom određenog vremenskog perioda.

26 Pisanje izveštaja o testiranju Odeljak izveštaja sa informacijama o samom izvršavanju treba da sadrži podatke koji nisu navedeni u uvodu, ali su relevantni za to izvršavanje: - broj izvršenih testova, - broj neizvršenih testova sa obrazloženjima, - bilo kakve promene u okruženjima, - bilo kakve promene koje su mogle da utiču na izvršavanje testova, itd.

27 Pisanje izveštaja o testiranju Odeljak sa rezultatima obično sadrži kratak sažetak rezultata i/ili link ka testovima u alatu za upravljanje testiranjem. Odeljak gde su navedeni novi i aktivni defekti detektovani prilikom izvršavanja testova: - id defekta, - naslov, - stanje defekta - reproducibilnost, - ozbiljnost, - verovatnoća pojavljivanja,...

28 Pisanje izveštaja o testiranju Zaključak sadrži mišljenje testera/test menadžera o kvalitetu softvera, doneto na osnovu ukupnih test rezultata i uticaja pronađenih defekata na ponašanje softvera. Ponekad izveštaj može da sadrži informacije o tome kada je zakazano sledeće izvršavanje testova. Izveštaj se šalje svim zainteresovanim stranama kako bi bila omogućena transparentnost procesa i kako bi bilo omogućeno planiranje narednih akcija. Izveštaj o testiranju je stoga jedan od najvažnijih projektnih dokumenata.

29 Pisanje izveštaja o testiranju Primer naslovne strane izveštaja o testiranju

30 Pisanje izveštaja o testiranju Primer uvoda, informacija o izvršavanju i rezultata

31 Pisanje izveštaja o testiranju Lista novih, aktivnih i poznatih defekata, zaključak

32 Pisanje izveštaja o testiranju Izgled mogućeg obrasca izveštaja za regresiono testiranje