Hvad er Requirements Traceability Matrix (RTM) i test?

Af: Thomas Hamilton Thomas Hamilton
Hours Opdateret

⚡ Smart opsummering

Kravsporbarhedsmatrixen (RTM) er et struktureret dokument, der forbinder projektkrav med deres tilsvarende testcases, hvilket sikrer fuld dækning og validering. Den spiller en afgørende rolle i softwaretest ved at forhindre oversete funktionaliteter, understøtte compliance og give synlighed på tværs af interessenter.

  • Start RTM tidligt i projektets livscyklus for at sikre fuldstændig overensstemmelse med kravene.
  • Hold matricen opdateret, når krav eller testcases ændrer sig.
  • Brug klare, unikke ID'er til effektivt at kortlægge krav, scenarier og testcases.
  • Samarbejd på tværs af testere, udviklere, analytikere og ledere for at sikre fælles ansvarlighed.
  • Udnyt automatiseringsværktøjer (f.eks. Jira, Zephyr) til at reducere manuel indsats og forbedre skalerbarheden.
Læs mere

Sporbarhedsmatrix (RTM)

Hvad er Traceability Matrix (TM)?

En sporbarhedsmatrix er et dokument, der korrelerer to basisdokumenter, der kræver en mange-til-mange-relation for at kontrollere relationens fuldstændighed.

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

👉 Tilmeld dig et gratis live softwaretestprojekt

Hvad er en kravsporbarhedsmatrix?

En kravsporbarhedsmatrix (RTM) er et dokument, der kortlægger og sporer brugerkrav med testcases. Det indfanger alle krav, som klienten har foreslået, og sporbarheden af ​​kravene i et enkelt dokument, der leveres ved afslutningen af Softwareudviklings livscyklusHovedformålet med kravsporbarhedsmatricen er at validere, at alle krav er kontrolleret via testcases, således at ingen funktionalitet er ukontrolleret under softwaretestning.

Hvorfor er RTM vigtigt?

Hovedmålet for enhver tester bør være at forstå kundens krav og sikre, at resultatet er fejlfrit. For at nå dette mål bør enhver kvalitetssikringsmedarbejder forstå kravet grundigt og oprette positive og negative testcases.

Dette ville betyde, at de softwarekrav, som klienten stiller, skal opdeles yderligere i forskellige scenarier og yderligere i testcases. Hvert af disse cases skal udføres individuelt.

Her opstår et spørgsmål om, hvordan man sikrer, at kravet testes, idet alle mulige scenarier/tilfælde tages i betragtning? Hvordan man sikrer, at intet krav udelades af testcyklussen?

En enkel måde er at spore kravet med dets tilsvarende testscenarier og test tilfældeDette kaldes en 'kravsporbarhedsmatrix'.

Sporbarhedsmatricen er typisk et regneark, der indeholder kravene med alle mulige test scenarier og cases og deres nuværende status, dvs. om de er blevet bestået eller ikke bestået. Dette ville hjælpe testteamet med at forstå niveauet af testaktiviteter, der er udført for det specifikke produkt.

Hvem har brug for RTM?

A Requirements Traceability Matrix (RTM) er ikke kun for testere – det er værdifuldt for alle, der er involveret i at levere software eller projekter af høj kvalitet.

  • QA og testere → Sikr 100% kravdækning med veldefinerede testcases.
  • Forretningsanalytikere → Spor krav fra SRS/brugerhistorier gennem hele eksekveringen.
  • Projektledere → Få indsigt i omfang, fremskridt og manglende opfyldelse af krav.
  • Udviklere → Forstå, hvordan funktioner relaterer sig til forretningsmål.
  • Regulerede industrier (Sundhedsvæsen, bilindustrien, luftfart, finans) → Bevis overholdelse af regler og bestå revisioner med tydelig sporbarhed.
  • Klienter og interessenter → Få sikkerhed for, at deres krav er implementeret og testet.

👉 Kort sagt, enhver der er ansvarlig for opbygning, validering eller godkendelse af softwarekrav fordele ved RTM.

Hvilke parametre skal inkluderes i kravsporbarhedsmatricen?

  • Krav ID
  • Krav Type og Description
  • Testsager med status

Krav Sporbarhedsmatrix

Ovenfor er en prøvekravs-sporbarhedsmatrix.

Men i en typisk software test projekt, ville sporbarhedsmatricen have mere end disse parametre.

Krav Sporbarhedsmatrix

Som illustreret ovenfor kan en kravsporbarhedsmatrix:

  • Vis kravdækningen i antallet af testcases
  • Designstatus samt udførelsesstatus for den konkrete testcase
  • Hvis der er brugeracceptanstests, der skal udføres af brugerne, kan UAT-statussen også registreres i den samme matrix.
  • De relaterede defekter og den aktuelle tilstand kan også nævnes i samme matrix.

