how create requirements traceability matrix
Co je to Matice sledovatelnosti požadavků (RTM) v Testování softwaru: Podrobný průvodce vytvořením Matice sledovatelnosti s příklady a ukázkovou šablonou
Dnešní tutoriál je o důležitém nástroji QC, který je buď příliš zjednodušený (přečteno přehlédnuto), nebo příliš zdůrazněn - tj. Traceability Matrix (TM).
Tvorba, kontrola nebo sdílení Traceability Matrix nejčastěji není jedním z primárních výstupů procesu QA - takže se na něj příliš nezaměřuje, což způsobuje nedostatečné zdůraznění. Někteří klienti naopak očekávají, že TM odhalí na svém produktu (v testu) aspekty otřesů a jsou zklamaní.
'Při správném použití může být matice sledovatelnosti vaším GPS pro vaši cestu QA.'
Jak je obvyklá praxe v STH , v tomto článku uvidíme aspekty „Co“ a „Jak“ TM.
Co se naučíte:
- Co je matice sledovatelnosti požadavků?
- Vyzkoušejte pokrytí a sledovatelnost požadavků
- Jak vytvořit matici sledovatelnosti požadavků
Co je matice sledovatelnosti požadavků?
V Matici sledovatelnosti požadavků nebo RTM jsme nastavili proces dokumentování vazeb mezi uživatelskými požadavky navrženými klientem na budovaný systém. Stručně řečeno, jedná se o dokument na vysoké úrovni, který mapuje a sleduje požadavky uživatelů pomocí testovacích případů, aby bylo zajištěno, že u každého požadavku bude dosaženo odpovídající úrovně testování.
Proces kontroly všech testovacích případů, které jsou definovány pro jakýkoli požadavek, se nazývá sledovatelnost. Sledovatelnost nám umožňuje určit, které požadavky způsobily největší počet defektů během procesu testování.
Zaměření každé testovací zakázky je a mělo by být maximální pokrytí testem. Pokrytím to jednoduše znamená, že musíme otestovat vše, co má být testováno. Cílem každého testovacího projektu by mělo být 100% pokrytí testem.
Matice sledovatelnosti požadavků stanoví způsob, jak zajistit, abychom prováděli kontroly aspektu pokrytí. Pomáhá při vytváření snímku k identifikaci mezer v pokrytí. Stručně řečeno, lze jej také označit jako metriky, které určují počet testovacích případů Spustit, Úspěšně, Neúspěšně nebo Blokováno atd. Pro každý požadavek.
Proč je vyžadována sledovatelnost požadavků?
Matice sledovatelnosti požadavků pomáhá propojit požadavky, Testovací případy a vady přesně. Celá aplikace je testována tím, že má sledovatelnost požadavků ( End to End testování aplikace).
software pro stahování videí z vaší aplikace
Sledovatelnost požadavku zajišťuje dobrou ‚kvalitu 'aplikace, protože jsou testovány všechny funkce. Kontrola kvality lze dosáhnout testováním softwaru pro nepředvídané scénáře s minimálními vadami a splněním všech funkčních i nefunkčních požadavků.
Matice sledovatelnosti požadavků pomáhá při testování softwarových aplikací ve stanovené době, rozsah projektu je dobře určen a jeho implementace je dosažena podle požadavků a potřeb zákazníka a náklady na projekt jsou dobře kontrolovány.
Nedochází k únikům vad, protože celá aplikace je testována na své požadavky.
Typy matice sledovatelnosti
Dopředná sledovatelnost
V požadavcích „Předat sledovatelnost“ na testovací případy. Zajišťuje, že projekt postupuje požadovaným směrem a že každý požadavek je důkladně otestován.
Zpětná sledovatelnost
Testovací případy jsou mapovány s požadavky v části „Zpětná sledovatelnost“. Jeho hlavním účelem je zajistit, aby byl vyvíjený produkt na správné cestě. Pomáhá také určit, že nejsou přidány žádné další nespecifikované funkce, a tím je ovlivněn rozsah projektu.
Obousměrná sledovatelnost
(Vpřed + vzad): Matice Good Traceability obsahuje odkazy z testovacích případů na požadavky a naopak (požadavky na testovací případy). Toto se označuje jako „obousměrná“ sledovatelnost. Zajišťuje, že všechny testovací případy lze vysledovat podle požadavků a každý specifikovaný požadavek má pro ně přesné a platné testovací případy.
Příklady RTM
# 1) Obchodní požadavek
BR1 : Měla by být k dispozici možnost psaní e-mailů.
Scénář zkoušky (technická specifikace) pro BR1
TS1 : Je k dispozici možnost psaní pošty.
Testovací případy:
Testovací případ 1 (TS1.TC1) : Možnost psaní pošty je povolena a funguje úspěšně.
Testovací případ 2 (TS1.TC2) : Možnost psaní pošty je zakázána.
# 2) Vady
Po provedení testovacích případů, pokud se zjistí nějaké vady, které lze také vypsat a zmapovat s obchodními požadavky, testovací scénáře a testovací případy.
Například, Pokud TS1.TC1 selže, tj. Možnost Vytvořit poštu, i když je povolená, nefunguje správně, může být chyba zaznamenána. Předpokládejme, že ID chyby je automaticky generované nebo ručně přiřazené číslo D01, pak to může být mapováno s čísly BR1, TS1 a TS1.TC1.
Všechny požadavky tedy mohou být reprezentovány ve formátu tabulky.
Obchodní požadavek # | Scénář testu | Modelový případ # | Vady # |
---|---|---|---|
BR1 | TS1 | TS1.TC1 TS1.TC2 | D01 |
BR2 | TS2 | TS2.TC1 TS2, TC2 TS2.TC3 | D02 D03 |
BR3 | TS3 | TS1.TC1 TS2.TC1 TS3.TC1 TS3.TC2 | NULA |
Vyzkoušejte pokrytí a sledovatelnost požadavků
Co je pokrytí testem?
Test Coverage uvádí, které požadavky zákazníků mají být ověřeny na začátku testovací fáze. Test Coverage je termín, který určuje, zda jsou testovací případy psány a prováděny, aby bylo zajištěno úplné otestování softwarové aplikace takovým způsobem, že jsou hlášeny minimální nebo NIL závady.
Jak dosáhnout pokrytí testu?
Maximální pokrytí testem lze dosáhnout stanovením dobré „sledovatelnosti požadavků“.
- Mapování všech vnitřních vad na navržené testovací případy
- Mapování všech vad zákazníka (CRD) na jednotlivé testovací případy pro budoucí sadu regresních testů
Druhy požadavků Specifikace
# 1) Obchodní požadavky
Skutečné požadavky zákazníků jsou uvedeny níže v dokumentu známém jako Dokument obchodních požadavků (BRS) . Tento BRS je podrobně odvozený seznam požadavků na vysoké úrovni po krátké interakci s klientem.
Obvykle jej připravují „obchodní analytici“ nebo projekt „architekt“ (v závislosti na organizaci nebo struktuře projektu). Dokument „Specifikace softwarových požadavků“ (SRS) je odvozen od BRS.
# 2) Dokument o specifikaci softwarových požadavků (SRS)
Jedná se o podrobný dokument, který obsahuje všechny pečlivé podrobnosti všech funkčních i nefunkčních požadavků. Tento SRS je základem pro návrh a vývoj softwarových aplikací.
# 3) Dokumenty o požadavcích na projekt (PRD)
PRD je referenční dokument pro všechny členy týmu v projektu, který jim řekne přesně, co by měl produkt dělat. Lze jej rozdělit na části jako Účel produktu, Vlastnosti produktu, Kritéria vydání a Rozpočet a časový plán projektu.
# 4) Použijte dokument případu
Je to dokument, který pomáhá při navrhování a implementaci softwaru podle obchodních potřeb. Mapuje interakce mezi aktérem a událostí s rolí, kterou je třeba provést k dosažení cíle. Jedná se o podrobný podrobný popis toho, jak je třeba úkol provést.
Například,
Herec: Zákazník
Role: Stáhnout hru
Stažení hry je úspěšné.
Případy použití mohou být také součástí dokumentu SRS podle pracovního procesu organizace.
# 5) Dokument o ověření vady
Je zdokumentován a obsahuje všechny podrobnosti týkající se vad. Tým může udržovat dokument „Ověření vady“ pro opravu a opětovné testování vad. Testeři mohou odkazovat na dokument „Ověření vady“, když chtějí ověřit, zda jsou vady opraveny nebo ne, znovu otestovat vady na jiném OS, zařízení, jiné konfiguraci systému atd.
Dokument „Ověření vady“ je užitečný a důležitý, pokud existuje vyhrazená fáze odstraňování a ověřování vad.
# 6) Uživatelské příběhy
Příběh uživatele se primárně používá při „agilním“ vývoji k popisu softwarové funkce z pohledu koncového uživatele. Uživatelské příběhy definují typy uživatelů, jakým způsobem a proč chtějí určitou funkci. Požadavek se zjednodušuje vytvářením uživatelských příběhů.
V současné době všechna softwarová odvětví směřují k používání uživatelských příběhů a agilního vývoje a odpovídajících softwarových nástrojů pro zaznamenávání požadavků.
Výzvy pro sběr požadavků
# 1) Shromážděné požadavky musí být podrobné, jednoznačné, přesné a dobře specifikované. Ale je NEDĚLEJ vhodné opatření pro výpočet těchto podrobností, jednoznačnosti, přesnosti a dobře definovaných specifikací, které jsou pro sběr požadavků zapotřebí.
#dva) Výklad „obchodního analytika“ nebo „vlastníka produktu“, který poskytne informace o požadavcích, je zásadní. Podobně musí tým, který obdrží informace, získat vhodná vysvětlení, aby pochopil očekávání zúčastněných stran.
Porozumění musí být synchronizováno jak s obchodními potřebami, tak se skutečným úsilím vyžadovaným pro implementaci aplikace.
# 3) Informace by také měly být odvozeny z pohledu koncového uživatele.
# 4) Státy zúčastněných stran jsou v rozporu nebo jsou v rozporu s požadavky v různých dobách.
# 5) Hledisko koncového uživatele se z několika důvodů nezohledňuje a další zúčastněné strany si myslí, že „zcela“ rozumí tomu, co je od produktu požadováno, což obecně neplatí.
# 6) Zdroje nedostatečné dovednosti pro aplikaci vyvinuté.
# 7) Časté změny rozsahu nebo změny priority modulů.
# 8) Zmeškané, implicitní nebo nezdokumentované požadavky.
# 9) Nekonzistentní nebo vágní požadavky stanovené zákazníky.
# 10) Závěr všech výše uvedených faktorů je takový, že „úspěch“ nebo „neúspěch“ projektu značně závisí na požadavku.
Jak může sledovatelnost požadavků pomoci
# 1) Kde je implementován požadavek?
Například,
Požadavek: Implementujte funkci „Vytvořit poštu“ v poštovní aplikaci.
Implementace: Na hlavní stránce by mělo být umístěno tlačítko „Vytvořit zprávu“ a mělo by k němu být přistupováno.
# 2) Je požadavek nutný?
Například,
Požadavek: Implementujte funkci „Vytvořit poštu“ v poštovní aplikaci pouze pro určité uživatele.
Implementace: Podle přístupových práv uživatelů, pokud je e-mailová schránka „Jen pro čtení“, nebude v tomto případě tlačítko „Vytvořit poštu“ vyžadováno.
# 3) Jak mohu interpretovat požadavek?
Například,
Požadavek: Funkce „psaní pošty“ v poštovní aplikaci s písmy a přílohami.
Implementace: Po kliknutí na možnost „Vytvořit zprávu“ by měly být poskytovány všechny funkce?
- Text Text pro psaní e-mailů a úpravy v různých typech písma a také tučné kurzívy, podtržení
- Typy příloh (obrázky, dokumenty, jiné e-maily atd.)
- Velikost příloh (maximální povolená velikost)
Tím se požadavky rozdělí na dílčí požadavky.
# 4) Jaká designová rozhodnutí ovlivňují implementaci požadavku?
Například,
Požadavek: Všechny prvky „Doručená pošta“, „Odeslaná pošta“, „Koncepty“, „Spam“, „Koš“ atd. By měly být jasně viditelné.
Implementace: Viditelné prvky by měly být zobrazeny ve formátu „Strom“ nebo „Tab“.
# 5) Jsou přiděleny všechny požadavky?
Například,
Požadavek: K dispozici je možnost „Koš“.
Implementace: Pokud byla zadána možnost „Koš“, musí být nejprve implementována možnost „Odstranit“ e-maily (požadavek) a měla by fungovat přesně. Pokud možnost „Odstranit“ poštu funguje správně, budou se do složky „Koš“ shromažďovat pouze smazané e-maily a implementace možnosti „koš“ (požadavek) bude mít smysl (bude užitečné).
Výhody pokrytí RTM a testů
# 1) Vyvinutá a testovaná sestava má požadovanou funkčnost, která splňuje potřeby a očekávání „Zákazníků“ / „Uživatelů“. Zákazník musí dostat, co chce. Překvapit zákazníka aplikací, která nedělá to, co se od ní očekává, není pro nikoho uspokojivou zkušeností.
#dva) Konečný produkt (softwarová aplikace) vyvinutý a dodaný zákazníkovi musí zahrnovat pouze funkce, které jsou potřebné a očekávané. Extra funkce poskytované v softwarové aplikaci se mohou zpočátku zdát atraktivní, dokud nenastane režie času, peněz a úsilí o její vývoj.
co je nejlepší mp3 downloader pro Android
Tato zvláštní funkce se také může stát zdrojem defektů, které mohou zákazníkovi po instalaci způsobit problémy.
# 3) Počáteční úkol vývojáře je jasně definován, protože nejprve pracuje na implementaci požadavků, které mají podle požadavku zákazníka vysokou prioritu. Pokud jsou jasně stanoveny požadavky zákazníka s vysokou prioritou, lze tyto komponenty kódu vyvinout a implementovat na první prioritě.
Tím je zajištěno, že šance na konečný produkt odeslaný zákazníkovi jsou podle nejvyšších požadavků a jsou naplánovány.
# 4) Testeři nejprve ověřují nejdůležitější funkčnost implementovanou vývojáři. Jelikož se ověřování (testování) prioritní softwarové komponenty provádí jako první, pomáhá určit, kdy a jestli jsou první verze systému připraveny k vydání.
# 5) Přesné testovací plány, testovací případy se zapisují a provádějí, čímž se ověřuje, že jsou všechny požadavky aplikace implementovány správně. Mapování testovacích případů s požadavky pomáhá zajistit, že nezmeškáte žádné závažné vady. Dále pomáhá při implementaci kvalitního produktu podle očekávání zákazníka.
# 6) V případě, že od klienta existuje požadavek na změnu, všechny komponenty aplikace, které jsou ovlivněny požadavkem na změnu, budou upraveny a nic nebude přehlédnuto. To dále zvyšuje při hodnocení dopadu požadavku na změnu na softwarovou aplikaci.
# 7) Zdánlivě jednoduchý požadavek na změnu může implikovat úpravy, které je třeba provést v několika částech aplikace. Než se dohodnete na provedení změny, je lepší odvodit závěr, kolik úsilí bude zapotřebí.
Výzvy v pokrytí testů
# 1) Dobrý komunikační kanál
Pokud existují nějaké změny, které navrhuje Zúčastněné strany totéž je třeba sdělit vývojovým a testovacím týmům v dřívějších fázích vývoje. Bez toho včas Nelze zajistit vývoj, testování aplikace a zachycení / opravu vad.
# 2) Stanovení priorit testovacích scénářů je důležité
Určit, které jsou vysoce prioritní, složité a důležité testovací scénáře, je obtížný úkol. Pokouším se vyzkoušet všechny Testovací scénáře je téměř nedosažitelný úkol. Cíl testování scénářů musí být velmi jasný z obchodního i koncového hlediska.
# 3) Implementace procesu
Proces testování musí být jasně definován s ohledem na faktory, jako je technická infrastruktura a implementace, dovednosti týmu, minulé zkušenosti, organizační struktury a sledované procesy, odhady projektu týkající se nákladů, času a zdrojů a umístění týmu podle časových pásem.
Jednotná implementace procesu s ohledem na uvedené faktory zajišťuje, že každý jednotlivec, který se projektu týká, je na stejné stránce. To pomáhá v plynulém toku všech procesů souvisejících s vývojem aplikací.
# 4) Dostupnost zdrojů
Zdroje jsou dvou typů: testery specifické pro zkušené domény a testovací nástroje používané testery. Pokud mají testeři správné znalosti domény, mohou psát a implementovat efektivní testovací scénáře a skripty. Pro implementaci těchto scénářů a skriptů by testeři měli být dobře vybaveni příslušnými „Testovacími nástroji“.
Dobrou implementaci a včasné dodání aplikace zákazníkovi může zajistit pouze zkušený tester a příslušné testovací nástroje.
# 5) Efektivní implementace testovací strategie
'' Samotná strategie testování je velkým a samostatným tématem diskuse. Ale zde pro „pokrytí testu“ efektivní implementace testovací strategie zajišťuje, že „ Kvalitní' aplikace je dobrý a to je udržovaný po celou dobu.
Účinná „testovací strategie“ hraje hlavní roli při plánování dopředu pro všechny druhy kritických výzev, což dále pomáhá při vývoji lepší aplikace.
Jak vytvořit matici sledovatelnosti požadavků
Abychom byli s, musíme přesně vědět, co je třeba sledovat nebo sledovat.
Testeři začnou psát své testovací scénáře / cíle a případně testovací případy na základě některých vstupních dokumentů - Dokument obchodních požadavků, Dokument s funkčními specifikacemi a dokument technického designu (volitelný).
Předpokládejme, že toto je náš dokument obchodních požadavků (BRD): ( Stáhněte si tento ukázkový soubor BRD ve formátu aplikace Excel )
(Kliknutím zvětšíte obrázek)
Níže je uveden náš dokument o funkčních specifikacích (FSD) založený na interpretaci dokumentu Business Requirements Document (BRD) a jeho přizpůsobení počítačovým aplikacím. V ideálním případě musí být všechny aspekty FSD řešeny v BRD. Ale pro jednoduchost jsem použil pouze body 1 a 2.
Ukázka FSD z výše BRD: ( Stáhněte si tuto ukázku FSD ve formátu aplikace Excel )
Poznámka : BRD a FSD nejsou dokumentovány týmy QA. Jsme pouhými konzumenty dokumentů spolu s dalšími projektovými týmy.
Na základě výše uvedených dvou vstupních dokumentů jsme jako tým QA přišli s níže uvedeným seznamem scénářů na vysoké úrovni, které bychom měli otestovat.
Ukázkové testovací scénáře z výše uvedených BRD a FSD: ( Stáhněte si tento soubor ukázkových testovacích scénářů )
Jakmile sem dorazíme, nyní by byl vhodný čas začít vytvářet Matici sledovatelnosti požadavků.
Osobně dávám přednost velmi jednoduchému listu aplikace Excel se sloupci pro každý dokument, který chceme sledovat. Jelikož obchodní požadavky a funkční požadavky nejsou očíslovány jednoznačně, použijeme ke sledování čísla sekcí v dokumentu.
(Sledování můžete zvolit na základě čísel řádků nebo čísel s odrážkami atd. V závislosti na tom, co má konkrétně pro váš případ největší smysl.)
Zde je příklad, jak by pro náš příklad vypadala jednoduchá Matice sledovatelnosti:
Výše uvedený dokument zavádí trasování mezi BRD do FSD a případně do testovacích scénářů. Vytvořením takového dokumentu můžeme zajistit, aby testovací tým při vytváření svých testovacích sad zohlednil všechny aspekty počátečních požadavků.
Můžete to nechat tak. Aby však bylo čitelnější, dávám přednost zahrnutí názvů sekcí. To posílí porozumění, když je tento dokument sdílen s klientem nebo jiným týmem.
Výsledek je uveden níže:
Volba použití původního nebo pozdějšího formátu je opět na vás.
Toto je předběžná verze vaší TM, ale obecně zde neslouží svému účelu. Můžete z toho získat maximální výhody, když jej extrapolujete až na závady.
Uvidíme jak.
Pro každý testovací scénář, který jste vymysleli, budete mít alespoň 1 nebo více testovacích případů. Až se tam dostanete, zahrňte další sloupec a napište ID testovacích případů, jak je znázorněno níže:
V této fázi lze k vyhledání mezer použít Matici sledovatelnosti. Například, ve výše uvedené Matici sledovatelnosti vidíte, že pro FSD oddíl 1.2 nejsou napsány žádné testovací případy.
rozdíl mezi stromem b a stromem b
Obecně platí, že jakékoli prázdné mezery v matici sledovatelnosti jsou potenciálními oblastmi pro vyšetřování. Takže taková mezera může znamenat jednu ze dvou věcí:
- Zkušební tým s ohledem na funkcionalitu „Stávající uživatel“ nějak minul.
- Funkce „Existující uživatel“ byla odložena na později nebo odstraněna z požadavků na funkčnost aplikace. V tomto případě TM ukazuje nekonzistenci ve FSD nebo BRD - což znamená, že by měla být provedena aktualizace dokumentů FSD a / nebo BRD.
Pokud se jedná o scénář 1, bude to označovat místa, kde testovací tým musí ještě pracovat, aby zajistil 100% pokrytí.
Ve scénářích 2 TM nejen ukazuje mezery, ale ukazuje na nesprávnou dokumentaci, která vyžaduje okamžitou opravu.
Pojďme nyní rozšířit TM tak, aby zahrnoval stav provádění testů a vady.
Níže uvedená verze Traceability Matrix je obecně připravena během nebo po provedení testu:
Stáhněte si šablonu Matice sledovatelnosti požadavků:
=> Šablona matice sledovatelnosti ve formátu Excel
Důležité poznámky
Níže jsou uvedeny důležité body, které je třeba si o této verzi Matice sledovatelnosti všimnout:
# 1) Zobrazí se také stav provedení. Během provádění poskytuje konsolidovaný snímek o postupu práce.
# 2) Vady: Pokud se tento sloupec použije ke stanovení zpětné sledovatelnosti, zjistíme, že funkce „Nový uživatel“ je nejvíce vadná. Namísto hlášení, že testovací případy selhaly, poskytuje TM transparentnost zpět k obchodnímu požadavku, který má většinu defektů, a tak předvádí kvalitu z hlediska toho, co si klient přeje.
# 3) Jako další krok můžete vybarvit ID defektu tak, aby reprezentovalo jejich stavy. Například, Červené ID vady může znamenat, že je stále otevřené, zelené může znamenat, že je zavřené. Když je to provedeno, TM funguje jako zpráva o kontrole stavu, která zobrazuje stav vad odpovídajících určité funkci BRD nebo FSD, která se právě otevírá nebo zavírá.
# 4) Pokud existuje dokument technického návrhu nebo případy použití nebo jiné artefakty, které chcete sledovat, můžete výše vytvořený dokument kdykoli rozšířit podle svých potřeb přidáním dalších sloupců.
Stručně řečeno, RTM pomáhá v:
- Zajištění 100% pokrytí testu
- Zobrazení nesrovnalostí mezi požadavkem a dokumentem
- Zobrazení celkového stavu vady / provedení se zaměřením na obchodní požadavky.
- Pokud by se měl změnit určitý obchodní nebo funkční požadavek, TM pomůže odhadnout nebo analyzovat dopad na práci týmu QA, pokud jde o revizi / přepracování testovacích případů.
Dodatečně,
- Matice sledovatelnosti není specifickým nástrojem pro ruční testování, lze ji použít také pro automatizační projekty. U projektu Automation může ID testovacího případu označovat název skriptu Automation Test.
- Nejedná se také o nástroj, který by mohly používat pouze QA. Vývojový tým může použít stejné k mapování požadavků BRD / FSD na bloky / jednotky / podmínky vytvořeného kódu, aby se ujistil, že jsou vyvinuty všechny požadavky.
- Nástroje pro správu testů jako HP ALM přicházejí s vestavěnou funkcí sledovatelnosti.
Je důležité si uvědomit, žezpůsob, jakým udržujete a aktualizujete svou sledovatelnost Matrix, určuje účinnost jejího použití. Pokud se neaktualizuje často nebo se aktualizuje nesprávně, nástroj je zátěží místo toho, aby byl nápovědou, a vytváří dojem, že nástroj sám o sobě není hoden použití.
Závěr
Prostředkem je Matice sledovatelnosti požadavků mapa a trasování všechny požadavky klienta s testovacími případy a zjištěnými vadami. Je to jeden dokument který slouží hlavnímu účelu, aby nezmeškal žádné testovací případy, a tak je pokryta a testována každá funkčnost aplikace.
Dobré „pokrytí testu“, které je naplánováno předem, zabraňuje opakujícím se úkolům ve fázích testování a únikům vad. Vysoký počet defektů naznačuje, že testování proběhlo dobře, a proto stoupá „kvalita“ aplikace. Podobně velmi nízký počet defektů naznačuje, že testování neprobíhá až po značku, což negativně ovlivňuje „kvalitu“ aplikace.
Pokud je pokrytí testu provedeno důkladně, lze ospravedlnit nízký počet defektů a tento počet defektů lze považovat za podpůrnou statistiku, nikoli za primární statistiku. Kvalita aplikace se označuje jako „dobrá“ nebo „uspokojivá“, když je pokrytí testu maximalizováno a počet defektů je minimalizován.
O autorovi: Členka týmu STH Urmila P. je zkušená profesionálka QA vysoká kvalita dovednosti v oblasti testování a sledování problémů.
Vytvořili jste ve svých projektech Matici sledovatelnosti požadavků? Jak podobné nebo odlišné je to od toho, co jsme vytvořili v tomto článku? Sdělte nám své zkušenosti, komentáře, myšlenky a zpětnou vazbu k tomuto článku prostřednictvím svých komentářů.
Doporučené čtení
- Ukázková šablona plánu testování softwaru s formátem a obsahem
- Jak napsat efektivní souhrnnou zprávu o testu (Stažení ukázkové zprávy)
- Ukázková šablona testovacího případu s příklady testovacích případů (Stáhnout)
- Ukázková šablona pro protokol o přejímce s příklady
- Jak psát dokument strategie testování (se vzorem šablony strategie testování)
- Jak otestovat specifikaci softwarových požadavků (SRS)?
- Top 20+ nejlepších nástrojů pro správu požadavků (kompletní seznam)
- Kontrolní seznamy pro testování softwaru QA (zahrnuty ukázkové kontrolní seznamy)