Menu

Živé sledování chyb projektu, testovací metriky a odhlášení z testu - 6. den školení QA zdarma

  • Hlavní
  • Sledování Chyby
  • Živé sledování chyb projektu, testovací metriky a odhlášení z testu - 6. den školení QA zdarma

live project bug tracking

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

Toto je závěrečná část našeho „ Školení testování softwaru na živém projektu “Série.

Bude to o defektech a také o několika zbývajících tématech, která poznačí dokončení fáze provádění testu STLC.

V předchozí článek Během provádění testu jsme narazili na situaci, kdy nebyl splněn očekávaný výsledek testovacího případu. Během průzkumného testování jsme také identifikovali neočekávané chování.

Živé sledování chyb projektu, testovací metriky a testovací odhlášení

Co se stane, když narazíme na tyto odchylky?

Zjevně je musíme zaznamenat a sledovat, abychom zajistili, že tyto odchylky budou zpracovány a nakonec opraveny na AUT.

# 1) Tyto odchylky se označují jako defekty / chyby / problémy / incidenty / chyby / chyby.

#dva) Všechny následující případy lze zaznamenat jako vady

  • Chybějící požadavky
  • Nesprávně fungující požadavky
  • Zvláštní požadavky
  • Nesrovnalosti referenčního dokumentu
  • Problémy související s životním prostředím
  • Vylepšení návrhů

# 3) Záznam defektů se většinou provádí v excelových listech nebo pomocí softwaru / nástroje pro správu defektů. Informace o tom, jak řešit vady pomocí nástrojů, zkuste použít následující odkazy:

Co se naučíte:

Jak efektivně zaznamenávat vady

Nyní se pokusíme zjistit, jak zaznamenat vady, na které jsme narazili v předchozím článku, v listu aplikace Excel. Jako vždy je důležitý výběr standardního formátu nebo šablony.

nejlepší stahování hudby ve formátu mp3 pro Android

Součástí zprávy o vadách jsou obvykle následující sloupce:

  • ID vady: Pro jedinečnou identifikaci.
  • Popis závady: Je to jako název, který krátce popisuje problém.
  • Modul / sekce AUT: Toto je volitelné, pouze pro větší srozumitelnost, pokud jde o označení oblasti AUT, kde došlo k problému.
  • Kroky k reprodukci: Jaká je přesná sekvence operací, které mají být provedeny na AUTu k opětovnému vytvoření chyby, jsou zde uvedeny. Pokud jsou nějaká vstupní data specifická pro daný problém, je také nutné zadat tyto informace.
  • Vážnost: K označení intenzity problému a případně jeho dopadu na fungování AUT. Pokyny, jak přiřadit a jaké hodnoty přiřadit v tomto poli, najdete v dokumentu plánu zkoušek. Podívejte se prosím na Dokument Testovací plán z článku 3 .
  • Postavení: Bude se o nich dále pojednávat v článku.
  • Snímek obrazovky: Snímek aplikace k zobrazení chyby, když k ní došlo.

Toto jsou některá z polí, která musíte mít. Tuto šablonu lze rozšířit (např. O jméno testera, který problém nahlásil) nebo uzavřít smlouvu ( Například, název modulu odstraněn) podle potřeby.

Podle výše uvedených pokynů a pomocí výše uvedené šablony může ukázkový protokol / sestava vad vypadat takto:

Ukázková zpráva o vadě projektu OrangeHRM Live:

Zpráva o vadách OrangeHRM

=> Kliknutím sem stáhnete živou zprávu o vadách projektu

Níže je ukázka zprávy o defektu vytvořená v nástroji qTest Test Management: (Klikněte na obrázek pro zvětšení)

Ukázka hlášení o vadě

Vady nejsou dobré, když je zaznamenáme a necháme si je pro sebe. Budeme je muset přiřadit ve správném pořadí, aby na ně příslušné týmy jednaly. Proces - komu přiřadit nebo jaké pořadí následovat najdete také v dokumentu plánu zkoušek. Je to většinou podobné (Klikněte na obrázek pro zvětšení)

Cyklus závad:

Životní cyklus vady 1

