how create requirements traceability matrix
Čo je to Požiadavka na sledovateľnosť (RTM) v testovaní softvéru: Podrobný sprievodca vytvorením Matice sledovateľnosti s príkladmi a vzorovou šablónou
Dnešný tutoriál je o dôležitom nástroji QC, ktorý je buď príliš zjednodušený (prehliadané čítaním) alebo príliš zdôraznený - t.j. Sledovateľnosť Matrix (TM).
Tvorba, preskúmanie alebo zdieľanie Matice vysledovateľnosti najčastejšie nie je jedným z primárnych výstupov procesu zabezpečenia kvality - takže sa na ňu príliš nesústredí, čo spôsobuje nedostatočný dôraz. Niektorí klienti naopak očakávajú, že TM odhalí na svojom produkte (v teste) vlastnosti, ktoré otriasajú, a sú sklamaní.
„Pri správnom použití môže byť matica sledovateľnosti vaším GPS pre vašu cestu QA.“
Ako je to v praxi obvyklou praxou STH , v tomto článku uvidíme aspekty „Čo“ a „Ako“ TM.
Čo sa dozviete:
- Aká je matica sledovateľnosti požiadaviek?
- Pokrytie a sledovateľnosť požiadaviek
- Ako vytvoriť maticu sledovateľnosti požiadaviek
Aká je matica sledovateľnosti požiadaviek?
V matici požiadaviek na sledovanie alebo RTM sme nastavili proces dokumentovania väzieb medzi požiadavkami používateľov navrhovanými klientom na budovaný systém. Stručne povedané, je to dokument na vysokej úrovni, ktorý mapuje a sleduje požiadavky používateľov s testovacími prípadmi, aby sa zabezpečilo, že pre každú jednotlivú požiadavku sa dosiahne primeraná úroveň testovania.
Proces kontroly všetkých testovacích prípadov, ktoré sú definované pre každú požiadavku, sa nazýva sledovateľnosť. Vysledovateľnosť nám umožňuje určiť, ktoré požiadavky spôsobili najväčší počet chýb počas procesu testovania.
Zameranie na každú zákazku na testovanie je a malo by byť maximálnym pokrytím testu. Pokrytie to jednoducho znamená, že musíme otestovať všetko, čo má byť testované. Cieľom každého testovacieho projektu by malo byť 100% pokrytie testom.
Matica sledovateľnosti požiadaviek predstavuje spôsob, ako zabezpečiť, aby sme vykonali kontroly aspektu pokrytia. Pomáha pri vytváraní snímky na identifikáciu medzier v pokrytí. Stručne povedané, možno ju tiež označiť ako metriky, ktoré určujú počet spustených, úspešných, zlyhaných alebo blokovaných testovacích prípadov atď. Pre každú požiadavku.
Prečo sa vyžaduje sledovateľnosť požiadaviek?
Matica sledovateľnosti požiadaviek pomáha prepojiť požiadavky, Testovacie prípady a chyby presne. Celá aplikácia je testovaná na základe sledovateľnosti požiadaviek ( Kompletné testovanie aplikácie).
previesť znak na reťazec c ++
Sledovateľnosť požiadavky zaručuje dobrú ‘kvalitu’ aplikácie pri testovaní všetkých funkcií. Kontrola kvality je možné dosiahnuť testovaním softvéru na nepredvídané scenáre s minimálnymi chybami a so splnením všetkých funkčných a nefunkčných požiadaviek.
Matica sledovateľnosti požiadaviek pomáha pri testovaní softvérových aplikácií v stanovenom časovom období, rozsah projektu je dobre určený a jeho implementácia sa dosahuje podľa požiadaviek a potrieb zákazníka a náklady na projekt sú dobre kontrolované.
Predchádza sa tak únikom chýb, pretože celá aplikácia je testovaná na svoje požiadavky.
Typy matice sledovateľnosti
Dohľadateľnosť vpred
V časti „Požiadavky na spätnú vysledovateľnosť“ k testovacím prípadom. Zaisťuje, aby projekt postupoval požadovaným smerom a aby boli všetky požiadavky dôkladne testované.
Spätná sledovateľnosť
Testovacie prípady sú mapované s požiadavkami v časti „Spätná sledovateľnosť“. Jeho hlavným účelom je zabezpečiť, aby bol vyvíjaný produkt na dobrej ceste. Pomáha tiež zistiť, či nie sú pridané žiadne bližšie nešpecifikované funkcie, a tým je ovplyvnený rozsah projektu.
Obousmerná sledovateľnosť
(Dopredu + dozadu): Matica dobrej vysledovateľnosti obsahuje odkazy z testovacích prípadov na požiadavky a naopak (požiadavky na testovacie prípady). Toto sa označuje ako „obojsmerná“ sledovateľnosť. Zaisťuje, že všetky testovacie prípady je možné vysledovať podľa požiadaviek a každá špecifikovaná požiadavka má pre ne presné a platné testovacie prípady.
Príklady RTM
# 1) Obchodné požiadavky
BR1 : Mala by byť k dispozícii možnosť písania e-mailov.
Testovací scenár (technická špecifikácia) pre BR1
TS1 : Je k dispozícii možnosť písania správy.
Testovacie prípady:
Testovací prípad 1 (TS1.TC1) : Je zapnutá možnosť Compose mail a funguje úspešne.
Testovací prípad 2 (TS1.TC2) : Možnosť Napísať správu je vypnutá.
# 2) Poruchy
Po vykonaní testovacích prípadov, ak sa zistia nejaké chyby, ktoré je možné tiež uviesť a zmapovať s obchodnými požiadavkami, testovacie scenáre a testovacie prípady.
Napríklad, Ak TS1.TC1 zlyhá, t. J. Možnosť Vytvoriť poštu, aj keď je povolená, nefunguje správne, je možné zaznamenať chybu. Predpokladajme, že ID chyby je automaticky generované alebo manuálne priradené číslo D01, potom to možno mapovať pomocou čísel BR1, TS1 a TS1.TC1.
Všetky požiadavky môžu byť teda vyjadrené vo formáte tabuľky.
Obchodné požiadavky # | Scenár testu # | Testovacia situácia # | Chyby # |
---|---|---|---|
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 | NIL |
Pokrytie a sledovateľnosť požiadaviek
Čo je pokrytie testom?
Pokrytie testu uvádza, ktoré požiadavky zákazníkov sa majú overiť na začiatku testovacej fázy. Test Coverage je pojem, ktorý určuje, či sú testovacie prípady napísané a vykonané tak, aby sa zabezpečilo úplné otestovanie softvérovej aplikácie takým spôsobom, aby sa hlásili minimálne chyby alebo chyby NIL.
Ako dosiahnuť pokrytie testom?
Maximálne pokrytie skúškou je možné dosiahnuť stanovením dobrej „sledovateľnosti požiadaviek“.
- Mapovanie všetkých vnútorných chýb na navrhnuté testovacie prípady
- Mapovanie všetkých hlásených chýb zákazníka (CRD) na jednotlivé testovacie prípady pre budúcu sadu regresných testov
Typy špecifikácií požiadaviek
# 1) Obchodné požiadavky
Skutočné požiadavky zákazníkov sú uvedené nižšie v dokumente známom ako Dokument obchodných požiadaviek (BRS) . Tento zoznam BRS je podrobne odvodený zoznam požiadaviek na vysokej úrovni po krátkej interakcii s klientom.
Spravidla ju pripravujú „obchodní analytici“ alebo projekt „architekt“ (v závislosti od organizácie alebo štruktúry projektu). Dokument „Technické požiadavky na softvér“ (SRS) je odvodený od BRS.
# 2) Dokument so špecifikáciami softvérových požiadaviek (SRS)
Je to podrobný dokument, ktorý obsahuje všetky podrobné informácie o všetkých funkčných a nefunkčných požiadavkách. Tento SRS je základnou líniou pre navrhovanie a vývoj softvérových aplikácií.
# 3) Dokumenty o požiadavkách na projekt (PRD)
PRD je referenčný dokument pre všetkých členov tímu v projekte, ktorý im presne hovorí, čo by mal produkt robiť. Môže byť rozdelený do častí ako Účel produktu, Vlastnosti produktu, Kritériá vydania a Rozpočet a harmonogram projektu.
# 4) Použite dokument prípadu
Je to dokument, ktorý pomáha pri navrhovaní a implementácii softvéru podľa obchodných potrieb. Mapuje interakcie medzi aktérom a udalosťou s úlohou, ktorú je potrebné vykonať, aby sa dosiahol cieľ. Je to podrobný podrobný popis toho, ako je potrebné vykonať úlohu.
Napríklad,
Herec: Zákazník
Úloha: Stiahnite si hru
Sťahovanie hier je úspešné.
Prípady použitia môžu byť tiež súčasťou dokumentu SRS podľa pracovného procesu organizácie.
# 5) Dokument o overení chyby
Je zdokumentovaný a obsahuje všetky podrobnosti týkajúce sa chýb. Tím môže udržiavať dokument „Overenie chyby“ na opravu a opätovné testovanie chýb. Testéri môžu odporučiť dokument „Overenie chyby“, keď chcú overiť, či sú chyby opravené alebo nie, znova otestovať chyby na inom operačnom systéme, zariadení, inej konfigurácii systému atď.
Dokument „Overenie defektu“ je užitočný a dôležitý, ak existuje špeciálna fáza odstránenia a overenia chyby.
# 6) Príbehy používateľov
Príbeh používateľa sa primárne používa pri vývoji „Agile“ na popis softvérovej funkcie z pohľadu koncového používateľa. Príbehy používateľov definujú typy používateľov, akým spôsobom a prečo chcú určitú funkciu. Požiadavka sa zjednodušuje vytváraním užívateľských príbehov.
V súčasnosti všetky softvérové odvetvia prechádzajú k využívaniu používateľských príbehov a agilného vývoja a zodpovedajúcich softvérových nástrojov na zaznamenávanie požiadaviek.
Výzvy na zber požiadaviek
# 1) Zhromaždené požiadavky musia byť podrobné, jednoznačné, presné a dobre špecifikované. Ale existuje NEROBTE vhodné opatrenie na výpočet týchto detailov, jednoznačnosti, presnosti a presne stanovených špecifikácií, ktoré sú potrebné na zber požiadaviek.
#dva) Výklad „obchodného analytika“ alebo „vlastníka produktu“, ktorý poskytuje informácie o požiadavkách, je zásadný. Podobne aj tím, ktorý prijíma informácie, musí získať príslušné vysvetlenia, aby pochopil očakávania zainteresovaných strán.
Porozumenie musí byť synchronizované s obchodnými potrebami a skutočným úsilím potrebným na implementáciu aplikácie.
# 3) Informácie by mali byť odvodené aj z pohľadu koncového používateľa.
# 4) Štát zainteresovaných strán je v rozporu alebo je v rozpore s požiadavkami v rôznom čase.
# 5) Z mnohých dôvodov sa neprihliada na hľadisko koncového používateľa a ďalšie zainteresované strany si myslia, že „úplne“ rozumejú tomu, čo sa od produktu vyžaduje, čo vo všeobecnosti neplatí.
# 6) Vyvinuli sa zdroje nedostatku zručností pre aplikáciu.
# 7) Časté zmeny rozsahu platnosti „aplikácie“ alebo zmeny priority modulov.
# 8) Zmeškané, implicitné alebo nezdokumentované požiadavky.
# 9) Nekonzistentné alebo neurčité požiadavky určené zákazníkmi.
# 10) Záver všetkých vyššie uvedených faktorov je taký, že „Úspech“ alebo „Zlyhanie“ projektu závisí vo veľkej miere od požiadavky.
Ako môže pomôcť sledovateľnosť požiadaviek
# 1) Kde je implementovaná požiadavka?
Napríklad,
Požiadavka: V poštovej aplikácii implementujte funkciu „Napísať správu“.
Implementácia: Na hlavnej stránke by malo byť umiestnené tlačidlo „Napísať správu“ a malo by k nemu prístup.
# 2) Je požiadavka nevyhnutná?
Napríklad,
Požiadavka: Implementujte funkciu „Vytvoriť poštu“ v poštovej aplikácii iba pre určitých používateľov.
Implementácia: Podľa prístupových práv používateľov je e-mailová schránka „Iba na čítanie“, v takom prípade nebude tlačidlo „Napísať správu“ vyžadované.
# 3) Ako môžem interpretovať požiadavku?
Napríklad,
Požiadavka: Funkcia „vytvárať správy“ v poštovej aplikácii s písmami a prílohami.
Implementácia: Aké všetky funkcie by sa mali poskytovať, keď kliknete na „Napísať správu“
- Text na písanie e-mailov a ich úpravu v rôznych typoch písma a tiež na zvýraznenie tučnou kurzívou
- Typy príloh (obrázky, dokumenty, ďalšie e-maily atď.)
- Veľkosť príloh (maximálna povolená veľkosť)
Požiadavky sa teda členia na čiastkové požiadavky.
najlepšie hodnotený softvér na odstránenie škodlivého softvéru
# 4) Aké rozhodnutia o dizajne ovplyvňujú implementáciu požiadavky?
Napríklad,
Požiadavka: Všetky prvky „Doručená pošta“, „Odoslaná pošta“, „Koncepty“, „Spam“, „Kôš“ atď. By mali byť zreteľne viditeľné.
Implementácia: Prvky, ktoré majú byť viditeľné, by mali byť zobrazené vo formáte „Strom“ alebo „Tab“.
# 5) Sú pridelené všetky požiadavky?
Napríklad,
Požiadavka: K dispozícii je možnosť „Kôš“.
Implementácia: Ak bola poskytnutá možnosť „Kôš“, potom musí byť na začiatku implementovaná možnosť „Odstrániť“ e-maily (požiadavka), ktorá by mala fungovať správne. Ak možnosť „Odstrániť“ poštu funguje správne, do priečinka „Kôš“ sa zhromaždia iba odstránené e-maily a implementácia možnosti „Odpadkový kôš“ (požiadavka) bude mať zmysel (bude užitočné).
Výhody pokrytia RTM a testu
# 1) Vyvinutá a testovaná zostava má požadovanú funkčnosť, ktorá zodpovedá potrebám a očakávaniam „Zákazníci“ / „Používatelia“. Zákazník musí dostať to, čo chce. Prekvapiť zákazníka aplikáciou, ktorá nerobí to, čo sa od nej očakáva, nie je pre nikoho uspokojivou skúsenosťou.
#dva) Konečný produkt (softvérová aplikácia) vyvinutý a dodaný zákazníkovi musí obsahovať iba funkcie, ktoré sú potrebné a očakávané. Špeciálne funkcie poskytované softvérovou aplikáciou sa spočiatku môžu javiť ako atraktívne, kým na ich vývoj nebude čas, peniaze a úsilie.
Táto ďalšia funkcia sa tiež môže stať zdrojom defektov, ktoré môžu zákazníkovi po inštalácii spôsobiť problémy.
# 3) Počiatočná úloha vývojára je jasne definovaná, pretože najskôr pracuje na implementácii požiadaviek, ktoré majú podľa priority zákazníka najvyššiu prioritu. Ak sú jasne špecifikované požiadavky zákazníka s vysokou prioritou, potom môžu byť tieto komponenty kódu vyvinuté a implementované s prvou prioritou.
Takto je zaistené, že šanca na dodanie konečného produktu k zákazníkovi je podľa najvyšších požiadaviek a je naplánovaná.
# 4) Testéri najskôr overia najdôležitejšiu funkcionalitu implementovanú vývojármi. Keď sa najskôr vykoná overenie (testovanie) prioritnej softvérovej súčasti, pomôže to určiť, kedy a či sú pripravené prvé verzie systému na vydanie.
# 5) Presné plány testov. Testovacie prípady sa zapisujú a vykonávajú, čím sa overuje, či sú všetky požiadavky aplikácie implementované správne. Mapovanie testovacích prípadov s požiadavkami pomáha zabezpečiť, aby nezmeškali žiadne závažné chyby. Ďalej pomáha pri implementácii kvalitného produktu podľa očakávaní zákazníka.
# 6) V prípade, že od klienta existuje žiadosť o zmenu, všetky komponenty aplikácie, ktoré sú ovplyvnené požiadavkou na zmenu, sa upravia a nič sa neprehliadne. To ďalej zvyšuje pri hodnotení toho, aký dopad má žiadosť o zmenu na softvérovú aplikáciu.
# 7) Zdanlivo jednoduchá žiadosť o zmenu môže znamenať úpravy, ktoré je potrebné vykonať v niekoľkých častiach aplikácie. Pred prijatím zmeny je lepšie odvodiť záver, koľko úsilia si bude vyžadovať.
Výzvy v pokrytí testu
# 1) Dobrý komunikačný kanál
Ak existujú nejaké zmeny, ktoré navrhuje Zainteresované strany to isté je potrebné oznámiť vývojovým a testovacím tímom v skorších fázach vývoja. Bez toho načas Vývoj, testovanie aplikácie a zachytenie / odstránenie chýb nie je možné zabezpečiť.
# 2) Stanovenie priorít testovacích scenárov je dôležité
Určiť, ktoré sú vysoko prioritné, zložité a dôležité testovacie scenáre, je ťažká úloha. Pokúšam sa vyskúšať všetky možnosti Testovacie scenáre je takmer nedosiahnuteľná úloha. Cieľ testovania scenárov musí byť z obchodného hľadiska a z hľadiska koncového používateľa veľmi jasný.
# 3) Implementácia procesu
Proces testovania musí byť jasne definovaný vzhľadom na faktory ako technická infraštruktúra a implementácie, tímové zručnosti, minulé skúsenosti, organizačné štruktúry a procesy, ktoré sa majú dodržať, odhady projektu týkajúce sa nákladov, času a zdrojov a umiestnenia tímu podľa časových pásiem.
Jednotná implementácia procesu s ohľadom na uvedené faktory zaručuje, že každý jednotlivec, ktorý sa týka projektu, je na rovnakej stránke. To pomáha pri plynulom toku všetkých procesov súvisiacich s vývojom aplikácií.
# 4) Dostupnosť zdrojov
Zdroje sú dvoch typov: testeri špecifickí pre konkrétnu oblasť a testovacie nástroje používané testermi. Ak majú testeri správne znalosti o doméne, môžu písať a implementovať efektívne testovacie scenáre a skripty. Na implementáciu týchto scenárov a skriptov by testéri mali byť vybavení príslušnými „testovacími nástrojmi“.
Kvalitnú implementáciu a včasné dodanie aplikácie zákazníkovi môže zabezpečiť jediný kvalifikovaný tester a príslušné testovacie nástroje.
# 5) Efektívna implementácia stratégie testovania
„ Samotná stratégia testovania je veľkou a samostatnou témou diskusie. Ale tu pre „pokrytie testu“ efektívna implementácia testovacej stratégie zaručuje, že „test Kvalita “ aplikácie je dobre a to je udržiavané za dané časové obdobie všade.
Účinná „testovacia stratégia“ hrá hlavnú úlohu pri plánovaní všetkých druhov kritických výziev, čo ďalej pomáha pri vývoji lepšej aplikácie.
Ako vytvoriť maticu sledovateľnosti požiadaviek
Aby sme boli s nami, musíme presne vedieť, čo je to, čo je potrebné vysledovať alebo vystopovať.
Testéri začnú písať svoje testovacie scenáre / ciele a nakoniec testovacie prípady na základe niektorých vstupných dokumentov - Dokument obchodných požiadaviek, Dokument funkčných špecifikácií a dokument o technickom dizajne (voliteľné).
Predpokladajme, že toto je náš dokument obchodných požiadaviek (BRD): ( Stiahnite si túto ukážku BRD vo formáte programu Excel )
(Kliknite na akýkoľvek obrázok pre zväčšenie)
Ďalej je uvedený náš dokument s funkčnými špecifikáciami (FSD) založený na interpretácii dokumentu s požiadavkami na podnikanie (BRD) a jeho prispôsobení počítačovým aplikáciám. V ideálnom prípade je potrebné zaoberať sa všetkými aspektmi FSD v smernici BRD. Ale pre zjednodušenie som použil iba body 1 a 2.
Ukážka FSD zhora BRD: ( Stiahnite si túto ukážku FSD vo formáte programu Excel )
Poznámka : BRD a FSD nie sú dokumentované tímami QA. Sme iba konzumenti dokumentov a ďalšie projektové tímy.
Na základe vyššie uvedených dvoch vstupných dokumentov sme ako tím QA vytvorili nasledujúci zoznam scenárov na vysokej úrovni, ktoré môžeme otestovať.
Príklady testovacích scenárov z vyššie uvedených BRD a FSD: ( Stiahnite si tento súbor vzorových testovacích scenárov )
Len čo sem dorazíme, teraz by bol vhodný čas na začatie vytvárania Matice sledovateľnosti požiadaviek.
Ja osobne uprednostňujem veľmi jednoduchý hárok programu Excel so stĺpcami pre každý dokument, ktorý chceme sledovať. Pretože obchodné požiadavky a funkčné požiadavky nie sú očíslované jednoznačne, použijeme na sledovanie čísla sekcií v dokumente.
(Sledovanie môžete zvoliť na základe čísel riadkov alebo čísel s odrážkami atď., Podľa toho, čo má pre váš prípad konkrétny najväčší zmysel.)
Takto by vyzerala jednoduchá matica sledovateľnosti pre náš príklad:
apriori algoritmus v dolovani dat s prikladom
Vyššie uvedený dokument ustanovuje trasovanie medzi BRD až FSD a prípadne k testovacím scenárom. Vytvorením takého dokumentu môžeme zaistiť, aby testovací tím pri vytváraní svojich testovacích balíkov zohľadnil všetky aspekty počiatočných požiadaviek.
Môžete to nechať tak. Pre lepšiu čitateľnosť však radšej uvediem názvy sekcií. To zvýši porozumenie, keď je tento dokument zdieľaný s klientom alebo iným tímom.
Výsledok je uvedený nižšie:
Opäť je na vás, či sa rozhodnete použiť pôvodný alebo novší formát.
Toto je predbežná verzia vašej TM, ale všeobecne tu neslúži svojmu účelu, keď sa tu zastavíte. Z nej môžete vyťažiť maximum, keď ju extrapolujete až na chyby.
Pozrime sa ako.
Pre každý testovací scenár, ktorý ste vymysleli, budete mať minimálne 1 alebo viac testovacích prípadov. Keď sa tam dostanete, zahrňte ďalší stĺpec a napíšte ID testovacích prípadov, ako je uvedené nižšie:
V tejto fáze je možné na nájdenie medzier použiť maticu sledovateľnosti. Napríklad, vo vyššie uvedenej matici vysledovateľnosti vidíte, že pre FSD oddiel 1.2 nie sú napísané žiadne testovacie prípady.
Spravidla sú všetky prázdne miesta v matici vysledovateľnosti potenciálnymi oblasťami na skúmanie. Takže medzera ako táto môže znamenať jednu z dvoch vecí:
- Testovací tím akosi neprišiel o funkčnosť „Existujúci používateľ“.
- Funkcia „Existujúci používateľ“ bola odložená na neskôr alebo odstránená z požiadaviek na funkčnosť aplikácie. V tomto prípade TM ukazuje nekonzistenciu vo FSD alebo BRD - čo znamená, že by sa mala vykonať aktualizácia dokumentov FSD a / alebo BRD.
Ak je to scenár 1, bude to označovať miesta, kde testovací tím musí ešte pracovať, aby zabezpečil 100% pokrytie.
V scenároch 2 TM nielen ukazuje medzery, ale ukazuje aj na nesprávnu dokumentáciu, ktorú je potrebné okamžite opraviť.
Poďme teraz rozšíriť TM o stav vykonania testovacieho prípadu a chyby.
Nasledujúca verzia matice vysledovateľnosti je všeobecne pripravená počas alebo po vykonaní testu:
Stiahnite si šablónu Matice sledovateľnosti požiadaviek:
=> Šablóna sledovateľnosti matice vo formáte Excel
Dôležité poznámky
Nasledujú dôležité body, ktoré je potrebné si uvedomiť o tejto verzii Matice sledovateľnosti:
# 1) Zobrazí sa tiež stav vykonania. Počas vykonávania poskytuje konsolidovaný prehľad o postupe prác.
# 2) Vady: Ak sa tento stĺpec použije na stanovenie spätnej vysledovateľnosti, môžeme povedať, že funkcia „Nový používateľ“ je najviac chybná. Namiesto hlásenia, že testovacie prípady zlyhali, TM poskytuje transparentnosť späť k obchodným požiadavkám, ktoré majú väčšinu nedostatkov, a tak vyjadrujú kvalitu v zmysle toho, čo si klient želá.
# 3) Ako ďalší krok môžete vyfarbiť ID chyby tak, aby reprezentovala ich stavy. Napríklad, ID chyby červenou farbou môže znamenať, že je stále otvorené, zelenou farbou môže byť zatvorené. Keď je to hotové, TM funguje ako správa o kontrole stavu, ktorá zobrazuje stav chýb zodpovedajúcich určitej funkcii BRD alebo FSD, ktorá sa práve otvára alebo zatvára.
# 4) Ak existuje dokument o technickom dizajne alebo prípady použitia alebo akékoľvek iné artefakty, ktoré by ste chceli sledovať, môžete kedykoľvek vyššie vytvorený dokument rozšíriť tak, aby vyhovoval vašim potrebám, pridaním ďalších stĺpcov.
Stručne povedané, RTM pomáha pri:
- Zaistenie 100% pokrytia testu
- Zobrazenie nezrovnalostí medzi požiadavkami a dokumentmi
- Zobrazenie celkového stavu Poruchy / Vykonania so zameraním na Obchodné požiadavky.
- Ak by sa mala zmeniť určitá obchodná a / alebo funkčná požiadavka, TM pomáha odhadnúť alebo analyzovať vplyv na prácu tímu QA z hľadiska prehodnotenia / prepracovania testovacích prípadov.
Navyše,
- Matica sledovateľnosti nie je špecifickým nástrojom na ručné testovanie, dá sa použiť aj pre automatizačné projekty. V prípade automatizačného projektu môže ID testovacieho prípadu označovať názov skriptu automatizačného testu.
- Tiež to nie je nástroj, ktorý môžu používať iba kontroly kvality. Vývojový tím môže použiť to isté na mapovanie požiadaviek BRD / FSD na bloky / jednotky / podmienky vytvoreného kódu, aby sa ubezpečil, že sú vyvinuté všetky požiadavky.
- Nástroje na správu testov ako HP ALM prísť s vstavanou funkciou sledovateľnosti.
Je dôležité si uvedomiť, žespôsob, akým udržiavate a aktualizujete svoju Maticu vysledovateľnosti, určuje účinnosť jej použitia. Ak sa neaktualizuje často alebo sa neaktualizuje nesprávne, je nástrojom namiesto pomoci a vytvára dojem, že samotný nástroj nie je hodný použitia.
Záver
Matica sledovateľnosti požiadaviek je prostriedok, ktorým sa dá dosiahnuť mapa a sledovanie všetky požiadavky klienta s testovacími prípadmi a zistenými chybami. Je to jediný dokument ktorý slúži hlavnému účelu, aby nezmeškali žiadne testovacie prípady, a tak je pokrytá a testovaná každá funkčnosť aplikácie.
Dobré „pokrytie testu“, ktoré je naplánované vopred, zabráni opakujúcim sa úlohám vo fázach testovania a únikom chýb. Vysoký počet defektov naznačuje, že testovanie prebieha dobre, a preto stúpa „kvalita“ aplikácie. Rovnako veľmi nízky počet defektov naznačuje, že testovanie sa nevykonáva až po značku, čo negatívne ovplyvňuje „kvalitu“ aplikácie.
Ak sa pokrytie testu vykoná dôkladne, je možné odôvodniť nízky počet defektov a tento počet defektov možno považovať za podpornú štatistiku, a nie za primárnu štatistiku. Kvalita aplikácie sa označuje ako „dobrá“ alebo „uspokojivá“, keď je pokrytie testu maximalizované a počet chýb je minimalizovaný.
O autorovi: Členka tímu STH Urmila P. je skúsená profesionálka QA vysoká kvalita zručnosti v oblasti testovania a sledovania problémov.
Vytvorili ste vo svojich projektoch Maticu sledovateľnosti požiadaviek? Aké podobné alebo odlišné je to od toho, čo sme vytvorili v tomto článku? Zdieľajte svoje skúsenosti, komentáre, myšlienky a spätnú väzbu k tomuto článku prostredníctvom svojich komentárov.
Odporúčané čítanie
- Ukážka šablóny plánu testovania softvéru s formátom a obsahom
- Ako napísať efektívnu súhrnnú správu o teste [stiahnutie vzorovej správy]
- Ukážka šablóny testovacieho prípadu s príkladmi testovacích prípadov [Stiahnuť]
- Vzorová šablóna pre správu o prevzatí s príkladmi
- Ako napísať dokument stratégie testovania (so vzorovou šablónou stratégie testovania)
- Ako otestovať špecifikáciu softvérových požiadaviek (SRS)?
- Top 20+ najlepších nástrojov na správu požiadaviek (kompletný zoznam)
- Kontrolné zoznamy na testovanie softvéru QA (súčasťou sú vzorové kontrolné zoznamy)