Denne type matrix ville give One-stop-butik til alle testaktiviteter.

Udover at vedligeholde et separat Excel-dokument, kan et testteam også vælge kravsporing, der er tilgængelig i Test Management Tools.

Typer af sporbarhedstestmatrix

Inden for softwareudvikling kan en 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 er påført produktet, og at hvert krav bliver testet grundigt. Den kortlægger krav til testcases.
  • Sporbarhed bagud eller omvendt: Det bruges til at sikre, at det nuværende produkt forbliver på rette spor. Formålet med denne type sporbarhed er at verificere, at vi ikke udvider projektets omfang ved at tilføje kode, designelementer, test eller andet arbejde, der ikke er specificeret i kravene. Det knytter testcases til krav.
  • Tovejs sporbarhed (fremad+bagud): Denne sporbarhedsmatrix sikrer, at testcases dækker alle krav. Den analyserer virkningen af ​​en ændring i krav, der påvirkes af Defekt i et arbejdsprodukt og omvendt.

RELATEREDE ARTIKLER

Sådan opretter du en kravsporbarhedsmatrix

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

På grundlag af Business Requirement Document (BRD) og Teknisk kravdokument (TRD), begynder testere at skrive testcases.

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

Her er scenariet, at kunden skal kunne logge ind på Guru99 bankwebstedet med den korrekte adgangskode og brugernummer, mens administratoren skal kunne logge ind på webstedet via kundens loginside.

Sådan opretter du kravsporbarhedsmatrix (RTM)

Tabellen nedenfor er vores Teknisk kravdokument (TRD).

Sådan opretter du kravsporbarhedsmatrix (RTM)

Bemærk: QA-hold dokumenterer ikke BRD og TRD. Også nogle virksomheder bruger Funktionskravsdokumenter (FRD), som ligner tekniske kravdokumenter, men processen med at oprette en sporbarhedsmatrix forbliver den samme.

Lad os gå videre og oprette RTM i test

Trin 1) Vores prøve Test Case is

"Bekræft login: Når det korrekte ID og den korrekte adgangskode er indtastet, burde den logge ind korrekt."

Sådan opretter du kravsporbarhedsmatrix (RTM)

Trin 2) Identificer det tekniske krav, som denne testcase verificerer. I vores testcase verificeres det tekniske krav T94.

Sådan opretter du kravsporbarhedsmatrix (RTM)

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

Sådan opretter du kravsporbarhedsmatrix (RTM)

Trin 4) Identificer det forretningskrav, som dette TR (Technical Requirement-T94) er defineret for

Sådan opretter du kravsporbarhedsmatrix (RTM)

Trin 5) Bemærk BR (forretningskravet) i testcasen

Sådan opretter du kravsporbarhedsmatrix (RTM)

Trin 6) Gør ovenstående for alle testcases. LaterUdpak de første 3 kolonner fra din testsuite. RTM i test er klar!

Sådan opretter du kravsporbarhedsmatrix (RTM)

Fordele ved kravsporbarhedsmatrixen

  • Det bekræfter 100% testdækning
  • Det fremhæver eventuelle manglende krav eller dokumenterer uoverensstemmelser
  • Den viser de overordnede mangler eller udførelsesstatus med fokus på forretningskrav
  • Det hjælper med at analysere eller estimere effekten på QA-teamets arbejde med hensyn til at gennemgå eller omarbejde testcases.

De bedste fremgangsmåder og tips til brug af RTM

En kravsporbarhedsmatrix (RTM) er mest effektiv, når den er holdes enkel, konsistent og opdateres regelmæssigtHer er de bedste fremgangsmåder, der vil give teams mulighed for at sikre fuld dækning, minimalt omarbejde og forbedret tillid til projektlevering:

  • Start tidligt → Opret din RTM helt i starten af ​​projektet.
  • Hold det opdateret → Opdater matricen, når krav eller testcases ændres.
  • Brug klare ID'er → Tildel unikke ID'er til krav og testcases for nem sporbarhed.
  • Dæk positive og negative sager → Sørg for, at alle krav valideres fra flere testvinkler.
  • Samarbejd på tværs af teams → Involver testere, udviklere, business advisors og projektledere i vedligeholdelsen af ​​RTM.
  • Udnyt værktøjer → Overvej teststyringsværktøjer (som Jira, HP ALM eller Zephyr) i stedet for regneark for at opnå skalerbarhed.
  • Version Control → Gem historiske versioner for at spore ændringer og opretholde overholdelse af regler.
  • Fokus på enkelhed → Undgå at overbelaste matricen; fremhæv kun de vigtigste parametre.
  • Revision regelmæssigt → Gennemgå periodisk RTM for at opdage mangler inden testfrister.
  • Link til forretningsværdi → Kortlæg krav tilbage til forretningsmål for at vise ROI.