Z výše uvedeného procesu lze poznamenat, že chyby procházejí různými lidmi a různými rozhodnutími v procesu identifikace jsou opraveny. Ke sledování a stanovení transparentnosti, v jakém stavu se určitá chyba nachází, se ve zprávě o chybě používá pole „Stav“. Celý proces se označuje jako „životní cyklus chyby“. Další informace o všech stavech a jejich významech naleznete v tomto dokumentu Výukový program Bug Life Cycle .

Několik ukazatelů při sledování chyb

  • Když jsme v kreativním týmu / projektu / AUT nováčkem, vždy je nejlepší diskutovat o problému, se kterým jsme se setkali s partnerem, abychom se ujistili, že naše chápání toho, co skutečně vede k defektu, je správné nebo ne.
  • Na poskytnout všechny informace to je nezbytné k reprodukci problému. Vada, která se vrací zpět k testovacímu týmu se stavem nastaveným na „Nedostatek informací“, se na nás příliš pozitivně neodráží. Podívejte se na tento příspěvek - Jak vyřešit všechny chyby bez označení „Neplatná chyba“ .
  • Před vytvořením nového zkontrolujte, zda nevznikl podobný problém. „Duplicitní“ problémy jsou také špatnou zprávou pro tým QA.
  • Pokud dojde k problému, dojde k němu náhodně a neznáme přesné kroky / situace, ve kterých jej můžeme znovu vytvořit - problém navýšit stejně. S rizikem, že problém bude nastaven na 'Neprodukovatelný / nedostatek informací' - stále se musíme ujistit, že jsme všechny možné poruchy řešili v co nejlepší míře.
  • Obecná praxe je to, že tým QA vytváří chyby každého z nich v listu aplikace Excel během dne a konsoliduje je na konci dne.

Kompletní životní cyklus vady

Pokud bychom pro náš živý projekt sledovali životní cyklus defektu pro defekt 1,

jak otevřít soubor eps
  • Když jej (tester) vytvořím, jeho stav je 'Nový“. Když jej přiřadím vedoucímu týmu QA, stav je stále „Nový“, ale vlastník je nyní vedoucím QA.
  • Vedoucí QA problém zkontroluje a po určení, že se jedná o platný problém, je problém přiřazen vedoucímu Dev. V této fázi je stav 'Přiřazeno' a majitelem je Dev lead.
  • Vedoucí vývojáře poté přiřadí tento problém vývojáři, který bude pracovat na vyřešení tohoto problému. Stav bude nyní 'Probíhá práce' (nebo něco podobného v tomto smyslu), vlastníkem je vývojář.
  • U defektu 1 vývojář není schopen chybu reprodukovat, takže ji přiřadí zpět týmu QA a nastaví stav jako 'Není schopen reprodukovat“.
  • Alternativně, pokud by byl vývojář schopen na tom pracovat a opravit problém, stav by byl nastaven na 'vyřešen' a problém by byl přidělen zpět týmu QA.
  • Tým QA to poté vyzvedne, znovu otestuje problém a pokud bude opraven, nastaví stav na 'Zavřeno' . Pokud problém stále existuje, je stav nastaven na 'Znovu otevřít' a proces pokračuje.
  • V závislosti na dalších situacích lze stav nastavit jako 'Odložený' „Nedostatek informací“, 'Duplikát' , 'pracuje podle plánu' atd. vývojářem.
  • Tato metoda zaznamenávání vad, hlášení a přiřazování, jejich správa je jednou z hlavních činností prováděných členy týmu QA během fáze provádění testu. To se provádí denně, dokud není dokončen konkrétní testovací cyklus.
  • Po dokončení cyklu 1 bude vývojovému týmu trvat jeden nebo dva dny, než konsoliduje všechny opravy a znovu sestaví kód do další verze, která se použije pro další cyklus.
  • Stejný proces opět pokračuje i pro cyklus 2. Na konci cyklu existuje šance, že v aplikaci mohou stále existovat nějaké problémy „otevřené“ nebo nefixované.
  • V této fázi - pokračujeme v cyklu 3? Pokud ano, kdy přestaneme testovat?

