Proces upravljanja nedostacima u testiranju softvera (predložak izvještaja o pogreškama)

Sadržaj:

Anonim

Što je Bug?

Bug je posljedica / ishod kodiranja.

Nedostatak testiranja softvera

Kvar na testiranje softvera je varijacija ili odstupanje od strane aplikacije iz zahtjeva krajnjeg korisnika ili originalnih poslovnim zahtjevima. Softverska neispravnost je pogreška u kodiranju koja uzrokuje netočne ili neočekivane rezultate softverskog programa koji ne udovoljava stvarnim zahtjevima. Ispitivači bi mogli naići na takve nedostatke tijekom izvršavanja testnih slučajeva.

Ova dva pojma imaju vrlo tanku granicu razlike. U industriji su obje greške koje treba popraviti, pa ih međusobno koriste neki od ispitnih timova.

Kada testeri izvrše testne slučajeve, mogli bi naići na takve rezultate ispitivanja koji su u suprotnosti s očekivanim rezultatima. Ova varijacija rezultata ispitivanja naziva se softverskim nedostatkom. Ti se nedostaci ili varijacije nazivaju različitim nazivima u različitim organizacijama, poput problema, problema, programskih pogrešaka ili nezgoda.

U ovom vodiču naučit ćete-

  • Izvještaj o greškama
  • Proces upravljanja nedostacima
    • Otkriće
    • Kategorizacija
    • Razlučivost
    • Verifikacija
    • Zatvaranje
    • Izvještavanje
  • Važne metrike nedostataka

Izvještaj o greškama u testiranju softvera

Izvješće o pogrešci u softver testiranje je detaljan dokument o bugova pronađenih u softverskoj aplikaciji. Izvješće o programskim pogreškama sadrži svaki detalj o programskim pogreškama, kao što je opis, datum pronalaska programske pogreške, ime testera koji ga je pronašao, ime programera koji ga je popravio itd. Izvješće o programskim pogreškama pomaže identificirati slične programske pogreške u budućnosti kako bi ih se moglo izbjeći.

Dok prijavljujete grešku programeru, vaše izvješće o pogreškama treba sadržavati sljedeće podatke

  • ID kvara - jedinstveni identifikacijski broj kvara.
  • Opis oštećenja - detaljan opis oštećenja, uključujući informacije o modulu u kojem je otkriven nedostatak.
  • Verzija - Verzija aplikacije u kojoj je pronađen nedostatak.
  • Koraci - detaljni koraci zajedno sa snimkama zaslona pomoću kojih programer može reproducirati nedostatke.
  • Povećani datum - datum podizanja kvara
  • Referenca - gdje u vama Navedite referencu na dokumente poput. zahtjevi, dizajn, arhitektura ili možda čak i snimke zaslona pogreške kako bi se pomoglo u razumijevanju nedostatka
  • Otkriveno po - imenu / ID ispitivača koji je podigao kvar
  • Status - Status kvara, više o tome kasnije
  • Ispravio - Ime / ID programera koji ga je popravio
  • Datum zatvaranja - Datum zatvaranja kvara
  • Ozbiljnost koja opisuje utjecaj nedostatka na aplikaciju
  • Prioritet koji se odnosi na hitnost otklanjanja kvara. Prioritet ozbiljnosti mogao bi biti visok / srednji / nizak na temelju hitnosti udara pri kojem bi nedostatak trebao biti otklonjen

Kliknite ovdje ako videozapis nije dostupan

Resursi

Preuzmite uzorak predloška za izvještavanje o nedostacima

Smatrajte sljedeće kao Test Manager

Vaš je tim pronašao bugove tijekom testiranja projekta Guru99 Banking.

Nakon tjedan dana programer odgovara -

Sljedeći tjedan tester odgovara

Kao i u gornjem slučaju, ako se komunikacija s nedostatkom vrši usmeno, stvari se vrlo kompliciraju. Za kontrolu i učinkovito upravljanje bugovima potreban vam je životni ciklus kvara.

Što je postupak upravljanja nedostacima?

Upravljanje nedostacima sustavni je postupak za identificiranje i ispravljanje pogrešaka. Ciklus upravljanja nedostacima sadrži sljedeće faze 1) Otkrivanje nedostataka, 2) Kategorizacija nedostataka 3) Ispravljači nedostataka od strane programera 4) Provjera od strane testera, 5) Zatvaranje nedostataka 6) Izvješća o nedostacima na kraju projekta

Ova će vas tema voditi kako primijeniti postupak upravljanja nedostacima na web mjestu projekta Guru99 Bank. Možete slijediti korake u nastavku za upravljanje nedostacima.

Otkriće

U fazi otkrića, projektni timovi moraju otkriti kako mnoge nedostatke kao što je to moguće, prije nego što krajnji kupac može otkriti. Kaže se da je kvar otkriven i promijenjen u status prihvaćen kad ga programeri priznaju i prihvate

U gore navedenom scenariju testeri su otkrili 84 nedostatka na web mjestu Guru99.

Pogledajmo sljedeći scenarij; vaš je ispitni tim otkrio neke probleme na web mjestu banke Guru99. Smatraju ih nedostacima i prijavljeni razvojnom timu, ali postoji sukob -

U tom slučaju, što ćete učiniti kao voditelj ispitivanja?
A) Dogovorite se s testnim timom da je to nedostatak
B) Voditelj ispitivanja preuzima ulogu suca da odluči je li problem nedostatak ili ne
C) Dogovorite se s razvojnim timom koji nije nedostatak. Ispravi InCorrect

U tom slučaju, za rješavanje sukoba treba primijeniti postupak rješavanja, vi preuzimate ulogu suca koji odlučuje je li problem web stranice kvar ili ne.

Kategorizacija

