how create requirements traceability matrix
Wat is Requirements Traceability Matrix (RTM) bij softwaretests: stapsgewijze handleiding voor het maken van traceerbaarheidsmatrix met voorbeelden en voorbeeldsjabloon
De tutorial van vandaag gaat over een belangrijke QC-tool, die ofwel te versimpeld is (gelezen over het hoofd gezien) of te veel benadrukt, d.w.z. Traceerbaarheidsmatrix (TM).
Meestal is het maken, beoordelen of delen van een traceerbaarheidsmatrix niet een van de primaire resultaten van het QA-proces - dus het is niet in grote mate geconcentreerd, waardoor de onderbenadrukking wordt veroorzaakt. Integendeel, sommige klanten verwachten dat een TM wereldschokkende facetten van hun product (onder test) onthult en zijn teleurgesteld.
'Indien correct gebruikt, kan een traceerbaarheidsmatrix uw GPS zijn voor uw QA-reis'.
Zoals een algemene praktijk bij STH , zullen we de 'Wat' en 'Hoe' aspecten van een TM in dit artikel zien.
Wat je leert:
- Wat is de traceerbaarheidsmatrix van vereisten?
- Testdekking en traceerbaarheid van vereisten
- Hoe u een traceerbaarheidsmatrix voor vereisten maakt
Wat is de traceerbaarheidsmatrix van vereisten?
In Requirement Traceability Matrix of RTM hebben we een proces opgezet voor het documenteren van de koppelingen tussen de gebruikersvereisten die door de klant worden voorgesteld aan het systeem dat wordt gebouwd. Kortom, het is een document op hoog niveau om gebruikersvereisten in kaart te brengen en te traceren met testcases om ervoor te zorgen dat voor elke vereiste een adequaat testniveau wordt bereikt.
Het proces om alle testcases te beoordelen die voor elke vereiste zijn gedefinieerd, wordt Traceerbaarheid genoemd. Traceerbaarheid stelt ons in staat om te bepalen welke vereisten tijdens het testproces de meeste defecten hebben voortgebracht.
De focus van elke testopdracht is en moet de maximale testdekking zijn. Met dekking betekent het simpelweg dat we alles moeten testen wat er getest moet worden. Het doel van elk testproject moet 100% testdekking zijn.
Vereisten Traceerbaarheidsmatrix stelt een manier vast om ervoor te zorgen dat we het dekkingsaspect controleren. Het helpt bij het maken van een momentopname om hiaten in de dekking te identificeren. Kort gezegd kunnen het ook metrics worden genoemd die het aantal uitgevoerde, geslaagde, mislukte of geblokkeerde testcases voor elke vereiste bepalen.
Waarom is traceerbaarheid van vereisten vereist?
Requirement Traceability Matrix helpt om de vereisten, Testgevallen , en defecten nauwkeurig. De hele applicatie wordt getest door middel van Requirement Traceability ( Einde om testen te beëindigen van een aanvraag is bereikt).
video-downloader-software vanaf elke site
Vereiste Traceerbaarheid verzekert een goede ‘kwaliteit’ van de applicatie, aangezien alle functies worden getest. Kwaliteitscontrole kan worden bereikt als software wordt getest op onvoorziene scenario's met minimale defecten en waarbij aan alle functionele en niet-functionele vereisten wordt voldaan.
Vereiste Traceerbaarheid Matrixhulpmiddelen voor het testen van softwareapplicaties in de voorgeschreven tijdsduur, de omvang van het project is goed bepaald en de implementatie ervan wordt bereikt volgens de eisen en behoeften van de klant en de kosten van het project worden goed beheerst.
Defect Lekkages worden voorkomen doordat de gehele applicatie wordt getest op zijn eisen.
Soorten traceerbaarheidsmatrix
Voorwaartse traceerbaarheid
In ‘Forward Traceability’ -vereisten voor de testgevallen. Het zorgt ervoor dat het project volgens de gewenste richting verloopt en dat elke vereiste grondig wordt getest.
Achterwaartse traceerbaarheid
De testcases worden in kaart gebracht met de vereisten in ‘Backward Traceability’. Het belangrijkste doel is ervoor te zorgen dat het huidige product dat wordt ontwikkeld op de goede weg is. Het helpt ook om vast te stellen dat er geen extra niet-gespecificeerde functionaliteiten worden toegevoegd en dat daarmee de scope van het project wordt beïnvloed.
Bi-directionele traceerbaarheid
(Vooruit + achteruit): Een goede traceerbaarheidsmatrix bevat verwijzingen van testgevallen naar eisen en vice versa (eisen naar testgevallen). Dit wordt ‘Bi-directionele’ traceerbaarheid genoemd. Het zorgt ervoor dat alle testcases kunnen worden herleid tot vereisten en dat voor elke gespecificeerde vereiste nauwkeurige en geldige testcases voor hen zijn.
Voorbeelden van RTM
# 1) Zakelijke vereisten
BR1 : De optie voor het schrijven van e-mails moet beschikbaar zijn.
Testscenario (technische specificatie) voor BR1
TS1 : De optie E-mail opstellen is beschikbaar.
Testgevallen:
Testgeval 1 (TS1.TC1) : De optie E-mail opstellen is ingeschakeld en werkt met succes.
Testgeval 2 (TS1.TC2) : De optie voor het opstellen van een e-mail is uitgeschakeld.
# 2) Gebreken
Als er na het uitvoeren van de testcases eventuele defecten worden geconstateerd, kunnen die ook worden weergegeven en in kaart worden gebracht met de businessvereisten, testscenario's en testcases.
Bijvoorbeeld, Als TS1.TC1 mislukt, d.w.z. de optie E-mail opstellen, hoewel ingeschakeld, niet correct werkt, kan een defect worden geregistreerd. Stel dat het automatisch gegenereerde of handmatig toegewezen defect-ID D01 is, dan kan dit worden toegewezen aan de nummers BR1, TS1 en TS1.TC1.
Zo kunnen alle vereisten worden weergegeven in een tabelformaat.
Bedrijfsvereiste # | Testscenario # | Testgeval # | Gebreken # |
---|---|---|---|
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 |
Testdekking en traceerbaarheid van vereisten
Wat is testdekking?
Test Coverage geeft aan welke eisen van de klanten moeten worden geverifieerd wanneer de testfase begint. Testdekking is een term die bepaalt of de testcases worden geschreven en uitgevoerd om ervoor te zorgen dat de softwareapplicatie volledig wordt getest, zodanig dat minimale of NIL-defecten worden gerapporteerd.
Hoe testdekking bereiken?
De maximale testdekking kan worden bereikt door een goede ‘Requirement Traceability’ vast te stellen.
- Alle interne defecten in kaart brengen aan de ontworpen testcases
- Alle door de klant gerapporteerde defecten (CRD) toewijzen aan individuele testgevallen voor de toekomstige regressietestsuite
Soorten vereiste specificaties
# 1) Zakelijke vereisten
De feitelijke eisen van de klanten worden vermeld in een document dat bekend staat als Bedrijfseisen Document (BRS) Deze BRS is een minutieus afgeleide eisenlijst op hoog niveau, na een korte interactie met de opdrachtgever.
Het wordt meestal voorbereid door ‘Business Analisten’ of de ‘Architect’ van het project (afhankelijk van de organisatie of projectstructuur). Het document ‘Specificaties softwarevereisten’ (SRS) is afgeleid van BRS.
# 2) Specificatiedocument voor softwarevereisten (SRS)
Het is een gedetailleerd document dat alle nauwgezette details van alle functionele en niet-functionele eisen bevat. Dit SRS is de basis voor het ontwerpen en ontwikkelen van softwareapplicaties.
# 3) Documenten voor projectvereisten (PRD)
De PRD is een referentiedocument voor alle teamleden in een project om hen precies te vertellen wat een product moet doen. Het kan worden onderverdeeld in secties zoals Doel van het product, Productkenmerken, Vrijgavecriteria en Budgettering en planning van het project.
# 4) Gebruik Case Document
Het is het document dat helpt bij het ontwerpen en implementeren van de software volgens de zakelijke behoeften. Het brengt de interacties in kaart tussen een actor en een evenement met een rol die moet worden uitgevoerd om een doel te bereiken. Het is een gedetailleerde stapsgewijze beschrijving van hoe een taak moet worden uitgevoerd.
Bijvoorbeeld,
Acteur: Klant
Rol: Download spel
Het downloaden van het spel is gelukt.
Use Cases kunnen ook deel uitmaken van het SRS-document volgens het werkproces van de organisatie.
# 5) Verificatiedocument voor defecten
Het is gedocumenteerd met alle details met betrekking tot defecten. Het team kan een ‘Defect Verification’-document bijhouden voor het verhelpen en opnieuw testen van de defecten. De testers kunnen verwijzen naar het ‘Defect Verification’ -document als ze willen verifiëren of de defecten zijn verholpen of niet, defecten opnieuw testen op een ander besturingssysteem, apparaat, andere systeemconfiguratie, enz.
Het document ‘Verificatie van defecten’ is handig en belangrijk wanneer er een speciale fase voor het oplossen en verifiëren van defecten is.
# 6) Gebruikersverhalen
Het gebruikersverhaal wordt voornamelijk gebruikt in ‘Agile’ -ontwikkeling om een softwarefunctie vanuit het perspectief van de eindgebruiker te beschrijven. Gebruikersverhalen bepalen de soorten gebruikers en op welke manier en waarom ze een bepaalde functie willen. De vereiste wordt vereenvoudigd door gebruikersverhalen te maken.
Momenteel evolueren alle software-industrieën naar het gebruik van User Stories en Agile Development en bijbehorende softwaretools voor het vastleggen van de vereisten.
Uitdagingen voor het verzamelen van vereisten
# 1) De verzamelde Requirements moeten gedetailleerd, ondubbelzinnig, nauwkeurig en goed gespecificeerd zijn. Maar er is NEE geschikte maatstaf voor het berekenen van deze details, ondubbelzinnigheid, nauwkeurigheid en goed gedefinieerde specificaties die nodig zijn voor het verzamelen van vereisten.
#twee) De interpretatie van de ‘Business Analyst’ of ‘Product Owner’ die de informatie over de vereisten verstrekt, is van cruciaal belang. Evenzo moet het team dat de informatie ontvangt, gepaste verduidelijkingen geven om de verwachtingen van de belanghebbenden te begrijpen.
Het begrip moet in overeenstemming zijn met zowel de zakelijke behoeften als de feitelijke inspanningen die nodig zijn voor de implementatie van de applicatie.
# 3) De informatie moet ook worden afgeleid vanuit het oogpunt van de eindgebruiker.
# 4) Stakeholders stellen op verschillende tijdstippen tegenstrijdige of tegenstrijdige eisen.
# 5) Het standpunt van de eindgebruiker wordt om meerdere redenen niet in overweging genomen en andere belanghebbenden denken dat ze “volledig” begrijpen wat er nodig is voor een product, wat doorgaans niet het geval is.
# 6) Middelen gebrek aan vaardigheden voor applicatie ontwikkeld.
# 7) Frequente ‘Scope’ wijzigingen van applicatie of prioriteitswijzigingen voor modules.
# 8) Gemiste, impliciete of niet-gedocumenteerde vereisten.
# 9) Inconsistente of vage vereisten bepaald door de klanten.
# 10) De conclusie van alle bovengenoemde factoren is dat het ‘succes’ of ‘mislukking’ van een project in hoge mate afhangt van een vereiste.
Hoe traceerbaarheid van vereisten kan helpen
# 1) Waar wordt een vereiste geïmplementeerd?
Bijvoorbeeld,
Vereiste: Implementeer ‘E-mail opstellen’ functionaliteit in een e-mailtoepassing.
Implementatie: Waar op de hoofdpagina de knop ‘E-mail opstellen’ moet worden geplaatst en geopend.
# 2) Is een vereiste nodig?
Bijvoorbeeld,
Vereiste: Implementeer de functie ‘E-mail opstellen’ in een e-mailtoepassing alleen voor bepaalde gebruikers.
Implementatie: Wat betreft de toegangsrechten van de gebruiker als de e-mailinbox ‘Alleen-lezen’ is, is in dit geval de knop 'E-mail opstellen' niet vereist.
# 3) Hoe interpreteer ik een vereiste?
Bijvoorbeeld,
Vereiste: ‘E-mail opstellen’ Functionaliteit in een e-mailtoepassing met lettertypen en bijlagen.
Implementatie: Als er op ‘E-mail opstellen’ wordt geklikt, wat moeten alle functies zijn?
- Teksttekst om e-mails te schrijven en te bewerken in verschillende lettertypen en ook vet, cursief, onderstrepen
- Soorten bijlagen (afbeeldingen, documenten, andere e-mails, enz.)
- Grootte van bijlagen (maximale toegestane grootte)
Dus de vereisten worden opgesplitst in subvereisten.
# 4) Welke ontwerpbeslissingen zijn van invloed op de implementatie van een vereiste?
Bijvoorbeeld,
Vereiste: Alle elementen ‘Inbox’, ‘Verzonden e-mail’, ‘Concepten’, ‘Spam’, ‘Prullenbak’, enz. Moeten duidelijk zichtbaar zijn.
Implementatie: De elementen die zichtbaar moeten zijn, moeten worden weergegeven in de indeling ‘Boomstructuur’ of ‘Tabblad’.
# 5) Zijn alle vereisten toegewezen?
Bijvoorbeeld,
Vereiste: De optie ‘Prullenbak’ is voorzien.
Implementatie: Als de e-mailoptie ‘Prullenbak’ is opgegeven, moet in eerste instantie de optie ‘Verwijderen’ e-mails (vereiste) worden geïmplementeerd en zou deze correct moeten werken. Als de e-mailoptie ‘Verwijderen’ correct werkt, worden alleen de verwijderde e-mails verzameld in de ‘Prullenbak’ en het implementeren van de e-mailoptie ‘Prullenbak’ (vereiste) is zinvol (zal nuttig zijn).
beste optimalisatiesoftware voor Windows 10
Voordelen van RTM en testdekking
# 1) De ontwikkelde en geteste build heeft de vereiste functionaliteit die voldoet aan de behoeften en verwachtingen van ‘klanten’ / ‘gebruikers’. De klant moet krijgen wat hij wil. De klant verrassen met een applicatie die niet doet wat hij moet doen, is voor niemand een bevredigende ervaring.
#twee) Het eindproduct (softwareapplicatie) dat is ontwikkeld en aan de klant wordt geleverd, moet alleen de functionaliteit bevatten die nodig en verwacht is. Extra functies die in de softwaretoepassing worden geboden, kunnen aanvankelijk aantrekkelijk lijken totdat er veel tijd, geld en moeite is om het te ontwikkelen.
De extra functie kan ook een bron van defecten worden, die na installatie voor een klant problemen kunnen veroorzaken.
# 3) De initiële taak van de ontwikkelaar wordt duidelijk gedefinieerd terwijl ze eerst werken aan het implementeren van de vereisten, die hoge prioriteit hebben, volgens de vereisten van de klant. Als de eisen van de klant met hoge prioriteit duidelijk worden gespecificeerd, kunnen die codecomponenten op eerste prioriteit worden ontwikkeld en geïmplementeerd.
Zo wordt ervoor gezorgd dat de kans dat het eindproduct naar de klant wordt verzonden, voldoet aan de hoogste eisen en op schema ligt.
# 4) Testers verifiëren eerst de belangrijkste functionaliteit die door ontwikkelaars wordt geïmplementeerd. Aangezien de verificatie (testen) van de prioriteitssoftwarecomponent als eerste wordt uitgevoerd, helpt het om te bepalen wanneer en of de eerste versies van het systeem klaar zijn om te worden vrijgegeven.
# 5) Nauwkeurige testplannen, testcases worden geschreven en uitgevoerd die verifiëren dat alle toepassingsvereisten correct zijn geïmplementeerd. Het in kaart brengen van testgevallen met de vereisten helpt ervoor te zorgen dat er geen grote defecten worden gemist. Het helpt verder bij het implementeren van een kwaliteitsproduct volgens de verwachtingen van de klant.
# 6) In het geval dat er een ‘Wijzigingsverzoek’ van de klant is, worden alle applicatiecomponenten die door het wijzigingsverzoek worden beïnvloed, gewijzigd en wordt niets over het hoofd gezien. Dit vergroot de evaluatie nog meer van de impact die een wijzigingsverzoek heeft op de softwareapplicatie.
# 7) Een ogenschijnlijk eenvoudig wijzigingsverzoek kan wijzigingen inhouden die moeten worden aangebracht in verschillende delen van de applicatie. Het is beter om een conclusie te trekken over hoeveel moeite het kost voordat u akkoord gaat met de wijziging.
Uitdagingen in testdekking
# 1) Goed communicatiekanaal
Als er wijzigingen zijn die worden voorgesteld door het Belanghebbenden , hetzelfde moet worden gecommuniceerd naar de ontwikkeling- en testteams in de eerdere ontwikkelingsfasen. Zonder dit op tijd Ontwikkeling, testen van de applicatie en het vastleggen / repareren van defecten kan niet worden gegarandeerd.
# 2) Prioritering van de testscenario's is belangrijk
Het is een moeilijke taak om te bepalen welke, complexe en belangrijke testscenario's met hoge prioriteit zijn. Ik probeer alle Test scenario's is bijna een onhaalbare taak. Het doel van het testen van de scenario's moet heel duidelijk zijn vanuit het oogpunt van het bedrijf en de eindgebruiker.
# 3) Procesimplementatie
Het testproces moet duidelijk worden gedefinieerd, rekening houdend met factoren zoals technische infrastructuur en implementaties, teamvaardigheden, ervaringen uit het verleden, gevolgde organisatiestructuren en processen, projectschattingen met betrekking tot kosten, tijd en middelen en de locatie van het team volgens de tijdzones.
Een uniforme procesimplementatie rekening houdend met de genoemde factoren zorgt ervoor dat iedereen die bij het project betrokken is, op dezelfde lijn staat. Dit helpt bij een vlotte doorstroming van alle processen met betrekking tot applicatieontwikkeling.
# 4) Beschikbaarheid van bronnen
Er zijn twee soorten bronnen: vakbekwame domeinspecifieke testers en de testtools die door de testers worden gebruikt. Als de testers de juiste kennis van het domein hebben, kunnen ze effectieve testscenario's en scripts schrijven en implementeren. Om deze scenario's en scripts te implementeren, moeten de testers goed zijn uitgerust met de juiste ‘testtools’.
Een goede implementatie en tijdige levering van de applicatie aan de klant kan worden gegarandeerd door de enige bekwame tester en de juiste testtools.
# 5) Effectieve implementatie van teststrategieën
Teststrategie is op zichzelf een groot en een apart gespreksonderwerp. Maar hier voor ‘Test Coverage’ zorgt een effectieve implementatie van de teststrategie ervoor dat de ‘ Kwaliteit' van de applicatie is is goed en het is gehandhaafd overal in de tijd.
Een effectieve ‘teststrategie’ speelt een grote rol bij het vooruit plannen voor allerlei kritieke uitdagingen, wat verder helpt bij het ontwikkelen van een betere applicatie.
Hoe u een traceerbaarheidsmatrix voor vereisten maakt
Om bij te zijn, moeten we precies weten wat er moet worden gevolgd of getraceerd.
Testers beginnen met het schrijven van hun testscenario's / doelstellingen en uiteindelijk de testcases op basis van enkele invoerdocumenten - Document met zakelijke vereisten, Functionele specificaties document en technisch ontwerpdocument (optioneel).
Laten we aannemen dat het volgende ons Business Requirements Document (BRD) is: ( Download dit voorbeeld-BRD in Excel-indeling
(Klik op een afbeelding om te vergroten)
Hieronder vindt u ons Functioneel Specificaties Document (FSD) gebaseerd op de interpretatie van het Business Requirements Document (BRD) en de aanpassing ervan aan computertoepassingen. Idealiter moeten alle aspecten van FSD worden behandeld in de BRD. Maar voor de eenvoud heb ik alleen de punten 1 en 2 gebruikt.
Voorbeeld FSD van boven BRD: ( Download dit voorbeeld FSD in Excel-indeling
Notitie : De BRD en FSD zijn niet gedocumenteerd door QA-teams. Wij zijn slechts de consumenten van de documenten samen met de andere projectteams.
Op basis van de bovenstaande twee invoerdocumenten hebben we als QA-team de onderstaande lijst met scenario's op hoog niveau opgesteld die we kunnen testen.
Voorbeeldtestscenario's van de bovenstaande BRD en FSD: ( Download dit bestand met voorbeeldtestscenario's
Als we hier eenmaal zijn aangekomen, is het nu een goed moment om te beginnen met het maken van de Requirements Traceability Matrix.
Persoonlijk geef ik de voorkeur aan een heel eenvoudig Excel-blad met kolommen voor elk document dat we willen bijhouden. Omdat de zakelijke vereisten en functionele vereisten niet uniek genummerd zijn, gaan we de sectienummers in het document gebruiken om bij te houden.
(U kunt ervoor kiezen om te volgen op basis van regelnummers of nummers met opsommingstekens, enz., Afhankelijk van wat het meest logisch is voor uw geval in het bijzonder.)
Hier is hoe een eenvoudige traceerbaarheidsmatrix eruit zou zien voor ons voorbeeld:
Het bovenstaande document legt een spoor vast tussen de BRD naar FSD en uiteindelijk naar de testscenario's. Door een document als dit te maken, kunnen we ervoor zorgen dat elk aspect van de initiële vereisten door het testteam in overweging is genomen bij het maken van hun testsuites.
Je kunt het zo laten. Om het leesbaarder te maken, geef ik er echter de voorkeur aan om de sectienamen op te nemen. Dit zal het begrip vergroten wanneer dit document wordt gedeeld met de klant of een ander team.
Het resultaat is als volgt:
Nogmaals, de keuze om het eerste formaat of het latere te gebruiken, is aan jou.
Dit is de voorlopige versie van uw TM, maar dient over het algemeen niet zijn doel als u hier stopt. Er kunnen maximale voordelen uit worden gehaald wanneer u het helemaal naar defecten extrapoleert.
Laten we eens kijken hoe.
Voor elk testscenario dat je hebt bedacht, heb je minimaal 1 of meer testcases. Voeg dus een andere kolom toe wanneer u daar aankomt en schrijf de testcase-ID's zoals hieronder weergegeven:
beste schoonmaaktool voor pc
In dit stadium kan de traceerbaarheidsmatrix worden gebruikt om hiaten te vinden. Bijvoorbeeld, in de bovenstaande traceerbaarheidsmatrix ziet u dat er geen testcases zijn geschreven voor FSD-sectie 1.2.
Als algemene regel geldt dat lege ruimtes in de traceerbaarheidsmatrix potentiële onderzoeksgebieden zijn. Dus een gat als deze kan een van de twee dingen betekenen:
- Het testteam heeft op de een of andere manier de 'bestaande gebruiker' -functionaliteit gemist.
- De functionaliteit 'Bestaande gebruiker' is uitgesteld naar later of verwijderd uit de functionaliteitsvereisten van de applicatie. In dit geval vertoont het TM een inconsistentie in de FSD of BRD - wat betekent dat er een update over FSD- en / of BRD-documenten moet worden gedaan.
Als het scenario 1 is, geeft het de plaatsen aan waar het testteam nog wat moet werken om 100% dekking te garanderen.
In scenario 2 toont TM niet alleen hiaten, maar wijst het op onjuiste documentatie die onmiddellijk moet worden gecorrigeerd.
Laten we nu het TM uitbreiden met de uitvoeringsstatus en defecten van testcases.
De onderstaande versie van de traceerbaarheidsmatrix wordt over het algemeen opgesteld tijdens of na het uitvoeren van de test:
Download Vereisten Traceerbaarheidsmatrix-sjabloon:
Traceerbaarheidsmatrixsjabloon in Excel-indeling
Belangrijke punten om op te merken
Hieronder volgen de belangrijke punten om op te merken over deze versie van de traceerbaarheidsmatrix:
# 1) De uitvoeringsstatus wordt ook weergegeven. Tijdens de uitvoering geeft het een geconsolideerde momentopname van hoe het werk vordert.
# 2) Gebreken: Wanneer deze kolom wordt gebruikt om de achterwaartse traceerbaarheid vast te stellen, kunnen we zien dat de functionaliteit 'Nieuwe gebruiker' het meest gebrekkig is. In plaats van te rapporteren dat deze en die testgevallen mislukten, biedt TM transparantie terug naar de zakelijke vereisten met de meeste gebreken, waardoor de kwaliteit wordt getoond in termen van wat de klant wenst.
# 3) Als een volgende stap kunt u de defect-ID een kleurcode geven om hun status weer te geven. Bijvoorbeeld, Defect-ID in rood kan betekenen dat het nog open is, in groen kan dit betekenen dat het gesloten is. Wanneer dit is gebeurd, werkt het TM als een gezondheidscontrolerapport dat de status weergeeft van de defecten die overeenkomen met een bepaalde BRD- of FSD-functionaliteit die open of gesloten is.
# 4) Als er een technisch ontwerpdocument is of gebruiksscenario's of andere artefacten die u wilt bijhouden, kunt u het hierboven gemaakte document altijd uitbreiden om aan uw behoeften te voldoen door extra kolommen toe te voegen.
Samenvattend helpt RTM bij:
- 100% testdekking garanderen
- Inconsistenties in vereisten / documenten weergeven
- Weergave van de algehele status van defect / uitvoering met de nadruk op zakelijke vereisten.
- Als een bepaalde zakelijke en / of functionele vereiste zou veranderen, helpt een TM de impact op het werk van het QA-team in te schatten of te analyseren in termen van het opnieuw bekijken / herwerken van de testcases.
Bovendien,
- Een traceerbaarheidsmatrix is geen specifieke tool voor handmatig testen, maar kan ook worden gebruikt voor automatiseringsprojecten. Voor een Automation-project kan de testcase-ID de naam van het Automation Test-script aangeven.
- Het is ook geen tool die alleen door de QA's kan worden gebruikt. Het ontwikkelingsteam kan hetzelfde gebruiken om BRD / FSD-vereisten toe te wijzen aan blokken / eenheden / voorwaarden van code die zijn gemaakt om ervoor te zorgen dat alle vereisten worden ontwikkeld.
- Testbeheertools zoals HP ALM worden geleverd met de ingebouwde traceerbaarheidsfunctie.
Een belangrijk punt om op te merken is datde manier waarop u uw traceerbaarheidsmatrix onderhoudt en bijwerkt, bepaalt de doeltreffendheid van het gebruik ervan. Als de tool niet vaak wordt bijgewerkt of onjuist wordt bijgewerkt, is deze een last in plaats van een hulp en wekt de indruk dat de tool op zichzelf niet de moeite waard is om te gebruiken.
Gevolgtrekking
Vereiste traceerbaarheidsmatrix is het middel om kaart en trace alle eisen van de klant met de testcases en ontdekte defecten. Het is een enkel document dat dient als hoofddoel dat er geen testcases worden gemist en dus elke functionaliteit van de applicatie wordt gedekt en getest.
Een goede ‘testdekking’ die van tevoren wordt gepland, voorkomt repetitieve taken in testfasen en lekkage van defecten. Een hoog aantal defecten geeft aan dat het testen goed is uitgevoerd en dat de ‘kwaliteit’ van de applicatie toeneemt. Evenzo geeft een zeer laag aantal defecten aan dat het testen niet tot de maat is uitgevoerd en dit belemmert de ‘kwaliteit’ van de toepassing op een negatieve manier.
Als de testdekking grondig wordt uitgevoerd, kan een laag aantal defecten worden gerechtvaardigd en kan dit aantal defecten worden beschouwd als ondersteunende statistieken en niet als een primaire. De kwaliteit van een applicatie wordt 'goed' of 'bevredigend' genoemd wanneer de testdekking is gemaximaliseerd en het aantal defecten wordt geminimaliseerd.
Over de auteur: STH teamlid Urmila P. is een ervaren QA Professional met van hoge kwaliteit het testen en volgen van vaardigheden.
Heeft u in uw projecten een matrix voor traceerbaarheid van vereisten gemaakt? Hoe vergelijkbaar of verschillend is het van wat we in dit artikel hebben gemaakt? Deel uw ervaringen, opmerkingen, gedachten en feedback over dit artikel via uw opmerkingen.
Aanbevolen literatuur
- Voorbeeld van een softwaretestplan-sjabloon met indeling en inhoud
- Een effectief testoverzichtsrapport schrijven [Voorbeeldrapport downloaden]
- Voorbeeldtestcase-sjabloon met testcasevoorbeelden [Download]
- Voorbeeldsjabloon voor acceptatietestrapport met voorbeelden
- Hoe een teststrategiedocument te schrijven (met voorbeeldteststrategiesjabloon)
- Hoe de specificatie van softwarevereisten (SRS) testen?
- Top 20+ Best Requirements Management Tools (de volledige lijst)
- De checklists voor het testen van software voor kwaliteitscontrole (inclusief voorbeeldchecklists)