Kritéria ukončení pro testování OrangeHRM Live Project

Zde používáme to, co bychom nazvali „Kritéria opuštění“. To je předdefinováno v dokumentu Testovací plán. Je to jednoduše ve formě kontrolního seznamu, který určí, zda ukončíme testování po 2. cyklu, nebo přejdeme na další cyklus. Vypadá to, že níže při vyplnění bereme v úvahu hypotetické odpovědi na následující otázky týkající se projektu OrangeHRM:

Kritéria pro odchod z testu

Když se pečlivě podíváme na výše uvedený kontrolní seznam, jsou zde zmíněny metriky a odhlášení, o kterých jsme dříve nemluvili. Promluvme si o nich hned.

Testovací metriky

Zjistili jsme, že během fáze provádění testu jsou rozesílány zprávy všem ostatním členům projektového týmu, aby poskytly jasnou představu o co se děje ve fázi provádění QA . Tyto informace jsou důležité pro každého, aby získali ověření o celkové kvalitě konečného produktu.

Představte si, že uvádím, že prošlo 10 testovacích případů nebo bylo provedeno 100 testovacích případů - tato čísla jsou pouze nezpracovaná data a neposkytují velmi dobrou perspektivu toho, jak se věci dějí.

Při vyplňování této mezery hrají zásadní roli metriky. Metriky jsou jednoduchými slovy, inteligentní čísla, která testovací tým shromažďuje a udržuje . Například, pokud jsem řekl, že 90% testovaných případů prošlo, má to větší smysl než říct, že prošlo 150 testovacích případů. Že ano?

Během fáze provádění testu se shromažďují různé druhy metrik. Jaké metriky přesně mají být shromažďovány a udržovány po jakou dobu - tyto informace najdete v dokumentu plánu zkoušek.

Níže jsou uvedeny nejčastěji shromážděné testovací metriky pro většinu projektů:

  • Procento testovacích případů
  • Hustota vad
  • Procento kritických vad
  • Vady, číslo závažnosti

Podívejte se na Zpráva o stavu připojená k tomuto článku abyste zjistili, jak se tyto metriky používají.

Protokol o odhlášení / dokončení testu

Jelikož musíme oznámit všem zúčastněným stranám, že testování začalo, je také povinností týmu QA informovat každého, že testování bylo dokončeno, a sdílet výsledky. Tým QA (obvykle vedoucí týmu / manažer QA) tedy obvykle zasílá e-mail s oznámením, že se tým QA odhlásil od produktu připojujícího výsledky testu a seznam otevřených / známých problémů.

Ukázkový test Odhlásit se E-mail:

Na: Klient, PM, Dev team, DB team, BA, QA team, Environment Team (and anyone else that need to be included)
E-mailem: Ahoj tým,

Tým QA odhlásí software OrangeHRM verze 3.0 po úspěšném dokončení 2 cyklů funkčního testování webu.

Testovací případy a jejich výsledky provedení jsou připojeny k e-mailu. (Nebo uveďte místo, kde jsou přítomni. Nebo pokud používáte software pro správu testů, uveďte podrobnosti týkající se stejných.)

Seznam známých problémů je připojen také k e-mailu. (Opět lze přidat jakékoli další odkazy, které mají smysl.)

Dík,
Vedení týmu QA.

Přílohy: Závěrečná zpráva o provedení, závěrečná zpráva o závadě / závadě, seznam známých problémů

Jakmile testovací přihlašovací e-mail zmizí z týmu QA, jsme oficiálně hotovi s procesem STLC. To nemusí nutně znamenat dokončení fáze „Testování“ SDLC. Abychom to mohli udělat, musíme ještě dokončit testování UAT. Nalézt více podrobností o testování UAT zde .

Po dokončení UAT se SDLC přesune do fáze nasazení, kde bude aktivní a bude k dispozici svým zákazníkům / koncovým uživatelům ke spotřebě.

A je to!

To byla naše snaha přinést našim čtenářům ty nejžhavější zážitky jako je projekt QA. Sdělte nám prosím své připomínky a dotazy týkající se této bezplatné online školení QA o testování softwaru.

Doporučené čtení

^