Hvad er kravsporbarhedsmatrix (RTM)? Eksempel skabelon

Hvad er sporbarhedsmatrix? (TM)

En sporbarhedsmatrix er et dokument, der sammenrelaterer alle to-baseline-dokumenter, der kræver mange-til-mange-forhold for at kontrollere fuldstændigheden af forholdet.

Det bruges til at spore kravene og til at kontrollere de aktuelle projektkrav er opfyldt.

Hvad er kravsporbarhedsmatrix?

Kravsporbarhedsmatrix (RTM) er et dokument, der kortlægger og sporer brugerbehov med testtilfælde. Den registrerer alle krav, der er foreslået af klienten, og sporbarhed af krav i et enkelt dokument, leveret ved afslutningen af softwareudviklingens livscyklus. Hovedformålet med kravsporbarhedsmatrix er at validere, at alle krav kontrolleres via testtilfælde, så der ikke er markeret nogen funktionalitet under softwaretest.

I denne vejledning lærer du mere om-

Hvorfor er RTM vigtigt?
Hvilke parametre skal inkluderes i kravsporbarhedsmatrix?
Typer af sporbarhedstestmatrix
Sådan oprettes kravsporbarhedsmatrix
Fordel ved kravsporbarhedsmatrix
Krav RTM-skabelon (sporbarhedsmatrix)

Hvorfor er RTM vigtigt?

Hoveddagsordenen for hver tester skal være at forstå kundens krav og sørge for, at outputproduktet skal være fejlfrit. For at nå dette mål bør hver kvalitetssikring forstå kravet grundigt og skabe positive og negative testtilfælde.

Dette vil betyde, at softwarekravene, der leveres af klienten, skal opdeles yderligere i forskellige scenarier og yderligere for at teste sager. Hver af denne sag skal udføres individuelt.

Her opstår et spørgsmål om, hvordan man kan sikre, at kravet testes i betragtning af alle mulige scenarier / tilfælde? Hvordan kan man sikre, at ethvert krav ikke udelades af testcyklussen?

En enkel måde er at spore kravet med dets tilsvarende testscenarier og testcases. Dette betegnes blot som 'Kravssporbarhedsmatrix.'

Sporbarhedsmatrixen er typisk et regneark, der indeholder kravene med alle mulige testscenarier og sager og deres aktuelle tilstand, dvs. hvis de er bestået eller mislykkedes. Dette vil hjælpe testteamet med at forstå niveauet af testaktiviteter, der er udført for det specifikke produkt.

Hvilke parametre skal inkluderes i kravsporbarhedsmatrix?

Krav-ID
Kravstype og beskrivelse
Test sager med status

Ovenfor er en prøvekrav sporbarhedsmatrix.

Men i et typisk softwaretestprojekt ville sporbarhedsmatrixen have mere end disse parametre.

Som illustreret ovenfor kan en kravsporbarhedsmatrix:

Vis kravdækningen i antallet af testsager
Designstatus samt eksekveringsstatus for den specifikke testsag
Hvis der er brugertest, der skal udføres af brugerne, kan UAT-status også registreres i den samme matrix.
De relaterede fejl og den aktuelle tilstand kan også nævnes i den samme matrix.

Denne form for matrix giver One Stop Shop til alle testaktiviteter.

Bortset fra at opretholde et excel separat. Et testteam kan også vælge krav, der sporer tilgængelige teststyringsværktøjer.

Typer af sporbarhedstestmatrix

I Software Engineering kan sporbarhedsmatrix opdeles i tre hovedkomponenter som nævnt nedenfor:

Sporbarhed fremad : Denne matrix bruges til at kontrollere, om projektet skrider frem i den ønskede retning og for det rigtige produkt. Den sørger for, at hvert krav anvendes på produktet, og at hvert krav testes grundigt. Det kortlægger krav for at teste sager.
Sporbarhed baglæns eller omvendt: Det bruges til at sikre, om det aktuelle produkt forbliver på rette spor. Formålet med denne type sporbarhed er at kontrollere, at vi ikke udvider projektets omfang ved at tilføje kode, designelementer, test eller andet arbejde, der ikke er specificeret i kravene. Det kortlægger testcases til kravene.
Tovejs sporbarhed (fremad + bagud): Denne sporbarhedsmatrix sikrer, at alle krav er dækket af testtilfælde. Den analyserer virkningen af en ændring i krav, der er påvirket af fejlen i et arbejdsprodukt og omvendt.

Sådan oprettes kravsporbarhedsmatrix

Lad os forstå konceptet med kravsporbarhedsmatrix gennem et Guru99-bankprojekt.

På baggrund af Business Requirement Document (BRD) og Technical Requirement Document (TRD) begynder testere at skrive testcases.

Lad os antage, at følgende tabel er vores forretningskravsdokument eller BRD til Guru99-bankprojekt .

Her er scenariet, at kunden skal være i stand til at logge ind på Guru99 bankwebsite med den korrekte adgangskode og bruger # id, mens manager skal være i stand til at logge ind på hjemmesiden via kundens login-side.

Mens nedenstående tabel er vores tekniske kravdokument (TRD) .

Bemærk: QA-hold dokumenterer ikke BRD og TRD. Nogle virksomheder bruger også Function Requirement Documents (FRD), der ligner Technical Requirement Document, men processen med at oprette sporbarhedsmatrix forbliver den samme.

Lad os gå fremad og oprette RTM i test

Trin 1: Vores prøveeksempel er

"Bekræft login, når korrekt ID og adgangskode er indtastet, skal det logge ind med succes"

Trin 2 : Identificer det tekniske krav, som dette test tilfælde bekræfter. I vores testsag er det tekniske krav, at T94 verificeres.

Trin 3: Bemærk dette tekniske krav (T94) i testkassen.

Trin 4: Identificer det forretningskrav, som denne TR (teknisk krav-T94) er defineret for

Trin 5: Bemærk BR (forretningskrav) i test sag

Trin 6: Gør ovenstående for alle testsager. Senere udtrække de første 3 kolonner fra din Test Suite. RTM i test er klar!

Fordel ved kravsporbarhedsmatrix

Det bekræfter 100% testdækning
Det fremhæver manglende krav eller inkonsekvenser i dokumenter
Det viser de overordnede mangler eller udførelsesstatus med fokus på forretningskrav
Det hjælper med at analysere eller estimere indvirkningen på QA-teamets arbejde med hensyn til at revidere eller genanvende testsagerne