Menu

Živé sledovanie chýb projektu, testovacie metriky a odhlásenie z testu - 6. deň školení QA zdarma

  • Hlavná
  • Sledovanie Chyby
  • Živé sledovanie chýb projektu, testovacie metriky a odhlásenie z testu - 6. deň školení QA zdarma

live project bug tracking

Vyskúšajte Náš Nástroj Na Odstránenie Problémov

Toto je záverečná časť nášho „ Výcvik testovania softvéru na živom projekte ”Séria.

Bude to o chybách a tiež o niekoľkých zostávajúcich témach, ktoré označia zavŕšenie fázy vykonávania testu STLC.

V predchádzajúci článok , zatiaľ čo prebiehalo vykonávanie testu, narazili sme na situáciu, keď nebol dosiahnutý očakávaný výsledok testovacieho prípadu. Počas prieskumného testovania sme tiež identifikovali neočakávané správanie.

Živé sledovanie chýb projektu, testovacie metriky a testovacie odhlásenie

Čo sa stane, keď narazíme na tieto odchýlky?

Očividne ich musíme zaznamenať a sledovať, aby sme sa uistili, že tieto odchýlky budú spracované a prípadne opravené na AUT.

# 1) Tieto odchýlky sa označujú ako defekty / chyby / problémy / incidenty / chyby / chyby.

#dva) Ako chyby sa dajú zaznamenať všetky nasledujúce prípady

  • Chýbajúce požiadavky
  • Nesprávne pracovné požiadavky
  • Extra požiadavky
  • Nezrovnalosti v referenčnom dokumente
  • Problémy súvisiace so životným prostredím
  • Návrhy vylepšení

# 3) Zaznamenávanie defektov sa väčšinou vykonáva v excelových listoch alebo pomocou softvéru / nástroja na správu defektov. Informácie o tom, ako riešiť chyby pomocou nástrojov, nájdete na nasledujúcich odkazoch:

Čo sa dozviete:

Ako efektívne zaznamenávať chyby

Teraz sa pokúsime zistiť, ako zaznamenať chyby, s ktorými sme sa stretli v predchádzajúcom článku, v hárku programu Excel. Ako vždy je dôležitý výber štandardného formátu alebo šablóny.

ako vytvoriť reťazcové pole

Súčasťou správy o chybe sú zvyčajne nasledujúce stĺpce:

  • ID chyby: Pre jednoznačnú identifikáciu.
  • Popis chyby: Je to ako názov, ktorý stručne popisuje problém.
  • Modul / oddiel AUT: Toto je voliteľné, len kvôli väčšej jasnosti, aby sa označila oblasť AUT, v ktorej sa vyskytol problém.
  • Kroky na reprodukciu: Aká je presná postupnosť operácií, ktoré sa majú vykonať v AUTe na opätovné vytvorenie chyby, je potrebné uviesť tu. Taktiež, ak sú nejaké vstupné údaje špecifické pre daný problém, je potrebné zadať aj tieto informácie.
  • Závažnosť: Na označenie intenzity problému a prípadného dopadu, ktorý by to mohlo mať na fungovanie AUT. Pokyny, ako priraďovať a aké hodnoty priraďovať v tomto poli, nájdete v dokumente plánu testov. Prečítajte si preto Dokument o pláne skúšok z článku 3 .
  • Postavenie: Ďalej sa o tom bude diskutovať v článku.
  • Screenshot: Snímka z aplikácie, ktorá zobrazuje chybu, keď sa stala.

Toto sú niektoré z polí, ktoré musíte mať. Túto šablónu je možné rozšíriť (napr. O meno testera, ktorý problém nahlásil) alebo uzavrieť zmluvu ( Napríklad, názov modulu odstránený) podľa potreby.

Podľa vyššie uvedených pokynov a pomocou vyššie uvedenej šablóny môže vzorový protokol / hlásenie o chybe vyzerať takto:

Vzorová správa o chybe pre projekt OrangeHRM Live:

Správa o chybe OrangeHRM

=> Kliknutím sem stiahnete správu o chybe projektu naživo

Nižšie je uvedená vzorová správa o chybe vytvorená v nástroji qTest Test Management: (Kliknite na obrázok pre zväčšenie)

Ukážka hlásenia o chybe

Poruchy nie sú dobré, keď ich prihlásime a necháme si ich pre seba. Budeme ich musieť priradiť v správnom poradí, aby príslušné tímy podľa nich konali. Postup - koho priradiť alebo aké poradie je potrebné dodržiavať, nájdete tiež v dokumente plánu testov. Je to väčšinou podobné (Kliknite na obrázok pre zväčšenie)

