Meni

Sledenje napakam v živo, meritve preizkusov in odjava iz preizkusov - 6. dan brezplačnega preverjanja kakovosti

  • Glavni
  • Sledenje Napakam
  • Sledenje napakam v živo, meritve preizkusov in odjava iz preizkusov - 6. dan brezplačnega preverjanja kakovosti

live project bug tracking

Preizkusite Naš Instrument Za Odpravo Težav

To je zaključni del našega Izobraževanje za testiranje programske opreme na projektu v živo ”Serija.

Šlo bo za napake in tudi nekaj preostalih tem, ki bodo označile zaključek faze preizkusa STLC.

V prejšnji članek , medtem ko je tekla izvedba preizkusa, smo naleteli na situacijo, ko pričakovani rezultat testnega primera ni bil izpolnjen. Prav tako smo med raziskovalnim testiranjem ugotovili nekaj nepričakovanega vedenja.

Sledenje napakam v živo, meritve preskusov in odjava iz preskusov

Kaj se zgodi, ko naletimo na ta odstopanja?

Očitno jih moramo zabeležiti in jim slediti, da zagotovimo, da bodo ta odstopanja obdelana in sčasoma odpravljena na AUT.

# 1) Ta odstopanja se imenujejo napake / napake / težave / incidenti / napake / napake.

#two) Vse naslednje primere lahko zapišemo kot napake

  • Manjkajoče zahteve
  • Nepravilno delujoče zahteve
  • Dodatne zahteve
  • Nedoslednosti referenčnega dokumenta
  • Vprašanja, povezana z okoljem
  • Predlogi za izboljšanje

# 3) Snemanje napak večinoma poteka v Excelovih listih ali s pomočjo programske opreme / orodja za upravljanje napak. Za informacije o tem, kako odpraviti napake z orodji, poskusite uporabiti naslednje povezave:

Kaj se boste naučili:

Kako učinkovito prijaviti napake

Zdaj bomo poskušali videti, kako napake, ki smo jih naleteli v prejšnjem članku, zabeležiti v excel list. Kot vedno je tudi pri nas pomembna izbira standardne oblike ali predloge.

razlika med ponovnim testiranjem in regresijskim testiranjem

Naslednji stolpci so običajno del poročila o napakah:

  • ID napake: Za enolično identifikacijo.
  • Opis napake: To je kot naslov, ki na kratko opisuje številko.
  • Modul / odsek AUT: To ni obvezno, samo za večjo jasnost, ki označuje območje AUT, kjer je prišlo do težave.
  • Koraki za reprodukcijo: Kakšno natančno je zaporedje operacij, ki jih je treba izvesti na AUT za ponovno ustvarjanje napake, je tukaj navedeno. Če so kakršni koli vhodni podatki specifični za težavo, je treba vnesti tudi informacije.
  • Resnost: Navedite intenzivnost izdaje in sčasoma vpliv, ki bi ga to lahko imelo na delovanje AUT. Smernice za dodelitev in vrednosti za dodelitev v tem polju najdete v dokumentu s testnim načrtom. Torej, glejte Dokument načrta preizkusa iz 3. člena .
  • Stanje: O njih bomo razpravljali nadalje v članku.
  • Posnetek zaslona: Posnetek aplikacije, ki prikazuje napako, ko se je zgodila.

To je nekaj 'must-have' polj. To predlogo lahko razširite (npr. Vključite ime preizkuševalca, ki je prijavil težavo) ali pogodbeno ( Na primer, ime modula odstranjeno) po potrebi.

V skladu z zgornjimi smernicami in z uporabo zgornje predloge je lahko vzorec dnevnika / poročila o napakah videti tako:

Vzorčno poročilo o napakah za projekt OrangeHRM Live:

Poročilo o napakah OrangeHRM

=> Kliknite tukaj, če želite prenesti poročilo o napakah za projekt v živo

Spodaj je vzorec poročila o napakah, ustvarjen v orodju qTest Test Management: (Kliknite na sliko za povečavo)

Vzorec poročila o napakah

Napake niso dobre, če jih evidentiramo in jih zadržimo zase. Razporediti jih bomo morali v pravilnem vrstnem redu, da bodo zadevne ekipe ukrepale po njih. Postopek - komu dodeliti ali kakšen vrstni red upoštevati, lahko najdete tudi v dokumentu načrta preskusa. Večinoma je podoben (Kliknite na sliko za povečavo)

