Meni

Praćenje programskih grešaka uživo, mjerni podaci ispitivanja i odjava s probe - 6. dan besplatnog QA treninga

  • Glavni
  • Praćenje Grešaka
  • Praćenje programskih grešaka uživo, mjerni podaci ispitivanja i odjava s probe - 6. dan besplatnog QA treninga

live project bug tracking

Isprobajte Naš Instrument Za Uklanjanje Problema

Ovo je završni dio našeg “ Obuka za testiranje softvera na projektu uživo ”Serija.

Bit će riječi o nedostacima, a također i o nekoliko preostalih tema koje će označiti završetak faze Test Test of STLC.

U prethodni članak , dok je izvođenje testova trajalo, naišli smo na situaciju da očekivani rezultat testnog slučaja nije bio ispunjen. Također smo tijekom istraživačkog testiranja utvrdili neko neočekivano ponašanje.

Praćenje programskih pogrešaka uživo, mjerni podaci ispitivanja i odjava s probe

Što se događa kada se susretnemo s tim odstupanjima?

Očito ih moramo zabilježiti i pratiti kako bismo bili sigurni da će se ta odstupanja riješiti i na kraju popraviti na AUT.

# 1) Ta se odstupanja nazivaju Defekti / bugovi / problemi / incidenti / pogreške / greške.

#dva) Svi sljedeći slučajevi mogu se evidentirati kao nedostaci

  • Nedostaju zahtjevi
  • Neispravni radni zahtjevi
  • Dodatni zahtjevi
  • Nedosljednosti referentnog dokumenta
  • Pitanja vezana uz okoliš
  • Prijedlozi za poboljšanje

# 3) Snimanje kvarova uglavnom se vrši u excel listovima ili pomoću softvera / alata za upravljanje nedostacima. Za informacije o tome kako riješiti nedostatke pomoću alata, pokušajte koristiti sljedeće veze:

Što ćete naučiti:

Kako učinkovito prijaviti nedostatke

Sada ćemo pokušati vidjeti kako prijaviti nedostatke na koje smo naišli u prethodnom članku u excel listu. Kao i uvijek, odabir standardnog formata ili predloška važan je.

kako pokrenuti povezani popis u javi

Sljedeći su stupci obično dio izvješća o nedostacima:

  • ID nedostatka: Za jedinstvenu identifikaciju.
  • Opis oštećenja: Ovo je poput naslova koji ukratko opisuje problem.
  • Modul / odjeljak AUT: Ovo nije obavezno, samo da bismo dodali više jasnoće kako bi se naznačilo područje AUT-a na kojem je došlo do problema.
  • Koraci za reprodukciju: Koji je točan slijed operacija koje treba izvršiti na AUT za ponovno stvaranje greške, ovdje će biti navedeni. Također, ako je bilo koji ulazni podatak specifičan za problem, treba unijeti i taj podatak.
  • Ozbiljnost: Ukazati na intenzitet problema i na kraju na utjecaj koji bi to moglo imati na funkcioniranje AUT-a. Smjernice o tome kako dodijeliti i koje vrijednosti treba dodijeliti u ovom polju mogu se naći u dokumentu plana ispitivanja. Dakle, pogledajte Dokument plana ispitivanja iz članka 3 .
  • Status: O tome će biti više riječi u članku.
  • Snimka zaslona: Snimka aplikacije koja prikazuje pogrešku kada se dogodila.

Ovo su neka od 'must-have' polja. Ovaj se predložak može proširiti (npr. Da uključi ime ispitivača koji je prijavio problem) ili ugovoriti ( Na primjer, ime modula uklonjeno) po potrebi.

Slijedom gornjih smjernica i korištenjem gornjeg predloška, ​​uzorak dnevnika / izvješća o nedostacima mogao bi izgledati ovako:

Uzorak izvješća o nedostacima za projekt OrangeHRM Live:

Izvješće o nedostacima OrangeHRM-a

=> Kliknite ovdje za preuzimanje izvještaja o nedostacima projekta uživo

Ispod je primjer izvještaja o kvarovima stvoren u alatu qTest Test Management: (Kliknite na sliku za uvećanje)

Uzorak izvješća o nedostacima

Defekti nisu dobri kad ih prijavimo i zadržimo za sebe. Morat ćemo ih rasporediti ispravnim redoslijedom kako bi dotični timovi djelovali na njih. Postupak - koga dodijeliti ili kojim redoslijedom također se može naći u dokumentu plana ispitivanja. Uglavnom je sličan (Kliknite na sliku za uvećanje)

