Hvem er ansvarlig for sporbarhetsmatrisen for krav?

Hovedansvaret for å vedlikeholde en RTM ligger vanligvis hos QA-teamet eller testerne. Forretningsanalytikere definerer imidlertid krav, utviklere kobler kode til disse kravene, og prosjektledere fører tilsyn med nøyaktigheten. I praksis er RTM et delt ansvar på tvers av teamene, som sikrer at krav spores og valideres i hvert trinn.

Hva er Requirements Traceability Matrix (RTM) i testing?

⚡ Smart oppsummering

The Requirements Traceability Matrix (RTM) is a structured document that links project requirements to their corresponding test cases, ensuring full coverage and validation. It plays a critical role in software testing by preventing missed functionalities, supporting compliance, and providing visibility across stakeholders.

Start RTM tidlig i prosjektets livssyklus for å sikre fullstendig samsvar med krav.
Hold matrisen oppdatert når krav eller testtilfeller endres.
Bruk tydelige, unike ID-er for å kartlegge krav, scenarioer og testtilfeller effektivt.
Samarbeid på tvers av testere, utviklere, analytikere og ledere for delt ansvarlighet.
Utnytt automatiseringsverktøy (f.eks. Jira, Zephyr) for å redusere manuell innsats og forbedre skalerbarheten.

Les mer

Hva er sporbarhetsmatrise (TM)?

En sporbarhetsmatrise er et dokument som korrelerer to grunnleggende dokumenter som krever en mange-til-mange-relasjon for å kontrollere fullstendigheten av forholdet.

Den brukes til å spore kravene og sjekke om de gjeldende prosjektkravene er oppfylt.

Hva er en sporbarhetsmatrise for krav?

En kravsporbarhetsmatrise (RTM) er et dokument som kartlegger og sporer brukerkrav med testtilfeller. Det samler alle krav foreslått av klienten og sporbarhet av krav i ett enkelt dokument, levert ved avslutningen av Programvareutvikling livssyklusHovedformålet med kravsporbarhetsmatrisen er å validere at alle krav er kontrollert via testtilfeller, slik at ingen funksjonalitet er ukontrollert under programvaretesting.

Hvorfor er RTM viktig?

Hovedagendaen til enhver tester bør være å forstå kundens krav og sørge for at resultatet er feilfritt. For å oppnå dette målet bør enhver kvalitetssikringsansvarlig forstå kravet grundig og lage positive og negative testtilfeller.

Dette ville bety at programvarekravene som klienten stiller må deles opp i ulike scenarioer og testtilfeller. Hvert av disse tilfellene må utføres individuelt.

Her oppstår et spørsmål om hvordan man kan sørge for at kravet testes, med tanke på alle mulige scenarioer/tilfeller? Hvordan sikre at ingen krav utelates fra testsyklusen?

En enkel måte er å spore kravet med tilhørende testscenarier og test tilfellerDette kalles en «kravsporbarhetsmatrise».

Sporbarhetsmatrisen er vanligvis et regneark som inneholder kravene med alle mulige test scenarier og saker og deres nåværende status, dvs. om de har blitt bestått eller ikke bestått. Dette vil hjelpe testteamet med å forstå nivået av testaktiviteter som er utført for det spesifikke produktet.

Hvem trenger RTM?

A Krav Sporbarhetsmatrise (RTM) er ikke bare for testere – det er verdifullt for alle som er involvert i å levere programvare eller prosjekter av høy kvalitet.

QA og testere → Sørg for 100 % kravdekning med godt kartlagte testtilfeller.
Forretningsanalytikere → Spor krav fra SRS/brukerhistorier gjennom hele utførelsesprosessen.
Prosjektledere → Få innsikt i omfang, fremdrift og manglende oppfylte krav.
Utviklere → Forstå hvordan funksjoner samsvarer med forretningsmål.
Regulert industri (Helsevesen, bilindustri, luftfart, finans) → Bevis samsvar og bestå revisjoner med tydelig sporbarhet.
Klienter og interessenter → Få bekreftelse på at kravene deres er implementert og testet.

👉 Kort sagt, alle som er ansvarlige for bygge, validere eller godkjenne programvarekrav fordeler med RTM.

Hvilke parametere skal inkluderes i kravsporbarhetsmatrisen?

Krav-ID
Krav Type og Description
Testtilfeller med status

Ovenfor er en prøvematrise for kravsporbarhet.

Men i en typisk programvaretesting prosjekt, vil sporbarhetsmatrisen ha mer enn disse parameterne.

Som illustrert ovenfor kan en kravsporbarhetsmatrise:

Vis kravdekningen i antall testtilfeller
Designstatus samt utførelsesstatus for den spesifikke testcase
Hvis det er noen brukeraksepttester som skal utføres av brukerne, kan UAT-statusen også registreres i samme matrise.
De relaterte defektene og den nåværende tilstanden kan også nevnes i samme matrise.