Almindelige RTM-udfordringer og løsninger

  1. Udfordring: At holde RTM opdateret
    Krav og testcases ændrer sig ofte, hvilket gør RTM hurtigt forældet.
    Opløsning: Brug automatiserede teststyringsværktøjer, der synkroniserer krav, testcases og defekter i realtid.
  2. Udfordring: Overdreven kompleksitet
    At tilføje for mange parametre gør det vanskeligt at vedligeholde og fortolke RTM.
    Opløsning: Hold RTM slank ved kun at fokusere på essentielle felter såsom ID'er, beskrivelser og status.
  3. Udfordring: Dårligt teamsamarbejde
    Forskellige teams er muligvis ikke enige om ejerskab eller opdateringer.
    Opløsning: Definer klare roller, involver testere, udviklere og analytikere, og planlæg regelmæssige RTM-gennemgange.
  4. Udfordring: Ufuldstændig kravdækning
    Nogle krav kan mangle testcases, hvilket kan føre til manglende funktionalitet.
    Opløsning: Valider dækningen regelmæssigt, brug tovejs sporbarhed, og udfør revisioner før større udgivelser.
  5. Udfordring: Manuel indsats i store projekter
    Det bliver tidskrævende at administrere RTM i regneark for komplekse systemer.
    Opløsning: Brug RTM-værktøjer som Jira, HP ALM eller Zephyr til at automatisere kortlægning og rapportering.

Lad os lære RTM med et eksempel i videoen

Klik link. hvis videoen ikke er tilgængelig

Krav Sporbarhed Matrix (RTM) skabelon

Klik nedenfor for at downloade RTM-skabelonen i Excel-filen

Download RTM-skabelonen Excel(.xlsx)

Ofte stillede spørgsmål:

En RTM bruges til at sikre, at alle projektkrav er knyttet til tilsvarende testcases. Den hjælper med at verificere fuld dækning, spore ændringer, reducere defekter og give bevis for validering. Ved at knytte krav til tests forbedrer RTM kvalitetssikring, compliance og interessenternes tillid i hele udviklingscyklussen.

Der er tre hovedtyper af RTM: Sporbarhed fremad (kortlægger krav til testcases), Sporbarhed bagud (knytter testcases tilbage til krav), og Tovejs sporbarhed (kombinerer begge retninger). Sammen sikrer disse tilgange fuldstændig dækning, forhindrer unødvendig udvidelse af omfanget og validerer, at alle krav er grundigt testet.

Kravsporbarhedsmatricen udarbejdes typisk tidligt i projektet, når kravene er dokumenteret i SRS, BRD eller backloggen. Den udvikler sig gennem hele livscyklussen og opdateres, når krav eller testcases ændrer sig. Tidlig forberedelse af RTM sikrer tilpasning, minimerer manglende funktionalitet og understøtter effektiv testplanlægning og dækningsanalyse.

Det primære ansvar for at vedligeholde et RTM ligger normalt hos QA team or testere. Imidlertid forretningsanalytikere definere krav, udviklere link kode til disse krav, og projektledere overvåge nøjagtighed. I praksis er RTM et fælles ansvar på tværs af teams, hvilket sikrer, at krav spores og valideres i alle faser.

For at bruge en RTM skal du liste projektkravene sammen med deres tilsvarende testcases. Spor udførelsesstatus, defekter og dækning. Teams bruger den til at verificere, at kravene testes, identificere mangler og vurdere virkningerne af ændringer. Den bliver et levende dokument, der giver synlighed og kontrol gennem hele test- og projektlivscyklussen.

Ja, RTM bruges i vid udstrækning i agile projekter. I stedet for formelle SRS-dokumenter kommer krav ofte fra brugerhistorier or produktefterslæbAgile teams knytter disse historier til testcases i RTM'en og sikrer, at hver historie valideres. Den tilpasser sig godt til Agiles iterative natur, samtidig med at den opretholder fuld dækning.

Ja, RTM kan automatiseres ved hjælp af teststyringsværktøjer som f. Jira, HP ALM eller ZephyrAutomatisering reducerer manuel indsats, sikrer opdateringer i realtid og giver bedre sporbarhed på tværs af krav, testcases og defekter. Automatiserede RTM'er er især nyttige i store eller regulerede projekter, hvor compliance og revisionsberedskab er afgørende.

RTM og RACI tjener forskellige formål. RTM sporer krav og testsager for at sikre dækning og validering. RACI er en ansvarsfordelingsmatrix, der viser, hvem der er ansvarlig, ansvarlig, konsulteret og informeret i et projekt. RTM fokuserer på krav og test, mens RACI præciserer teamroller og ansvar.

Opsummer dette indlæg med: