what is defect bug life cycle software testing
Úvod do chybného životného cyklu
V tomto návode budem hovoriť o životnom cykle chyby, aby ste si boli vedomí rôznych etáp poruchy, s ktorými sa musí tester vysporiadať pri práci v testovacom prostredí.
Tiež som pridal najčastejšie kladené otázky z rozhovoru o Defektnom životnom cykle. To je dôležité vedieť o rôznych stavoch defektu pre pochopenie životného cyklu defektu. Hlavným zámerom vykonania testovacej činnosti je skontrolovať, či má produkt nejaké problémy alebo chyby.
Pokiaľ ide o skutočné scenáre, chyby / chyby / chyby sa označujú ako chyby / chyby, a preto môžeme povedať, že hlavným cieľom vykonania testovania je zabezpečiť, aby bol výrobok menej náchylný na chyby (žiadne chyby nie sú nerealistickou situáciou). ).
Teraz sa vynára otázka, čo je to Vada?
Čo sa dozviete:
Čo je porucha?
Zjednodušene povedané, chyba je chyba alebo chyba v aplikácii, ktorá obmedzuje normálny tok aplikácie nezhodou očakávaného správania aplikácie so skutočným.
Porucha sa vyskytne, ak vývojár urobí chybu pri navrhovaní alebo vytváraní aplikácie a keď túto chybu zistí tester, označuje sa to ako chyba.
Tester je zodpovedný za dôkladné otestovanie aplikácie, aby sa zistilo čo najviac defektov, aby sa zabezpečilo, že sa kvalitný produkt dostane k zákazníkovi.
Pred prechodom na pracovný tok a rôznymi stavmi poruchy je dôležité pochopiť životný cyklus chyby.
Zoberme si preto viac informácií o chybnom životnom cykle.
Doteraz sme diskutovali o význame defektu a jeho vzťahu v kontexte s testovacou činnosťou. Poďme teraz k životnému cyklu defektu a pochopme pracovný tok defektu a rôzne stavy defektu.
Porucha životného cyklu podrobne
Životný cyklus chyby, tiež známy ako životný cyklus ploštice, je cyklus defektu, z ktorého prechádza rôznymi stavmi počas celého jeho života. Začína to, akonáhle tester zistí každú novú chybu, a skončí sa, keď tester túto chybu uzavrie a zabezpečí tak, že sa už nebude znova reprodukovať.
Defektný pracovný postup
Teraz je čas pochopiť skutočný pracovný tok životného cyklu chyby pomocou jednoduchého diagramu, ako je uvedené nižšie.
Poruchové štáty
# 1) Nové :Toto je prvý stav chyby v životnom cykle chyby. Ak sa zistí akákoľvek nová chyba, spadne do stavu „Nový“ a v neskorších fázach životného cyklu chyby sa s touto chybou vykonajú overenia a testy.
# 2) Priradené: V tejto fáze je vývojovému tímu pre prácu s chybou pridelená novovytvorená chyba. Toto pridelí vedúci projektu alebo manažér testovacieho tímu vývojárovi.
# 3) Otvorené: Tu vývojár spustí proces analýzy chyby a v prípade potreby pracuje na jej odstránení. Ak sa vývojár domnieva, že chyba nie je vhodná, môže sa preniesť do niektorého z nasledujúcich štyroch stavov Duplicitné, odložené, odmietnuté alebo nejde o chybu - na základe konkrétneho dôvodu.
O týchto štyroch štátoch budem diskutovať za chvíľu.
# 4) Opravené: Keď vývojár dokončí úlohu odstránenia chyby vykonaním požadovaných zmien, môže označiť stav chyby ako „Opravený“.
# 5) Čaká sa na opätovné testovanie: Po odstránení chyby vývojár pridelí chybu testerovi na opätovné testovanie chyby na jeho konci a kým tester nebude pracovať na opätovnom testovaní chyby, stav chyby zostane v stave „Čaká sa na opätovné testovanie“.
# 6) Opätovné testovanie: V tomto okamihu tester spustí úlohu pracovať na opätovnom testovaní chyby, aby overil, či je chyba opravená vývojárom presne podľa požiadaviek alebo nie.
# 7) Znova otvoriť: Ak problém naďalej pretrváva, bude znova pridelený vývojárovi na testovanie a stav chyby sa zmení na „Znovu otvoriť“.
# 8) Overené: Ak tester po pridelení vývojárovi na opätovné testovanie nezistí žiadny problém vady a má pocit, že ak bol defekt odstránený presne, bude stav defektu označený ako „Overený“.
# 9) Zatvorené: Ak chyba už neexistuje, tester zmení stav chyby na „Uzavretý“.
Niečo viac:
- Zamietnuté: Ak vada vývojárom nie je považovaná za skutočnú vadu, je označená ako „Odmietnutá“ vývojárom.
- Duplikát: Ak vývojár zistí chybu rovnako ako ktorúkoľvek inú chybu alebo ak sa koncept chyby zhoduje s akoukoľvek inou chybou, vývojár ju zmení na „Duplikovať“.
- Odložené: Ak má vývojár pocit, že chyba nemá veľmi dôležitú prioritu a v takom prípade ju možno opraviť v ďalších vydaniach, môže zmeniť stav chyby na „Odložené“.
- Nie je to chyba: Ak chyba nemá vplyv na funkčnosť aplikácie, stav chyby sa zmení na „Nie je to chyba“.
The povinné polia keď tester zaznamená každú novú chybu, sú Build version, Submit On, Product, Module, Severity, Synopsis and Description to Reproduce
Vo vyššie uvedenom zozname môžete niektoré pridať voliteľné polia ak používate manuálnu šablónu na zasielanie chýb. Tieto voliteľné polia zahŕňajú meno zákazníka, prehľadávač, operačný systém, prílohy súborov alebo snímky obrazovky.
Nasledujúce polia zostávajú buď zadané, alebo nevyplnené:
Ak máte oprávnenie pridávať polia Stav chyby, Priorita a „Priradené k“, môžete tieto polia určiť. V opačnom prípade Správca testov nastaví stav, Prioritu chyby a pridelí chybu vlastníkovi príslušného modulu.
Pozrite sa na nasledujúci cyklus chýb
Vyššie uvedený obrázok je dosť podrobný a keď vezmete do úvahy významné kroky v rámci Bug Life Cycle, získate o ňom rýchlu predstavu.
Po úspešnom prihlásení bude chyba skontrolovaná vývojovým alebo testovacím manažérom. Správca testov môže stav chyby nastaviť na Otvoriť, Môže Priradiť chybu vývojárovi alebo môže byť chyba odložená do ďalšieho vydania.
Keď bude chyba pridelená vývojárovi, môže s ním začať pracovať. Vývojár môže stav chyby nastaviť tak, že sa neopraví, nebude sa dať reprodukovať, bude treba viac informácií alebo že bude opravená.
Ak je stav chyby nastavený vývojárom na hodnotu „Potrebujete viac informácií“ alebo Opravený, QA odpovie konkrétnou akciou. Ak je chyba opravená, QA chybu overí a môže nastaviť stav chyby ako overenú zatvorenú alebo znovuotvorenú.
Pokyny na implementáciu životného cyklu chyby
Pred začatím práce s chybným životným cyklom je možné prijať niektoré dôležité pokyny.
Sú to tieto:
- Je veľmi dôležité, aby predtým, ako začnete pracovať na životnom cykle chyby, celý tím jasne pochopil rôzne stavy chyby (diskutované vyššie).
- Poruchový životný cyklus by mal byť náležite zdokumentovaný, aby sa v budúcnosti predišlo nejasnostiam.
- Zaistite, aby každý jednotlivec, ktorému bola pridelená akákoľvek úloha súvisiaca s Poruchovým životným cyklom, veľmi jasne pochopil svoju zodpovednosť za lepšie výsledky.
- Každý jednotlivec, ktorý mení stav chyby, by si mal byť tohto stavu riadne vedomý a mal by poskytnúť dostatok podrobností o stave a dôvode uvedenia tohto stavu, aby každý, kto pracuje na konkrétnej vade, pochopil dôvod takéhoto stavu. závady veľmi ľahko.
- S nástrojom na sledovanie defektov by sa malo manipulovať opatrne, aby sa zachovala konzistencia medzi defektmi, a teda aj v pracovnom toku životného cyklu chyby.
Ďalej poďme diskutovať o otázkach z pohovoru na základe životného cyklu chyby.
Dôležité časté otázky alebo otázky týkajúce sa rozhovorov o životnom cykle chyby
Otázka 1) Čo je chyba v perspektíve Testovania softvéru?
Odpoveď: Poruchou je akýkoľvek druh chyby alebo chyby v aplikácii, ktorý obmedzuje normálny tok aplikácie nesúladom očakávaného správania aplikácie so skutočným.
Otázka 2) Aký je hlavný rozdiel medzi chybou, chybou a chybou?
Odpoveď: Chyba: Ak vývojári zistia, že existuje nesúlad v skutočnom a očakávanom správaní sa aplikácie vo fáze vývoja, potom to nazývajú Chyba.
Porucha: Ak testéri zistia nesúlad v skutočnom a očakávanom správaní sa aplikácie vo fáze testovania, označia ju ako chybu.
Zlyhanie: Ak zákazníci alebo koncoví používatelia nájdu nesúlad v skutočnom a očakávanom správaní sa aplikácie vo fáze výroby, potom ju označia ako zlyhanie.
Otázka 3) Aký je stav chyby, keď sa zistí?
Odpoveď: Keď sa zistí nový nedostatok, je v stave „Nový“. Toto je počiatočný stav novo nájdenej chyby.
Otázka č. 4) Aké sú rôzne stavy chyby v životnom cykle chyby, keď je chyba schválená a opravená vývojárom?
Odpoveď: Rôzne stavy defektu, v tomto prípade, sú Nové, Priradené, Otvorené, Opravené, Čakajúce opätovné testovanie, Opakované testovanie, Overené a Uzavreté.
usertesting koľko testov za deň
Otázka č. 5) Čo sa stane, ak tester stále zistí problém s chybou, ktorú opravil vývojár?
Odpoveď: Tester môže označiť stav chyby ako „Znovu otvoriť“, ak stále zistí problém v opravenej chybe a chyba bude pridelená vývojárovi na opätovné testovanie.
Otázka č. 6) Čo je to vyrobiteľná chyba?
Odpoveď: Porucha, ktorá sa opakovane vyskytuje pri každej exekúcii a ktorej kroky je možné zachytiť pri každej exekúcii, sa potom nazýva takáto vada „produkovateľná“.
Otázka č. 7) Aký typ chyby nie je reprodukovateľná?
Odpoveď: Porucha, ktorá sa nevyskytuje opakovane pri každej exekúcii a produkuje sa iba v niektorých prípadoch a ktorej kroky ako dôkaz je potrebné zachytiť pomocou snímok obrazovky, sa potom nazýva ako „nereprodukovateľná“ vada.
Otázka č. 8) Čo je hlásenie o chybe?
Odpoveď: Správa o chybe je dokument, ktorý obsahuje hlásenie informácií o chybe alebo chybe v aplikácii, ktoré spôsobujú normálny tok aplikácie, ktorý sa odchyľuje od jej očakávaného správania.
Otázka č. 9) Aké podrobnosti sú obsiahnuté v hlásení o chybe?
Odpoveď: Správa o chybe obsahuje tieto podrobnosti:
ID chyby, Popis chyby, Názov funkcie, Názov testovacieho prípadu, Reprodukovateľná chyba alebo nie, Stav chyby, Závažnosť a Priorita chyby, Názov testera, Dátum testovania chyby, Verzia zostavy, v ktorej bola chyba nájdená .
A Vývojár, ktorému bola chyba pridelená, meno osoby, ktorá chybu napravila, Screenshoty chyby, ktorá zobrazuje priebeh krokov, Stanovenie dátumu chyby a osobu, ktorá chybu schválila.
Otázka č. 10) Kedy sa chyba zmení na „odložený“ stav v životnom cykle chyby?
Odpoveď: Ak zistená chyba nemá príliš veľký význam a tá, ktorú je možné opraviť v neskorších vydaniach, sa presunie do „odloženého“ stavu v rámci cyklu životného cyklu chyby.
Ďalšie informácie o chybe alebo chybe
- Poruchu je možné zaviesť kedykoľvek v životnom cykle vývoja softvéru.
- Skôr ako bude chyba zistená a odstránená, celkové náklady na kvalitu budú nižšie.
- Náklady na kvalitu sa minimalizujú, keď sa chyba odstráni v tej istej fáze, v ktorej sa vyskytla.
- Statické testovanie zistí poruchu, nie poruchu. Cena je minimalizovaná, pretože nejde o ladenie.
- Pri dynamickom testovaní sa prítomnosť chyby odhalí, keď spôsobí poruchu.
Štáty defektu
| S.No. | Počiatočný stav | Vrátený štát | Stav potvrdenia |
|---|---|---|---|
| 1 | Zhromaždite informácie pre osobu zodpovednú za reprodukciu chyby | Porucha je odmietnutá alebo je požiadaná o ďalšie informácie | Porucha je opravená a mala by byť otestovaná a uzavretá |
| dva | Štáty sú otvorené alebo nové | Štáty sú zamietnuté alebo objasnené. | Štáty sú vyriešené a overenie. |
Neplatné a duplicitné hlásenie o chybe
- Niekedy sa chyba vyskytne nie kvôli kódu, ale kvôli testovaciemu prostrediu alebo nedorozumeniu, takáto správa by mala byť uzavretá ako neplatná chyba.
- V prípade duplikátu správy sa jedna uchová a druhá sa uzavrie ako duplikát. Správca prijíma niektoré neplatné správy.
- Manažér testov vlastní celkovú správu a proces defektov a za správu protokolov je všeobecne zodpovedný krížovo funkčný tím nástroja pre správu defektov.
- Medzi účastníkov patria Test Manager, Developers, PM, Production Manager a ďalšie zainteresované strany, ktoré majú záujem.
- Výbor pre správu chýb by mal určiť platnosť každej chyby a určiť, kedy ju odstrániť alebo odložiť. Ak to chcete zistiť, zvážte náklady, riziká a prínosy neopravenia akejkoľvek chyby.
- Ak musí byť závada odstránená, musí sa určiť jej prednosť.
Údaje o chybe
- Meno osoby.
- Typ testovania
- Zhrnutie problému
- Podrobný popis chyby.
- Kroky na reprodukciu
- Fáza životného cyklu
- Pracovný výrobok, na ktorom bola predstavená chyba.
- Závažnosť a priorita
- Subsystém alebo komponent, v ktorom sa vyskytla chyba.
- Aktivita projektu, ku ktorej dôjde pri zavedení chyby.
- Metóda identifikácie
- Typ chyby
- Projekt a produkt, v ktorom existuje problém
- Súčasný vlastník
- Aktuálny stav správy
- Pracovný výrobok, kde sa vyskytla chyba.
- Vplyv na projekt
- Riziko, strata, príležitosť a výhody spojené s odstránením alebo neopravením chyby.
- Dátumy, keď nastanú rôzne fázy životného cyklu defektu.
- Opis riešenia problému a odporúčania na testovanie.
- Referencie
Schopnosť procesu
- Informácie o úvode, detekcii a odstránení -> Zlepšiť detekciu chýb a náklady na kvalitu.
- Úvod -> Praetorova analýza procesu, pri ktorom sa zavádza najväčší počet chýb, aby sa znížil celkový počet chýb.
- Informácie o defekte koreňa -> nájsť podčiarknuté dôvody chyby, aby sa znížil celkový počet chýb.
- Informácie o komponente defektu -> Vykonať klastrovú analýzu defektov.
Záver
Toto je všetko o chybnom životnom cykle a správe.
Dúfam, že ste určite získali nesmierne vedomosti o životnom cykle poruchy. Tento návod vám zase pomôže pri ľahkej práci s chybami v budúcnosti.
Odporúčané čítanie
- Čo je technika testovania na základe chýb?
- Čo je životný cyklus testovania softvéru (STLC)?
- Výukový program Bugzilla: Výukový program pre nástroj na správu chýb
- Vlákna Java s metódami a životným cyklom
- Testovanie softvéru je všetko o nápadoch (a o tom, ako ich generovať)
- Hĺbkové návody pre zatmenie pre začiatočníkov
- Proces správy defektov: Ako efektívne riadiť defekty
- Ukážka hlásenia chyby pre webové a produktové aplikácie