Denne typen matrise ville gi One-Stop Shop for alle testaktiviteter.

I tillegg til å vedlikeholde en separat Excel-fil, kan et testteam også velge kravsporing som er tilgjengelig i teststyringsverktøy.

Typer sporbarhetstestmatrise

Innen programvareutvikling kan en sporbarhetsmatrise deles inn i tre hovedkomponenter som nevnt nedenfor:

Sporbarhet fremover: Denne matrisen brukes til å sjekke om prosjektet går i ønsket retning og for riktig produkt. Den sørger for at hvert krav blir brukt på produktet og at hvert krav blir testet grundig. Den kartlegger krav til testtilfeller.
Sporbarhet bakover eller bakover: Den brukes til å sikre at det nåværende produktet forblir på rett spor. Formålet med denne typen sporbarhet er å bekrefte at vi ikke utvider prosjektets omfang ved å legge til kode, designelementer, test eller annet arbeid som ikke er spesifisert i kravene. Den knytter testtilfeller til krav.
Toveis sporbarhet (forover+bakover): Denne sporbarhetsmatrisen sikrer at testtilfeller dekker alle krav. Den analyserer virkningen av en endring i krav som påvirkes av Defekt i et arbeidsprodukt og omvendt.

Slik lager du en sporbarhetsmatrise for krav

La oss forstå konseptet med kravsporbarhetsmatrise gjennom et Guru99-bankprosjekt.

På grunnlag av Business Requirement Document (BRD) og Teknisk kravdokument (TRD), testere begynner å skrive testsaker.

La oss anta at følgende tabell er vårt forretningskravdokument eller BRD for Guru99 bankprosjekt.

Her er scenariet at kunden skal kunne logge inn på Guru99s banknettsted med riktig passord og bruker-ID, mens banksjefen skal kunne logge inn på nettstedet via kundens innloggingsside.

Tabellen nedenfor er vår Teknisk kravdokument (TRD).

OBS: QA-team dokumenterer ikke BRD og TRD. Noen selskaper bruker også Dokumenter for funksjonskrav (FRD), som ligner på tekniske kravdokumenter, men prosessen med å lage en sporbarhetsmatrise forblir den samme.

La oss gå videre og lage RTM i testing

Trinn 1) Våre eksempel Test Case is

«Bekreft pålogging: Når riktig ID og passord er skrevet inn, skal innloggingen være vellykket.»

Trinn 2) Identifiser det tekniske kravet som denne testtilfellet verifiserer. For vårt testtilfelle verifiseres det tekniske kravet T94.

Trinn 3) Merk dette tekniske kravet (T94) i testsaken.

Trinn 4) Identifiser forretningskravet som denne TR (Technical Requirement-T94) er definert for

Trinn 5) Merk deg BR (forretningskravet) i testtilfellet

Trinn 6) Gjør det ovennevnte for alle testtilfeller. Later, Pakk ut de tre første kolonnene fra testsuiten din. RTM i testing er klar!

Fordeler med kravsporbarhetsmatrisen

Det bekrefter 100 % testdekning
Den fremhever eventuelle krav som mangler eller dokumenterer inkonsekvenser
Den viser de generelle defektene eller utførelsesstatusen med fokus på forretningskrav
Det hjelper med å analysere eller estimere effekten på QA-teamets arbeid med hensyn til å gå gjennom eller omarbeide testtilfellene på nytt.

Beste praksis og tips for bruk av RTM

En kravsporbarhetsmatrise (RTM) er mest effektiv når den er holdes enkel, konsistent og oppdateres jevnligHer er de beste fremgangsmåtene som vil gjøre det mulig for team å sikre full dekning, minimalt omarbeid og forbedret trygghet i prosjektleveringen:

Begynn tidlig → Lag din RTM helt i begynnelsen av prosjektet.
Hold den oppdatert → Oppdater matrisen når krav eller testtilfeller endres.
Bruk klare ID-er → Tildel unike ID-er til krav og testtilfeller for enkel sporbarhet.
Dekk positive og negative tilfeller → Sørg for at alle krav valideres fra flere testvinkler.
Samarbeid på tvers av team → Involver testere, utviklere, forretningsavdelinger og prosjektledere i vedlikehold av RTM.
Utnytt verktøy → I stedet for regneark, vurder teststyringsverktøy (som Jira, HP ALM eller Zephyr) for skalerbarhet.
Versjonskontroll → Ta vare på historiske versjoner for å spore endringer og opprettholde samsvar.
Fokus på enkelhet → Unngå å overbelaste matrisen; marker kun viktige parametere.
Revisjon regelmessig → Gjennomgå RTM-en med jevne mellomrom for å fange opp mangler før testfrister.
Kobling til forretningsverdi → Kartlegg krav tilbake til forretningsmål for å vise avkastning.

