Sledování chyb

Při spouštění testů pro ověření vašich požadavků určitě naleznete chyby.Použijte pracovní položku chyby k popisu a sledování postupu pro každou chybu, kterou najdete.

Další informace o tom, jak vytvářet pracovních položek chyb, naleznete v tématu Spouštění manuálních testů pomocí aplikace Team Web Access.Jak jsou nacházeny chyby, postupujte podle postupu v tomto tématu a stanovte jejich prioritu, abyste zajistili jejich opravu a vytvoření záznamu práce a rozhodnutí, které byly zapojeny.

Chyby třídění

Schůzky třídění se konají v nastavených intervalech po zahájení vývojových prací a testování na projektu.Jak často a jak dlouhé uspořádat zasedání závisí na konkrétní situaci.

Schůzky třídění chyby jsou obvykle vedeny vedoucím projektu za přítomnosti týmových vedoucích a případně obchodních analytiků a účastníků, kteří mohou mluvit o konkrétních rizicích projektu.Vedoucí projektu může použít dotaz aktivní chyby na nové a znovu otevřené chyby pro vygenerování seznamu chyb ke třídění.

Před zahájením závěrečné kontroly navrhněte sadu kritérií, která určují, jaké chyby by měly být opraveny a s jakou prioritou.Kritéria obvykle určí závažnost chyb, chyby, které jsou spojeny s funkcemi významné hodnoty (nebo s významnými náklady příležitosti při zdržení), nebo jiná rizika projektu.

Kritéria třídění by měla být uložena ve složce Dokumenty týmového projektu.V průběhu času bude dokument aktualizován.Předpokládá se, že má váš projekt zapnutou správu verzí a že specifická kritéria používaná v daném okamžiku na projektu mohou být získána pro účely auditu a hodnocení důkazů.

V rané fázi projektu se pravděpodobně rozhodnete opravit většinu chyb, které najdete při kontrole.Jak však projekt pokračuje, kritéria(nebo panel) závěrečné kontroly lze vznést ke snížení počtu chyb, které jsou opraveny.

Zvednutí laťky kritérií třídění a ponechání hlášených chyb bez opravy je kompromis.Jde o kompromis, který říká, že oprava chyb je méně důležitá než dodržení rozsahu projektu, rozpočtu a harmonogramu.

Pomocí svých kritérií určete, které chyby opravit a jak nastavit jejich stav, prioritu, závažnost a ostatní pole.Ve výchozím nastavení, šablona nabízí čtyři priority: 1 pro "musí opravit" až 4 pro "nedůležité". Při změně definice v šabloně procesu byste měli aktualizovat návod, text nápovědy a všechny dokumenty kritérií odpovídajícím způsobem.

Opravit chyby

Poté, co chyba prošla závěrečnou kontrolou a byla stanovena priorita, by měla být přiřazena vývojáři pro další zkoumání.

Pracovní položka chyby obsahuje kartu pro reprodukci kroků, které by měly poskytnout to, co je třeba pro reprodukci chyb.Je však možné použít nápovědu IntelliTrace k reprodukci těžkých chyb.Další informace o IntelliTrace naleznete v části Sledování kvality softwaru.

Poté, co vývojář rozhodne o dalším postupu, by mělo být rozhodnutí poznamenáno v pracovní položce chyby.

Rozhodnout o opravě

Při spolupráci s dalšími členy týmu může vývojář doporučit opravu, která má vliv na ostatní části kódu a která může vyžadovat významné regresní testování.Všechny konverzace, které se týkají posouzení rizika takové opravy, by měly být zaznamenány v historii chyb pracovní položky, protože dokumentují užitečné analýzy rozhodnutí a důkazy správy rizik pro audit nebo standardní způsob hodnocení CMMI pro hodnocení procesu zlepšování (SCAMPI).Další informace o CMMI naleznete v tématu Základní informace o CMMI.

Aktualizovat a spustit testy jednotky pro opravu chyb

Testování částí ověří správnou implementaci části kódu.Zápis a provádění testů jednotek identifikuje chyby před začátkem testování, a proto pomáhá snížit náklady na řízení jakosti.Vývojáři musí psát testy jednotek pro veškerý kód, který bude zapsán, jako součást implementace úkolu vývoje nebo implementace oprav chyb.Další informace naleznete v tématu Ověřování kódu pomocí testování částí.

Můžete chtít napsat test jednotky před provedením jakýchkoliv oprav kódu ve strategii vývoje „nejprve otestovat“.Vývojáři softwaru agilní preferují tento typ strategie.CMMI nevyžaduje, aby byly testovací jednotky zapsány v určitém pořadí, jen aby bylo dosaženo efektivního ověření funkčnosti.

Důkaz, že jednotkové testy byly napsány a spuštěny, je vyžadován pro hodnocení CMMI.Nezapomeňte propojit testy s pracovními položkami úkolu pro opravu kódu a propojit tyto úkoly s pracovními položkami chyb.To poskytuje sledovatelnost důkazů, které bude vedoucí ohodnocovatel SCAMPI hledat.

Zkontrolujte a refaktorujte kód pro opravu chyby

Kontrola kódu se používá k zajištění, že nový nebo změněný kód splňuje stanovenou kvalitu, předtím než je kód integrován do denních sestavení.Faktory ovlivňující kvalitu jsou standardy kódování, soulad s architekturou a návrhem, výkon, čitelnost a zabezpečení.Revize kódu také poskytuje další informace od jiných vývojářů o tom, jak by měly být kód zapsán.Další informace o tom, jak kontrolovat a refaktorovat kód, naleznete v tématu Implementace úkolů vývoje.

Zavřít chyby

Poté, co je chyba opravena, by měla být přiřazena testerovi pro ověření, zda je problém vyřešen, před uzavřením pracovní položky chyby.

Ověření opravy

K ověření opravy by se tester měl pokusil opakovat chybu, vyhledat další neočekávané chování a v případě potřeby chyb znovu aktivovat.

Při ověřování řešení chyb můžete zjistit, že chyba nebyla zcela opravena nebo můžete s řešením nesouhlasit.V tomto případě můžete probrat chybu s osobou, která ji vyřešila, dosáhnout dohody a případně znovu aktivovat chybu.Pokud chybu znovu aktivujete, nezapomeňte uvést důvody opětovné aktivace chyby v popisu chyby, aby se informace zachovaly.

Zavřít pracovní položku chyby

Chyba je uzavřen z mnoha důvodů.V jednoduchém případě chyba byla ověřena jako opravená a také byla uzavřena.Chyba však může být odložena na další verzi produktu, ověřenou nebo reprodukovatelnou, nebo potvrzena jako duplicitní.Každý z těchto důvodů musí být dokumentován a chyba musí být správně uzavřena, aby bylo zajištěno, že nedojde k pochybnostem o důvodu uzavření.