Kategorizacija oštećenja pomaže programerima da daju prednost svojim zadacima. To znači da ovakav prioritet pomaže programerima da prvo otklone one nedostatke koji su izuzetno bitni.

Defekte obično kategorizira voditelj ispitivanja -

Napravimo malu vježbu kao što slijedi Povuci i spusti prioritet defekta u nastavku

  • Kritično
  • Visoko
  • Srednji
  • Niska
1) Izvedba web mjesta je prespora

2) Funkcija prijave na web mjestu ne radi ispravno

3) GUI web stranice ne prikazuje se ispravno na mobilnim uređajima

4) Web stranica se nije mogla sjetiti sesije prijave korisnika

5) Neke veze ne rade

Evo preporučenih odgovora

Ne. Opis Prioritet Obrazloženje
1 Izvedba web stranice je prespora Visoko Greška u izvedbi može uzrokovati velike neugodnosti korisniku.
2 Funkcija prijave na web mjestu ne radi ispravno Kritično Prijava je jedna od glavnih funkcija bankarske web stranice ako ova značajka ne radi, ozbiljne su greške
3 GUI web stranice ne prikazuje se ispravno na mobilnim uređajima Srednji Kvar utječe na korisnika koji koristi pametni telefon za pregled web stranice.
4 Web stranica se nije mogla sjetiti sesije prijave korisnika Visoko To je ozbiljan problem jer će se korisnik moći prijaviti, ali neće moći izvršavati daljnje transakcije
5 Neke veze ne rade Niska Ovo je jednostavno rješenje za momke u razvoju, a korisnik i dalje može pristupiti web mjestu bez ovih poveznica

Rješavanje nedostataka

Rješavanje nedostataka u softverskom testiranju korak je po korak postupak uklanjanja nedostataka. Proces rješavanja nedostataka započinje dodjeljivanjem nedostataka programerima, zatim programeri planiraju uklanjanje nedostataka prema prioritetu, zatim se popravljaju nedostaci i napokon programeri šalju izvještaj o rješavanju upravitelju ispitivanja. Ovaj postupak pomaže lako otkloniti i pratiti nedostatke.

Možete slijediti sljedeće korake da biste otklonili kvar.

  • Zadatak : dodijeljen programeru ili drugom tehničaru radi popravljanja i promijenio je status u Odgovor .
  • Popravljanje rasporeda : U ovoj fazi odgovornost preuzima programer. Stvorit će raspored otklanjanja tih nedostataka, ovisno o prioritetu kvara.
  • Ispravite kvar : Dok razvojni tim otklanja nedostatke, Test Manager prati postupak otklanjanja kvara u usporedbi s gornjim rasporedom.
  • Prijavi rješenje : Zatražite izvješće o rješenju od programera kad se otklone nedostaci.

Verifikacija

Nakon što je razvojni tim otklonio i prijavio kvar, ispitni tim provjerava jesu li kvarovi stvarno riješeni.

Na primjer, u gore navedenom scenariju, kada je razvojni tim izvijestio da je već otklonio 61 kvar, vaš bi tim ponovno testirao da provjeri jesu li ti kvarovi stvarno otklonjeni ili ne.

Zatvaranje

Nakon što se kvar riješi i provjeri, kvar se mijenja kao status zatvoren . Ako nije, poslat ćete obavijest razvojnom odjelu da ponovno provjeri kvar.

Izvještavanje o nedostacima

Izvješćivanje o nedostacima u testiranju softvera postupak je u kojem voditelji ispitivanja pripremaju i šalju izvještaj o kvaru menadžerskom timu radi povratnih informacija o procesu upravljanja nedostacima i statusu kvarova. Tada menadžerski tim provjerava izvještaj o kvaru i šalje povratne informacije ili pruža daljnju podršku ako je potrebno. Izvještavanje o nedostacima pomaže u boljoj komunikaciji, detaljnom praćenju i objašnjavanju nedostataka.

Uprava ima pravo znati status kvara. Moraju razumjeti postupak upravljanja nedostacima kako bi vas podržali u ovom projektu. Stoga im morate prijaviti trenutnu situaciju kvara da biste od njih dobili povratne informacije.

Važne metrike nedostataka

Natrag na gornji scenarij. Timovi programera i testa imaju pregled prijavljenih nedostataka. Evo rezultata te rasprave

Kako izmjeriti i procijeniti kvalitetu izvođenja testa?

To je pitanje koje svaki voditelj ispitivanja želi znati. Postoje 2 parametra koja možete smatrati sljedećim

U gornjem scenariju možete izračunati omjer odbijanja defekcije (DRR) 20/84 = 0,238 (23,8%).

Još jedan primjer, pretpostavlja se da web mjesto banke Guru99 ima ukupno 64 nedostatka, ali vaš tim za testiranje otkriva samo 44 nedostatka, tj. Propustili su 20 nedostataka. Stoga možete izračunati omjer propuštanja kvara (DLR) 20/64 = 0,312 (31,2%).

Zaključak, kvaliteta izvođenja testa ocjenjuje se pomoću sljedeća dva parametra

Što je manja vrijednost DRR i DLR, to je bolja kvaliteta izvođenja testa. Koji je opseg omjera koji je prihvatljiv ? Taj se raspon može definirati i prihvatiti kao osnova u cilju projekta ili možete uputiti mjerne podatke sličnih projekata.

U ovom projektu preporučena vrijednost prihvatljivog omjera je 5 ~ 10%. To znači da je kvaliteta izvođenja testa niska. Trebali biste pronaći protumjeru za smanjenje ovih omjera kao što su

  • Poboljšati vještine testiranja člana.
  • Provedite više vremena za izvršavanje ispitivanja, posebno za pregled rezultata izvršenja testa.