Cikel okvar:

Življenjski cikel napak 1

Iz zgornjega postopka je mogoče opaziti, da napake gredo skozi različne ljudi in različne odločitve v postopku prepoznavanja določijo. Za sledenje in ugotavljanje preglednosti, v katerem točno stanju je določena napaka, se v poročilu o napaki uporablja polje »Stanje«. Celoten postopek se imenuje 'življenjski cikel hroščev'. Za več informacij o vseh statusih in njihovih pomenih glejte to Vadnica za življenjski cikel hroščev .

Nekaj ​​napotkov med sledenjem napakam

  • Kadar smo v kreativni ekipi / projektu / AUT šele novi, je vedno najbolje razpravljali o vprašanju, s katerim smo se srečali z vrstnikom, da se prepričamo, da je naše razumevanje, kaj v resnici naredi napako, pravilno ali ne.
  • Za navedite vse informacije to je potrebno za reprodukcijo vprašanja. Napaka, ki se vrne preizkuševalni skupini s statusom, ki je nastavljen kot »Ni dovolj informacij«, na nas ne vpliva zelo pozitivno. Oglejte si to objavo - Kako rešiti vse napake brez oznake „Neveljavna napaka“ .
  • Preden ustvarite novo, preverite, ali se je pojavila podobna težava. 'Podvojene' številke so tudi slaba novica za ekipo QA.
  • Če obstaja težava, ki se pojavi naključno in ne vemo natančnih korakov / situacij, v katerih bi jo lahko poustvarili - vseeno jo sprožite. Tveganje, da bo težava nastavljena na “Neponovljivo / premalo informacij” - še vedno se moramo prepričati, da smo vse možne napake odpravili v najboljši možni meri.
  • Splošna praksa je, da ekipa QA tekom dneva vsakomur ustvari napake v excel listu in jih ob koncu dneva utrdi.

Popoln življenjski cikel pomanjkljivosti

Za naš projekt v živo, če bi sledili življenjskemu ciklu napake za napako 1,

brezplačen preprost pretvornik youtube v mp3
  • Ko ga (preizkuševalec) ustvarim, je njegov status 'Novo'. Ko ga dodelim vodji ekipe QA, je stanje še vedno »Novo«, lastnik pa je zdaj vodja QA.
  • Kabel za preverjanje kakovosti bo pregledal težavo in ko bo ugotovil, da gre za veljavno izdajo, je težava dodeljena vodiču razvijalcev. V tej fazi je stanje 'Dodeljeno' in lastnik je Dev lead.
  • Vodja za razvijalce bo nato to težavo dodelil razvijalcu, ki bo delal na odpravi te težave. Status bo zdaj 'Delo v teku' (ali kaj podobnega temu učinku), je lastnik razvijalec.
  • Za napako 1 razvijalec ne more reproducirati napake, zato jo dodeli skupini QA in status nastavi 'Ne more se razmnoževati'.
  • Če bi razvijalec lahko delal na njem in odpravil težavo, bi bilo stanje nastavljeno na 'razrešen' in izdaja bi bila dodeljena skupini QA.
  • Ekipa QA jo bo nato prevzela, znova preizkusila težavo in če bo odpravljena, bo status nastavila na 'Zaprto' . Če težava še vedno obstaja, je stanje nastavljeno na 'Ponovno odprite' in postopek se nadaljuje.
  • Glede na druge situacije lahko status nastavite kot 'Odloženo' , »Premalo informacij«, 'Dvojnik' , 'ki delajo, kot je bilo predvideno' , itd. s strani razvijalca.
  • Ta način snemanja napak, poročanja in dodelitve, upravljanje z njimi je ena glavnih dejavnosti, ki jo člani ekipe za preverjanje kakovosti izvajajo v fazi izvajanja preizkusa. To se naredi vsak dan, dokler določen preskusni cikel ni končan.
  • Ko je cikel 1 končan, bo skupina razvijalcev potrebovala dan ali dva, da konsolidira vse popravke in znova zgradi kodo v naslednjo različico, ki bo uporabljena za naslednji cikel.
  • Enak postopek se spet nadaljuje tudi za 2. cikel. Na koncu cikla obstaja verjetnost, da v aplikaciji še vedno obstajajo nekatere težave, »odprte« ali nepopravljene.
  • Na tej stopnji - ali še vedno nadaljujemo s ciklom 3? Če je odgovor da, kdaj bomo prenehali s testiranjem?

Merila izstopa za testiranje OrangeHRM Live Project

Tu uporabljamo tisto, kar bi imenovali »Merila izstopa«. To je vnaprej določeno v dokumentu Načrt testiranja. Preprosto je v obliki kontrolnega seznama, ki bo določil, ali zaključimo testiranje po 2. ciklu ali gremo še za en cikel. Zdi se, da spodaj, ko so izpolnjeni ob upoštevanju nekaterih hipotetičnih odgovorov na naslednja vprašanja o projektu OrangeHRM:

Merila za testni izhod

Ko natančno pogledamo zgornji kontrolni seznam, so tam omenjene meritve in odjave, o katerih prej nismo razpravljali. Pogovorimo se zdaj o njih.

Preskusne meritve

Ugotovili smo, da se v fazi izvajanja preizkusov poročila pošljejo vsem ostalim članom projektne skupine, da dobijo jasno predstavo o tem kaj se dogaja v fazi izvrševanja kakovosti . Te informacije so pomembne za vsakogar, da se preveri splošna kakovost končnega izdelka.

Predstavljajte si, da poročam, da je bilo opravljenih 10 testnih primerov ali je bilo izvedenih 100 testnih primerov - te številke so zgolj surovi podatki in ne dajejo zelo dobrega pogleda na to, kako se stvari dogajajo.

Metrike igrajo ključno vlogo pri zapolnitvi te vrzeli. Meritve so v preprostih besedah, inteligentne številke, ki jih ekipa za testiranje zbira in vzdržuje . Na primer, če sem rekel, da je 90% opravljenih testnih primerov, je bolj smiselno kot reči 150 opravljenih testnih primerov. Kajne?

Med fazo izvajanja preskusa se zbirajo različne vrste metrik. Katere meritve je treba natančno zbirati in vzdrževati v določenih časovnih obdobjih - te informacije lahko najdete v dokumentu s testnim načrtom.

Za večino projektov so najpogosteje zbrane testne meritve:

  • Odstotek testnih primerov
  • Gostota napak
  • Odstotek kritičnih napak
  • Napake, resnost številka

Oglejte si Poročilo o stanju, priloženo temu članku da vidim, kako se uporabljajo te metrike.

Poročilo o testni odjavi / zaključku

Ker moramo vse zainteresirane strani obvestiti, da se je testiranje začelo, je tudi naloga QA, da vsem sporoči, da je testiranje končano, in si deli rezultate. Običajno se od ekipe za preverjanje kakovosti (običajno vodja ekipe / vodja nadzora kakovosti) pošlje e-poštno sporočilo, ki navaja, da se je ekipa za preverjanje kakovosti odjavila z izdelkom in priložila rezultate testa ter seznam odprtih / znanih težav.

E-poštni naslov za odjavo vzorca:

Za: Naročnik, PM, Dev team, DB team, BA, QA team, Environment Team (in vsi drugi, ki jih je treba vključiti)
E-naslov: Pozdravljena ekipa,

Ekipa QA se po uspešnem zaključku dveh ciklov funkcionalnega testiranja spletnega mesta odjavi s programsko opremo OrangeHRM različice 3.0.

Testni primeri in njihovi rezultati so priloženi e-pošti. (Ali omenite lokacijo, kjer so. Ali če uporabljate programsko opremo za upravljanje testov, navedite podrobnosti o isti.)

Seznam znanih težav je priložen tudi e-pošti. (Ponovno lahko dodamo kakršne koli druge smiselne reference.)

Hvala,
Vodstvo ekipe QA.

Priloge: Končno poročilo o izvedbi, končno poročilo o napaki, seznam znanih težav

Ko iz ekipe za preverjanje kakovosti pošljemo e-poštno sporočilo o odjavi, smo s postopkom STLC uradno zaključili. To ne pomeni nujno zaključka faze 'preizkusa' SDLC. Še vedno moramo končati testiranje UAT, da se to zgodi. Najti več podrobnosti o testiranju UAT tukaj .

Po končanem UAT se SDLC premakne v fazo uvajanja, kjer začne delovati in je na voljo svojim strankam / končnim uporabnikom.

To je to!

To je bilo naše prizadevanje, da našim bralcem omogočimo kar največ izkušenj s projektom QA. Prosimo, sporočite nam svoje komentarje in vprašanja o tej brezplačni spletni seriji usposabljanja za testiranje programske opreme.

Priporočeno branje

^