Cyklus defektov:

Životný cyklus chyby 1

Z vyššie uvedeného procesu je možné poznamenať, že chyby prechádzajú rôznymi ľuďmi a rôznymi rozhodnutiami v procese identifikácie sú opravené. Na sledovanie a zabezpečenie transparentnosti, v akom presnom stave sa určitá chyba nachádza, sa v hlásení o chybe používa pole „Stav“. Celý proces sa označuje ako „životný cyklus chyby“. Ďalšie informácie o všetkých stavoch a ich významoch nájdete v tomto dokumente Výukový program pre Bug Life Cycle .

Niekoľko ukazovateľov pri sledovaní chýb

  • Keď sme v kreatívnom tíme / projekte / AUT nováčikom, vždy je najlepšie diskutovať o probléme, s ktorým sme sa stretli s kolegom, aby sme sa uistili, že naše chápanie toho, čo skutočne vedie k chybe, je správne alebo nie.
  • To poskytnúť všetky informácie to je nevyhnutné na reprodukciu problému. Porucha, ktorá sa vráti testovaciemu tímu so stavom nastaveným na „Nedostatok informácií“, sa na nás neodzrkadľuje veľmi pozitívne. Pozrite sa na tento príspevok - Ako vyriešiť všetky chyby bez štítku „Neplatná chyba“ .
  • Pred vytvorením nového skontrolujte, či sa nevyskytol podobný problém. „Duplicitné“ problémy sú tiež zlou správou pre tím QA.
  • Ak dôjde k problému, dôjde k nemu náhodne a nepoznáme presné kroky / situácie, v ktorých by sme ho mohli znova vytvoriť - problém vyvolať rovnako. S rizikom vzniku problému „Neprodukovateľný / málo informácií“ - stále sa musíme uistiť, že sme všetky možné poruchy fungovali čo najlepšie.
  • Všeobecná prax je to, že tím QA vytvára chyby každého z nich v excelovom hárku počas dňa a konsoliduje ich na konci dňa.

Kompletný životný cyklus chyby

Pokiaľ by sme pre náš živý projekt sledovali životný cyklus defektu pre defekt 1,

ako otvoriť súbor eps
  • Keď ho (tester) vytvorím, jeho stav je „Nový“. Keď ho priradím vedúcemu tímu QA, stav je stále „Nový“, ale vlastníkom je teraz vedúci QA.
  • Vedúci QA problém skontroluje a po určení, že ide o platný problém, sa problém priradí vedúcemu Dev. V tejto fáze je stav „pridelených„ a majiteľom je Dev lead.
  • Vedúci vývojára potom pridelí tento problém vývojárovi, ktorý bude pracovať na vyriešení tohto problému. Stav bude teraz „Prebieha práca„ (alebo niečo podobné v tomto zmysle), vlastník je vývojár.
  • Pri defekte 1 vývojár nie je schopný chybu reprodukovať, a preto ju priradí späť tímu QA a nastaví stav na „Nie je schopný reprodukovať“.
  • Ak by vývojár mohol na tom pracovať a opraviť problém, stav by sa nastavil na „vyriešený„ a problém bude pridelený späť tímu QA.
  • Tím QA to potom vyzdvihne, znova otestuje problém a ak bude opravený, nastaví stav na „Zatvorené„ . Ak problém stále existuje, stav je nastavený na „Znova otvoriť„ a proces pokračuje.
  • V závislosti od ďalších situácií môže byť stav nastavený ako „Odložené„ „Nedostatok informácií“, „Duplikát„ , „pracuje podľa plánu„ atď. vývojárom.
  • Táto metóda zaznamenávania defektov, ich hlásenia a prideľovania, ich spravovania je jednou z hlavných činností vykonávaných členmi tímu QA počas fázy vykonávania testu. Robí sa to každý deň, kým nie je dokončený konkrétny testovací cyklus.
  • Po dokončení cyklu 1 bude vývojovému tímu trvať deň alebo dva, kým spojí všetky opravy a znova zostaví kód do ďalšej verzie, ktorá sa použije v nasledujúcom cykle.
  • Rovnaký proces opäť pokračuje aj pre cyklus 2. Na konci cyklu existuje šanca, že v aplikácii môžu stále existovať problémy „otvorené“ alebo nevyriešené.
  • V tejto fáze - pokračujeme v 3. cykle? Ak áno, kedy prestaneme testovať?

Kritériá ukončenia pre testovanie projektu OrangeHRM Live