Vanlige RTM-utfordringer og løsninger

Utfordring: Holde RTM oppdatert
Krav og testtilfeller endres ofte, noe som gjør RTM raskt utdatert.
Løsning: Bruk automatiserte verktøy for testadministrasjon som synkroniserer krav, testtilfeller og defekter i sanntid.
Utfordring: Overdreven kompleksitet
Å legge til for mange parametere gjør det vanskelig å vedlikeholde og tolke RTM.
Løsning: Hold RTM slank ved kun å fokusere på viktige felt som ID-er, beskrivelser og status.
Utfordring: Dårlig teamsamarbeid
Ulike team er kanskje ikke enige om eierskap eller oppdateringer.
Løsning: Definer tydelige roller, involver testere, utviklere og analytikere, og planlegg regelmessige RTM-gjennomganger.
Utfordring: Ufullstendig kravdekning
Noen krav kan mangle testtilfeller, noe som fører til manglende funksjonalitet.
Løsning: Valider dekningen regelmessig, bruk toveis sporbarhet og utfør revisjoner før større utgivelser.
Utfordring: Manuell innsats i store prosjekter
Det blir tidkrevende å administrere RTM i regneark for komplekse systemer.
Løsning: Ta i bruk RTM-verktøy som Jira, HP ALM eller Zephyr for å automatisere kartlegging og rapportering.

La oss lære RTM med et eksempel i videoen

Klikk her. hvis videoen ikke er tilgjengelig

Krav Sporbarhetsmatrise (RTM) Mal

Klikk nedenfor for å laste ned RTM-malen i Excel-filen

Last ned RTM-malen Excel(.xlsx)

Spørsmål og svar:

En RTM brukes til å sikre at alle prosjektkrav er knyttet til tilsvarende testtilfeller. Den bidrar til å bekrefte full dekning, spore endringer, redusere feil og gi bevis på validering. Ved å tilordne krav til tester forbedrer RTM kvalitetssikring, samsvar og interessentenes tillit gjennom hele utviklingssyklusen.

Det finnes tre hovedtyper av RTM: Sporbarhet fremover (tilordner krav til testtilfeller), Sporbarhet bakover (knytter testtilfeller tilbake til krav), og Toveis sporbarhet (kombinerer begge retninger). Sammen sikrer disse tilnærmingene fullstendig dekning, forhindrer unødvendig omfangsutvidelse og validerer at alle krav er grundig testet.

Kravsporbarhetsmatrisen utarbeides vanligvis tidlig i prosjektet, når kravene er dokumentert i SRS, BRD eller backlog. Den utvikler seg gjennom hele livssyklusen og oppdateres når krav eller testtilfeller endres. Tidlig utarbeidelse av RTM sikrer samsvar, minimerer tapt funksjonalitet og støtter effektiv testplanlegging og dekningsanalyse.

Hovedansvaret for å opprettholde et RTM ligger vanligvis hos QA-team or testere. Imidlertid forretningsanalytikere definere krav, utviklere lenke kode til disse kravene, og prosjektledere overvåke nøyaktighet. I praksis er RTM et delt ansvar på tvers av team, som sikrer at krav spores og valideres i hvert trinn.

For å bruke en RTM, må du liste opp prosjektkravene ved siden av de tilhørende testtilfellene. Spor utførelsesstatus, defekter og dekning. Teamene bruker den til å bekrefte at kravene er testet, identifisere hull og vurdere virkningen av endringer. Den blir et levende dokument som gir oversikt og kontroll gjennom hele testingen og prosjektets livssyklus.

Ja, RTM brukes mye i agile prosjekter. I stedet for formelle SRS-dokumenter kommer krav ofte fra brukerhistorier or produktrestanserAgile team kartlegger disse historiene til testtilfeller i RTM, og sørger for at hver historie valideres. Den tilpasser seg godt til Agiles iterative natur samtidig som den opprettholder full dekning.

Ja, RTM kan automatiseres ved hjelp av teststyringsverktøy som Jira, HP ALM eller ZephyrAutomatisering reduserer manuell innsats, sikrer sanntidsoppdateringer og gir bedre sporbarhet på tvers av krav, testtilfeller og defekter. Automatiserte RTM-er er spesielt nyttige i store eller regulerte prosjekter der samsvar og revisjonsberedskap er avgjørende.

RTM og RACI tjener forskjellige formål. RTM sporer krav og testtilfeller for å sikre dekning og validering. RACI er en ansvarsfordelingsmatrise som viser hvem som er ansvarlig, ansvarlig, konsultert og informert i et prosjekt. RTM fokuserer på krav og testing, mens RACI tydeliggjør teamroller og ansvar.