Ciklus oštećenja:

Životni ciklus oštećenja 1

Iz gore navedenog postupka može se primijetiti da programske pogreške prolaze kroz različite ljude i da se različite odluke u procesu identificiranja ispravljaju. Za praćenje i utvrđivanje transparentnosti u kojem se točno stanju nalazi određena greška, u izvješću o grešci koristi se polje 'Status'. Čitav postupak naziva se 'životnim ciklusom grešaka'. Za više informacija o svim statusima i njihovim značenjima, pogledajte ovo Vodič za životni ciklus grešaka .

Nekoliko uputa tijekom praćenja grešaka

  • Kad smo novi u kreativnom timu / projektu / AUT, uvijek je najbolje razgovarati o problemu s kojim smo se susreli s vršnjakom kako bismo bili sigurni da je naše razumijevanje onoga što stvarno čini nedostatak točno ili ne.
  • Do pružiti sve informacije to je potrebno za reprodukciju problema. Kvar koji se vrati testnom timu sa statusom postavljenim kao 'Nema dovoljno podataka' ne odražava se pozitivno na nas. Pogledajte ovaj post - Kako riješiti sve programske pogreške bez oznake 'Nevaljana programska pogreška' .
  • Prije stvaranja novog provjerite je li pokrenut sličan problem. Problemi s „duplikatima“ su također loše vijesti za QA tim.
  • Ako postoji problem, koji se pojavljuje slučajno, a mi ne znamo točne korake / situacije u kojima možemo ponovno stvoriti problem - pokrenuti problem svejedno. Rizici da se problem postavi na “Neponovljivo / nema dovoljno podataka” - još uvijek moramo biti sigurni da smo sve moguće kvarove riješili u najboljoj mogućoj mjeri.
  • Opća praksa je da QA tim stvara svačije nedostatke u excel listu tijekom dana i konsolidira ih na kraju dana.

Kompletni životni ciklus oštećenja

Za naš projekt uživo ako bismo slijedili životni ciklus kvara za kvar 1,

kako otvoriti eps datoteku
  • Kad ga ja (tester) kreiram, njegov je status 'Novi'. Kad ga dodijelim voditelju QA tima, status je i dalje 'Novo', ali vlasnik je sada QA voditelj.
  • QA potencijalni klijent će pregledati problem i kada utvrdi da je to valjani problem, problem se dodjeljuje Dev potencijalnom kupcu. U ovoj fazi status je 'Dodijeljeno' a vlasnik je Dev lead.
  • Vodič za programere tada će dodijeliti ovaj problem programeru koji će raditi na njegovom rješavanju. Status će sada biti 'Radovi u tijeku' (ili nešto slično tom učinku), vlasnik je programer.
  • Za kvar 1, programer nije u mogućnosti reproducirati pogrešku, pa je vraća natrag QA timu i postavlja status kao 'Nije sposoban za reprodukciju'.
  • Ako bi programer mogao raditi na tome i riješiti problem, status bi se postavio na 'riješen' i izdanje bi bilo dodijeljeno natrag QA timu.
  • QA tim će ga tada podići, ponovno testirati problem i ako je riješen, postavit će status na 'Zatvoreno' . Ako problem i dalje postoji, status se postavlja na 'Ponovo otvoriti' a postupak se nastavlja.
  • Ovisno o ostalim situacijama, status se može postaviti kao 'Odgođena' , 'Nema dovoljno podataka', 'Duplikat' , 'radeći kako je predviđeno' , itd. od strane programera.
  • Ova metoda evidentiranja nedostataka, prijavljivanja i dodjeljivanja istih, upravljanje njima jedna je od glavnih aktivnosti koju su članovi QA tima provodili tijekom faze izvođenja testa. To se radi svakodnevno dok se određeni ciklus ispitivanja ne završi.
  • Nakon što završi 1. ciklus, razvojnom timu će trebati dan ili dva da objedini sve ispravke i obnovi kôd u sljedeću verziju koja će se koristiti za sljedeći ciklus.
  • Isti se postupak nastavlja i za ciklus 2. Na kraju ciklusa postoji vjerojatnost da u aplikaciji još uvijek postoje neki problemi 'otvoreni' ili neispravljeni.
  • U ovoj fazi - nastavljamo li i dalje s ciklusom 3? Ako da, kada ćemo zaustaviti testiranje?

Kriteriji izlaska za testiranje projekata OrangeHRM uživo

Tu koristimo ono što bismo nazvali „kriteriji izlaska“. To je unaprijed definirano u dokumentu Plana ispitivanja. Jednostavno je u obliku kontrolnog popisa koji će odrediti hoćemo li testiranje zaključiti nakon 2. ciklusa ili ćemo ići na još jedan ciklus. Izgleda da slijedeće kada se popunjava uzimajući u obzir neke hipotetske odgovore na sljedeća pitanja koja se tiču ​​OrangeHRM projekta:

Kriteriji za izlaz iz testa

Kada pažljivo pogledamo gornji popis, tamo se spominju mjerni podaci i odjava o kojima ranije nismo raspravljali. Razgovarajmo sada o njima.

Ispitne metrike

Ustanovili smo da se tijekom faze provođenja testa izvještaji šalju svim ostalim članovima projektnog tima kako bi se dala jasna predodžba o tome što se događa u fazi izvršenja osiguranja kvalitete . Ove su informacije važne svima kako bi se dobila potvrda o ukupnoj kvaliteti konačnog proizvoda.

Zamislite da prijavljujem da je prošlo 10 testnih slučajeva ili je izvršeno 100 testnih slučajeva - ti su brojevi samo neobrađeni podaci i ne daju baš dobru perspektivu o tome kako se stvari odvijaju.

Metrika igra vitalnu ulogu u popunjavanju ove praznine. Mjerni podaci su jednostavnim riječima, inteligentni brojevi koje ispitni tim prikuplja i održava . Na primjer, ako sam rekao da je prošlo 90% testnih slučajeva, to ima više smisla nego reći 150 položenih testnih slučajeva. Zar ne?

Postoje različite vrste metričkih podataka prikupljenih tijekom faze izvođenja testa. Koje se mjerne podatke točno treba prikupljati i održavati tijekom kojih vremenskih razdoblja - ove se informacije mogu naći u dokumentu plana ispitivanja.

Sljedeće su najčešće prikupljene metrike ispitivanja za većinu projekata:

  • Prolazni postotak testnih slučajeva
  • Gustoća defekata
  • Postotak kritičnih nedostataka
  • Defekti, ozbiljan broj

Pogledajte Izvješće o statusu priloženo uz ovaj članak kako bi vidjeli kako se koriste ove metrike.

Izvještaj o prijavi / završetku ispitivanja

Budući da moramo obavijestiti sve dionike da je ispitivanje započelo, također je dužnost QA tima obavijestiti sve da je testiranje završeno i podijeliti rezultate. Dakle, obično se šalje QA tim (obično voditelj tima / QA voditelj) e-pošte s naznakom da se QA tim odjavio na proizvodu prilažući rezultate testa i popis otvorenih / poznatih problema.

Uzorak testne e-pošte za odjavu:

Do: Klijent, premijer, razvojni tim, DB tim, BA, QA tim, tim za okoliš (i bilo tko drugi koji treba biti uključen)
E-mail: Pozdrav tim,

QA tim potpisuje se na softveru OrangeHRM verzije 3.0 nakon uspješnog završetka 2 ciklusa funkcionalnog testiranja web stranice.

Test slučajevi i njihovi rezultati izvršavanja priloženi su uz e-poštu. (Ili spomenite mjesto na kojem su prisutni. Ili ako koristite softver za upravljanje testovima, navedite detalje u vezi s istim.)

Popis poznatih problema priložen je i e-poruci. (Opet, mogu se dodati bilo koje druge reference koje imaju smisla.)

Hvala.
Vodstvo QA tima.

Prilozi: Konačno izvršno izvješće, konačno izdanje / izvještaj o nedostatku, popis poznatih problema

Nakon što QA tim pošalje e-poštu za odjavu s testa, službeno smo završili sa STLC postupkom. To ne mora nužno označiti završetak faze 'Test' SDLC-a. Još uvijek moramo završiti UAT testiranje da bi se to dogodilo. Pronaći više detalja o UAT testiranju ovdje .

Nakon završetka UAT-a, SDLC kreće u fazu postavljanja tamo gdje se aktivira i dostupan je svojim kupcima / krajnjim korisnicima.

To je to!

Ovo je naš pokušaj da našim čitateljima pružimo što više uživo poput QA projekta. Obavijestite nas o svojim komentarima i pitanjima u vezi s ovom besplatnom internetskom serijom obuke za testiranje softvera.

Preporučena literatura

^