Tu používame to, čo by sme nazvali „Kritériá výstupu“. Toto je vopred definované v dokumente Plán testov. Je to jednoducho vo forme kontrolného zoznamu, ktorý určí, či testovanie ukončíme po 2. cykle alebo pôjdeme ešte jeden cyklus. Vyzerá to, že pri vyplnení nižšie bude zohľadnená niekoľko hypotetických odpovedí na nasledujúce otázky týkajúce sa projektu OrangeHRM:

Testovacie výstupné kritériá

Keď sa pozorne pozrieme na vyššie uvedený kontrolný zoznam, sú tam spomenuté metriky a odhlásenie, o ktorých sme predtým nehovorili. Hovorme o nich teraz.

Testovacie metriky

Zistili sme, že počas fázy vykonávania testu sa všetkým ostatným členom projektového tímu zasielajú správy, ktoré poskytujú jasnú predstavu o čo sa deje vo fáze vykonávania QA . Tieto informácie sú dôležité pre každého, aby získali validáciu o celkovej kvalite konečného produktu.

Predstavte si, že uvádzam, že prešlo 10 testovacích prípadov alebo bolo vykonaných 100 testovacích prípadov - tieto čísla sú iba nespracovanými údajmi a neposkytujú veľmi dobrý prehľad o tom, ako sa veci majú.

Pri vyplňovaní tejto medzery zohrávajú zásadnú úlohu metriky. Metriky sú jednoduché slová, inteligentné čísla, ktoré testovací tím zhromažďuje a udržuje . Napríklad, ak som povedal, že prešlo 90% testovacích prípadov, má to väčší zmysel ako povedať, že prešlo 150 testovacích prípadov. Nie?

Počas fázy vykonávania testu sa zhromažďujú rôzne druhy metrík. Aké metriky presne sa majú zhromažďovať a udržiavať po aké časové obdobia - tieto informácie nájdete v dokumente plánu testov.

Nasledujú najčastejšie zhromažďované testovacie metriky pre väčšinu projektov:

  • Úspešné absolvovanie testovacích prípadov
  • Poruchy hustoty
  • Percento kritických chýb
  • Poruchy, číslo závažnosti

Pozrite sa na Správa o stave pripojená k tomuto článku zistiť, ako sa tieto metriky používajú.

Správa o odhlásení / dokončení testu

Pretože musíme oznámiť všetkým zainteresovaným stranám, že testovanie začalo, je tiež povinnosťou tímu QA informovať všetkých o tom, že testovanie bolo dokončené, a podeliť sa o výsledky. Tím QA (zvyčajne vedúci tímu / manažér QA) teda zvyčajne odosiela e-mail s oznámením, že sa tím QA odhlásil od produktu pripojeného k výsledkom testu a zoznamu otvorených / známych problémov.

Vzorový test Odhlásiť sa z e-mailu:

Komu: Klient, PM, tím vývojárov, tím DB, tím BA, QA, tím pre životné prostredie (a ktokoľvek iný, koho je potrebné zahrnúť)
Email: Ahoj tím,

Tím QA sa prihlásil k softvéru OrangeHRM verzie 3.0 po úspešnom ukončení 2 cyklov funkčného testovania webu.

Testovacie prípady a výsledky ich vykonania sú pripojené k e-mailu. (Alebo uveďte miesto, kde sa nachádzajú. Alebo ak používate softvér na správu testov, uveďte ďalšie podrobnosti.)

Zoznam známych problémov je pripojený k e-mailu. (Opäť je možné pridať akékoľvek ďalšie odkazy, ktoré majú zmysel.)

Vďaka,
Vedenie tímu QA.

Prílohy: Záverečná správa o vykonaní, Záverečná správa o chybe / závade, Zoznam známych problémov

Akonáhle tím QA vyjde testovací odhlasovací e-mail, sme oficiálne hotoví s procesom STLC. To nemusí nevyhnutne znamenať dokončenie fázy „testu“ SDLC. Čaká nás ešte testovanie UAT. Nájsť viac podrobností o testovaní UAT nájdete tu .

Po dokončení UAT sa SDLC presunie do fázy nasadenia, kde bude zverejnená a bude k dispozícii svojim zákazníkom / koncovým používateľom na konzumáciu.

To je všetko!

To bolo našou snahou priniesť našim čitateľom tie najpríjemnejšie zážitky z projektu QA. Dajte nám prosím vedieť svoje komentáre a otázky týkajúce sa tejto bezplatnej online školiacej série QA Testovania softvéru.

Odporúčané čítanie

^