how create requirements traceability matrix
Vad är krav Spårbarhetsmatris (RTM) vid programvarutestning: Steg-för-steg-guide för att skapa spårbarhetsmatris med exempel och exempelmall
Dagens handledning handlar om ett viktigt QC-verktyg, som antingen är förenklat (läs förbises) eller överbetonat - dvs Spårbarhetsmatris (TM).
Tillverkning, granskning eller delning av en spårbarhetsmatris är oftast inte en av de primära leveranserna av QA-processen - så den är inte särskilt koncentrerad på, vilket orsakar underskottet. Tvärtom, vissa kunder förväntar sig att ett TM avslöjar jordskakande aspekter på sin produkt (under test) och är besvikna.
'När det används rätt kan en spårbarhetsmatris vara din GPS för din QA-resa'.
Som är en allmän praxis på STH , kommer vi att se 'Vad' och 'Hur' aspekterna av en TM i denna artikel.
Vad du kommer att lära dig:
- Vad är kravspårbarhetsmatrisen?
- Testtäckning och kravspårbarhet
- Hur man skapar ett krav Spårbarhetsmatris
Vad är kravspårbarhetsmatrisen?
I Requirement Traceability Matrix eller RTM sätter vi upp en process för att dokumentera länkarna mellan de användarkrav som föreslagits av klienten till det system som byggs. Kort sagt är det ett dokument på hög nivå för att kartlägga och spåra användarkrav med testfall för att säkerställa att för varje krav uppnås tillräcklig testnivå.
Processen för att granska alla testfall som definieras för alla krav kallas spårbarhet. Spårbarhet gör det möjligt för oss att avgöra vilka krav som orsakade flest antal fel under testprocessen.
Fokus för alla testuppdrag är och bör vara maximal testtäckning. Genom täckning betyder det helt enkelt att vi behöver testa allt som finns att testa. Målet för alla testprojekt ska vara 100% testtäckning.
Krav Spårbarhetsmatris skapar ett sätt att se till att vi kontrollerar täckningsaspekten. Det hjälper till att skapa en ögonblicksbild för att identifiera täckningsbrister. Kort sagt kan det också kallas mätvärden som bestämmer antalet testfall Kör, godkända, misslyckade eller blockerade etc. för varje krav.
Varför krävs kravspårbarhet?
Krav Spårbarhetsmatris hjälper till att länka kraven, Testfall och defekter korrekt. Hela applikationen testas genom att ha kravspårbarhet ( Test från slut till slut ansökan uppnås).
sql testfrågor och svar pdf
Krav Spårbarhet säkerställer god ”kvalitet” på applikationen när alla funktioner testas. Kvalitetskontroll kan uppnås när programvara testas för oförutsedda scenarier med minimala defekter och alla funktionella och icke-funktionella krav uppfylls.
Krav Spårbarhetsmatrishjälpmedel för att mjukvarutillämpningar testas under den angivna tidsperioden, projektets omfattning är väl bestämd och dess genomförande uppnås enligt kundens krav och behov och projektets kostnad är väl kontrollerad.
Defektläckage förhindras eftersom hela applikationen testas för dess krav.
Typer av spårbarhetsmatris
Framåt spårbarhet
I ”Framåt spårbarhet” Krav på testfallet. Det säkerställer att projektet fortskrider enligt önskad riktning och att varje krav testas noggrant.
Spårbarhet bakåt
Testfallet kartläggs med kraven i ”Spårbarhet bakåt”. Dess huvudsyfte är att säkerställa att den nuvarande produkten som utvecklas är på rätt väg. Det hjälper också att fastställa att inga extra ospecificerade funktioner läggs till och därmed påverkas projektets omfattning.
Dubbelriktad spårbarhet
(Framåt + Bakåt): En bra spårbarhetsmatris har referenser från testfall till krav och vice versa (krav på testfall). Detta kallas ”dubbelriktad” spårbarhet. Det säkerställer att alla testfall kan spåras till krav och varje krav som anges har exakta och giltiga testfall för dem.
Exempel på RTM
# 1) Affärskrav
BR1 : Alternativet att skriva e-post ska vara tillgängligt.
Testscenario (teknisk specifikation) för BR1
TS1 : Alternativet Skriv e-post tillhandahålls.
Testfall:
Testfall 1 (TS1.TC1) : Alternativet Skriv e-post är aktiverat och fungerar framgångsrikt.
Testfall 2 (TS1.TC2) : Alternativet Skriv e-post är inaktiverat.
# 2) Fel
Efter att ha utfört testfallet om det finns några defekter som också kan listas och kartläggas med affärskraven, testscenarier och testfall.
Till exempel, Om TS1.TC1 misslyckas, d.v.s. att komponera e-postalternativ men aktiverat inte fungerar korrekt, kan en defekt loggas. Anta att defekt-ID som genereras automatiskt eller manuellt tilldelats numret är D01, då kan detta mappas med BR1-, TS1- och TS1.TC1-nummer.
Således kan alla krav representeras i ett tabellformat.
| Affärskrav # | Testscenario # | Testfall # | Fel # |
|---|---|---|---|
| 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 | NOLL |
Testtäckning och kravspårbarhet
Vad är testtäckning?
Testtäckning anger vilka krav som kunderna ska verifiera när testfasen startar. Testtäckning är en term som avgör om testfallet skrivs och utförs för att säkerställa att testa programvaran helt, på ett sådant sätt att minimala eller NIL-fel rapporteras.
Hur uppnår man testtäckning?
Det maximala testtäckningen kan uppnås genom att upprätta en god ”kravspårbarhet”.
- Kartläggning av alla interna defekter till de designade testfallen
- Kartläggning av alla kundrapporterade defekter (CRD) till enskilda testfall för framtida regressionstestpaket
Typer av kravspecifikationer
# 1) Affärskrav
De faktiska kundernas krav listas ned i ett dokument som kallas Dokument för affärsbehov (BRS) . Denna BRS är minutiöst härledda krav på hög nivå efter en kort interaktion med klienten.
Det är vanligtvis utarbetat av 'Business Analysts' eller projektet 'Architect' (beroende på organisation eller projektstruktur). SRS-dokumentet (Software Requirement Specifications) härrör från BRS.
# 2) Specifikationsdokument för mjukvarukrav (SRS)
Det är ett detaljerat dokument som innehåller alla noggranna detaljer för alla funktionella och icke-funktionella krav. Denna SRS är baslinjen för att designa och utveckla programvaruapplikationer.
# 3) Dokument för projektkrav (PRD)
PRD är ett referensdokument för alla teammedlemmar i ett projekt för att berätta för dem exakt vad en produkt ska göra. Det kan delas in i avsnitt som produktens syfte, produktegenskaper, frigörelseskriterier och budgetering och schema för projektet.
# 4) Använd ärendokument
Det är dokumentet som hjälper till att utforma och implementera programvaran enligt företagets behov. Det kartlägger interaktionerna mellan en skådespelare och en händelse med en roll som måste utföras för att uppnå ett mål. Det är en detaljerad steg-för-steg-beskrivning av hur en uppgift behöver utföras.
Till exempel,
Skådespelare: Kund
Roll: Ladda ner spel
Spelnedladdningen är lyckad.
Användningsfall kan också vara en del som ingår i SRS-dokumentet enligt organisationens arbetsprocess.
# 5) Dokument för verifieringsverifiering
Den är dokumenterad som innehåller alla detaljer relaterade till fel. Teamet kan underhålla ett ”Defect Verification” -dokument för att åtgärda och testa om defekterna. Testarna kan hänvisa till ”Defect Verification” -dokument, när de vill verifiera om defekterna är rättade eller inte, testa defekter på olika operativsystem, enheter, olika systemkonfigurationer etc.
Dokumentet ”Defektverifiering” är praktiskt och viktigt när det finns en särskild fasfixerings- och verifieringsfas.
# 6) Användarberättelser
Användarberättelsen används främst i 'Agile' utveckling för att beskriva en programvarufunktion ur ett slutanvändarperspektiv. Användarberättelser definierar vilka typer av användare och på vilket sätt och varför de vill ha en viss funktion. Kravet förenklas genom att skapa användarberättelser.
För närvarande går alla programvaruindustrin mot användning av User Stories och Agile Development och motsvarande programverktyg för att registrera kraven.
Utmaningar för kravsamling
# 1) De insamlade kraven måste vara detaljerade, entydiga, korrekta och väl specificerade. Men det är LÅT BLI lämpligt mått för beräkning av dessa detaljer, entydighet, noggrannhet och väldefinierade specifikationer som behövs för kravsamlingen.
#två) Tolkningen av 'Business Analyst' eller 'Product Owner' som tillhandahåller informationen är kritisk. På samma sätt måste teamet som tar emot informationen ta upp lämpliga förtydliganden för att förstå intressenternas förväntningar.
Förståelsen måste vara synkroniserad med både affärsbehov och de faktiska ansträngningar som krävs för applikationsimplementering.
# 3) Informationen bör också härledas ur slutanvändarens synvinkel.
# 4) Intressenternas tillstånd motstridiga eller motstridiga krav vid olika tidpunkter.
# 5) Slutanvändarens synvinkel beaktas inte av flera skäl och ytterligare intressenter tror att de 'helt' förstår vad som krävs för en produkt, vilket i allmänhet inte är fallet.
# 6) Resurser saknar färdigheter för applikationsutveckling.
# 7) Frekventa ändringar av tillämpningsområdet eller tillämpningsförändringar för moduler.
# 8) Missade, implicita eller odokumenterade krav.
# 9) Inkonsekventa eller vaga krav bestämda av kunderna.
# 10) Slutsatsen av alla faktorer som anges ovan är att ”framgång” eller ”misslyckande” för ett projekt beror väsentligt på ett krav.
Hur kravspårbarhet kan hjälpa
# 1) Var implementeras ett krav?
Till exempel,
Krav: Implementera 'Compose mail' -funktionalitet i ett e-postprogram.
Genomförande: Där på huvudsidan ska knappen ”Skriv e-post” placeras och nås.
# 2) Är ett krav nödvändigt?
Till exempel,
Krav: Implementera ”Skapa e-post” -funktionalitet i en e-postapplikation endast för vissa användare.
Genomförande: Enligt användarnas åtkomsträttigheter om e-postinkorgen är ”skrivskyddad”, krävs i det här fallet inte knappen 'Skriv e-post'.
# 3) Hur tolkar jag ett krav?
Till exempel,
Krav: 'Skapa e-post' Funktionalitet i ett e-postprogram med teckensnitt och bilagor.
Genomförande: När du klickar på 'Skapa e-post', vilka funktioner ska då tillhandahållas?
- Texttext för att skriva e-post och redigera i olika typsnitt och även fetstil, kursiv, understryka dem
- Typer av bilagor (bilder, dokument, andra e-postmeddelanden etc.)
- Tillbehörsstorlek (maximal tillåten storlek)
Således bryts kraven upp till underkrav.
# 4) Vilka designbeslut påverkar genomförandet av ett krav?
Till exempel,
Krav: Alla element 'Inkorgen', 'Skickat e-post', 'Utkast', 'Skräppost', 'Papperskorgen' etc. bör vara tydliga.
Genomförande: Elementen som ska visas ska visas i formatet ”Träd” eller ”Tab”.
youtube till mp4 converter gratis nedladdning full version
# 5) Tilldelas alla krav?
Till exempel,
Krav: Alternativet 'Papperskorgen' tillhandahålls.
Genomförande: Om alternativet 'Papperskorgen' har tillhandahållits måste alternativet 'Ta bort' e-postmeddelande (krav) implementeras och bör fungera korrekt. Om e-postalternativet 'Ta bort' fungerar korrekt samlas bara de borttagna e-postmeddelandena i 'Papperskorgen' och implementering av 'Papperskorgen' -alternativet (krav) är vettigt (kommer att vara användbart).
Fördelar med RTM och testtäckning
# 1) Byggnaden som utvecklats och testats har den nödvändiga funktionaliteten som uppfyller behoven och förväntningarna för 'Kunder' / 'Användare'. Kunden måste få vad han vill. Att överraska kunden med en applikation som inte gör vad den förväntas göra är ingen tillfredsställande upplevelse för någon.
#två) Slutprodukten (Software Application) som utvecklats och levererats till kunden måste endast omfatta den funktionalitet som behövs och förväntas. Extra funktioner som tillhandahålls i programvaran kan verka attraktiva från början tills det finns en kostnad för tid, pengar och ansträngningar att utveckla den.
Extrafunktionen kan också bli en källa till defekter, vilket kan orsaka problem för en kund efter installationen.
# 3) Utvecklarens första uppgift definieras tydligt eftersom de arbetar först med att implementera kraven, som har hög prioritet, enligt kundkravet. Om kundens högprioriterade krav tydligt anges kan dessa kodkomponenter utvecklas och implementeras med första prioritet.
Således säkerställs att chanserna för att slutprodukten ska levereras till kunden är enligt de översta kraven och är enligt schemat.
# 4) Testare verifierar först den viktigaste funktionaliteten som utvecklarna implementerar. Eftersom verifiering (testning) av den prioriterade programvarukomponenten görs först hjälper det till att avgöra när och om de första versionerna av systemet är redo att släppas.
# 5) Exakta testplaner, testfall skrivs och utförs som verifierar att alla applikationskrav implementeras korrekt. Testfallskartläggning med kraven hjälper till att säkerställa att inga större fel missas. Det hjälper vidare till att implementera en kvalitetsprodukt enligt kundens förväntningar.
# 6) Om det finns ”Ändringsförfrågan” från klienten ändras alla applikationskomponenter som påverkas av ändringsbegäran och ingenting förbises. Detta förbättras ytterligare vid utvärderingen, effekten av en ändringsförfrågan på programvaran.
# 7) En till synes enkel ändringsförfrågan kan innebära modifieringar som måste göras på flera delar av applikationen. Det är bättre att dra en slutsats om hur mycket ansträngningar som krävs innan du går med på att göra ändringen.
Utmaningar i testtäckning
# 1) Bra kommunikationskanal
Om det finns några ändringar som föreslås av Intressenter , samma måste kommuniceras till utvecklings- och testteamen i de tidigare faserna av utvecklingen. Utan detta i tid Utveckling, testning av applikation och insamling / fixering av defekter kan inte garanteras.
# 2) Det är viktigt att prioritera testscenarierna
Att identifiera vilka som är högprioriterade, komplexa och viktiga testscenarier är en svår uppgift. Försöker testa alla Testa scenarier är nästan en ouppnåelig uppgift. Målet med att testa scenarierna måste vara mycket tydligt ur affärs- och slutanvändarsynpunkt.
# 3) Processimplementering
Testprocessen måste definieras tydligt med hänsyn till faktorer som teknisk infrastruktur och implementeringar, teamkunskaper, tidigare erfarenheter, organisatoriska strukturer och processer som följts, projektuppskattningar relaterade till kostnad, tid och resurser och plats för teamet enligt tidszonerna.
En enhetlig processimplementering med beaktande av de nämnda faktorerna säkerställer att varje person som berörs av projektet är på samma sida. Detta hjälper till med ett smidigt flöde av alla processer relaterade till applikationsutveckling.
# 4) Tillgång till resurser
Resurserna är av två typer, skickliga domänspecifika testare och testverktygen som används av testarna. Om testarna har rätt kunskap om domänen kan de skriva och implementera effektiva testscenarier och skript. För att implementera dessa scenarier och skript bör testarna vara välutrustade med lämpliga testverktyg.
Bra implementering och leverans i tid av applikationen till kunden kan säkerställas av den enda skickliga testaren och lämpliga testverktyg.
# 5) Effektiv implementering av teststrategi
'' Teststrategi i sig är ett stort och ett separat diskussionsämne. Men här för 'Testtäckning' säkerställer en effektiv implementering av teststrategi att ' Kvalitet' av ansökan är Bra och det är upprätthålls över tiden överallt.
En effektiv ”Teststrategi” spelar en viktig roll i planeringen för alla typer av kritiska utmaningar, vilket ytterligare hjälper till att utveckla en bättre applikation.
Hur man skapar ett krav Spårbarhetsmatris
För att vara med måste vi veta exakt vad det är som behöver spåras eller spåras.
Testare börjar skriva sina testscenarier / mål och så småningom testfall baserade på vissa inmatningsdokument - Affärskravsdokument, Funktionella specifikationsdokument och teknisk design (valfritt).
Låt oss anta att följande är vårt dokument för affärsbehov (BRD): ( Ladda ner detta BRD-exempel i excel-format )
(Klicka på en bild för att förstora)
Nedan följer vårt Functional Specifications Document (FSD) baserat på tolkningen av Business Requirements Document (BRD) och anpassningen av det till datorprogram. Helst måste alla aspekter av FSD behandlas i BRD. Men för enkelhets skull har jag bara använt punkterna 1 och 2.
Exempel på FSD från ovan BRD: ( Ladda ner detta exempel FSD i Excel-format )
Notera : BRD och FSD dokumenteras inte av QA-team. Vi är bara, konsumenterna av dokumenten tillsammans med de andra projektgrupperna.
Baserat på ovanstående två inmatningsdokument, som QA-team, kom vi med listan nedan över högnivåscenarier som vi kan testa.
Exempel på testscenarier från ovanstående BRD och FSD: ( Ladda ner den här provtestscenarifilen )
När vi väl har kommit hit, skulle det nu vara en bra tid att börja skapa kravspårbarhetsmatrisen.
Jag föredrar personligen ett mycket enkelt excelblad med kolumner för varje dokument som vi vill spåra. Eftersom affärskraven och funktionskraven inte är numrerade unikt kommer vi att använda sektionsnumren i dokumentet för att spåra.
(Du kan välja att spåra baserat på linjenummer eller punktnummer osv. Beroende på vad som är mest vettigt för just ditt fall.)
Så här ser en enkel spårbarhetsmatris ut för vårt exempel:
Ovanstående dokument skapar ett spår mellan BRD till FSD och så småningom till testscenarierna. Genom att skapa ett dokument som detta kan vi se till att alla aspekter av de ursprungliga kraven har beaktats av testteamet för att skapa sina testsviter.
Du kan lämna det här. Men för att göra det mer läsbart föredrar jag att inkludera sektionsnamnen. Detta kommer att öka förståelsen när detta dokument delas med klienten eller något annat team.
Resultatet är som nedan:
länkad lista tutorial c ++
Återigen är valet att använda det tidigare eller det senare formatet ditt.
Detta är den preliminära versionen av din TM men tjänar generellt inte sitt syfte när du stannar här. Maximala fördelar kan skördas av det när du extrapolerar det hela vägen till defekter.
Låt oss se hur.
För varje testscenario som du kom fram till kommer du att ha minst 1 eller fler testfall. Så ta med en annan kolumn när du kommer dit och skriv test-ID: n enligt nedan:
I detta skede kan spårbarhetsmatrisen användas för att hitta luckor. Till exempel, i spårbarhetsmatrisen ovan ser du att det inte finns några testfall skrivna för FSD avsnitt 1.2.
Som en allmän regel är alla tomma utrymmen i spårbarhetsmatrisen potentiella områden för utredning. Så ett gap som detta kan betyda en av de två sakerna:
- Testteamet har på något sätt missat med tanke på funktionen 'Befintlig användare'.
- Funktionen 'Befintlig användare' har skjutits upp till senare eller tagits bort från programmets funktionskrav. I det här fallet visar TM en inkonsekvens i FSD eller BRD - vilket innebär att en uppdatering av FSD- och / eller BRD-dokument bör göras.
Om det är scenario 1 kommer det att ange de platser där testteamet behöver arbeta mer för att säkerställa 100% täckning.
I scenarier 2 visar TM inte bara luckor, det pekar på felaktig dokumentation som behöver omedelbar korrigering.
Låt oss nu utvidga TM till att inkludera status för testfall och fel.
Nedanstående version av spårbarhetsmatrisen förbereds generellt under eller efter utförandet av testet:
Ladda ner krav Spårbarhetsmallmall:
=> Spårbarhetsmatrismall i Excel-format
Viktiga punkter att notera
Följande är de viktiga punkterna att notera om den här versionen av spårbarhetsmatrisen:
# 1) Exekveringsstatus visas också. Under körningen ger det en konsoliderad ögonblicksbild av hur arbetet fortskrider.
# 2) Fel: När den här kolumnen används för att fastställa den bakåtgående spårbarheten kan vi säga att funktionen 'Ny användare' är den mest felaktiga. Istället för att rapportera att så och så testfall misslyckades, ger TM öppenhet tillbaka till det affärskrav som har de flesta brister och visar därmed kvaliteten vad gäller kunden.
# 3) Som ett ytterligare steg kan du färgkoda defekt-ID för att representera deras tillstånd. Till exempel, Defekt-ID i rött kan betyda att det fortfarande är öppet, i ett grönt kan det betyda att det är stängt. När detta är gjort fungerar TM som en hälsokontrollrapport som visar statusen för de defekter som motsvarar en viss BRD- eller FSD-funktionalitet är öppen eller stängd.
# 4) Om det finns ett tekniskt designdokument eller användningsfall eller andra artefakter som du vill spåra kan du alltid utöka det ovan skapade dokumentet för att passa dina behov genom att lägga till ytterligare kolumner.
Sammanfattningsvis hjälper RTM att:
- Säkerställer 100% testtäckning
- Visar inkonsekvenser för krav / dokument
- Visar den övergripande defekt- / utförandestatusen med fokus på affärskrav.
- Om ett visst affärs- och / eller funktionskrav skulle förändras hjälper en TM att uppskatta eller analysera inverkan på QA-teamets arbete när det gäller att ompröva / omarbeta testtalen.
Dessutom,
- En spårbarhetsmatris är inte ett specifikt verktyg för manuell testning, det kan också användas för automatiseringsprojekt. För ett automatiseringsprojekt kan testfallets ID ange skriptnamnet för Automation Test.
- Det är inte heller ett verktyg som bara kan användas av QA: erna. Utvecklingsteamet kan använda detsamma för att kartlägga BRD / FSD-krav till block / enheter / kodförhållanden som skapats för att säkerställa att alla krav är utvecklade.
- Testhanteringsverktyg som HP ALM levereras med den inbyggda spårbarhetsfunktionen.
En viktig punkt att notera är atthur du underhåller och uppdaterar din spårbarhetsmatris avgör effektiviteten för dess användning. Om det inte uppdateras ofta eller uppdateras felaktigt är verktyget en börda istället för att vara en hjälp och skapar intrycket att verktyget i sig inte är värt att använda.
Slutsats
Krav Spårbarhetsmatris är sättet att karta och spåra alla kundens krav med testfall och upptäckta defekter. Det är en enda dokument som tjänar huvudsyftet att inga testfall missas och därmed täcks och testas alla funktioner i applikationen.
Bra testtäckning som planeras i förväg förhindrar upprepade uppgifter i testfaser och defektläckage. Ett högt antal defekter indikerar att testning görs bra och därmed går applikationens 'kvalitet' upp. På samma sätt indikerar ett mycket lågt antal defekter att testning inte görs upp till märket och detta hämmar applikationens 'kvalitet' på ett negativt sätt.
Om testtäckningen görs ordentligt kan ett lågt antal defekter motiveras och detta antal kan betraktas som stödstatistik och inte som en primär. Kvaliteten på en applikation kallas ”Bra” eller ”Tillfredsställande” när testtäckningen är maximerad och antalet defekter minimeras.
Om författaren: STH-teammedlem Urmila P. är en erfaren QA Professional med hög kvalitet testa och utfärda spårningsförmåga.
Har du skapat en kravspårbarhetsmatris i dina projekt? Hur lika eller annorlunda är det från vad vi har skapat i den här artikeln? Dela dina erfarenheter, kommentarer, tankar och feedback om den här artikeln genom dina kommentarer.
Rekommenderad läsning
- Exempel på programvara Testplanmall med format och innehåll
- Hur man skriver en effektiv testsammanfattningsrapport (Nedladdning av provrapport)
- Exempel på testfallsmall med testfallsexempel (Ladda ner)
- Exempelmall för godkännandeprovrapport med exempel
- Hur man skriver teststrategidokument (med exempel på teststrategimall)
- Hur testar jag specifikationer för mjukvarukrav (SRS)?
- Topp 20+ bästa verktyg för hantering av krav (hela listan)
- QA-testlistor för testning av programvara (inkluderade exempel på checklistor)