Traceability matrix

Bij testen is een traceability matrix (ook wel traceerbaarheidmatrix of cross-reference-matrix genoemd) een document waarin de relatie wordt aangegeven tussen de requirements (functionele specificaties) en de gebruikte testgevallen. De traceability matrix geeft inzicht in de volledigheid van de ontwikkelde en geteste requirements. De traceability matrix is geen requirements overzicht.

Doelstelling van een traceability matrix

  • Geeft inzicht in de testdekking. Zijn alle requirements getest en met de gewenste diepgang.
  • Het geeft een overzicht van de (openstaande) bevindingen op requirement niveau. En is daarmee een goede basis om vast te stellen of aan de acceptatiecriteria is voldaan.
  • Helpt bij het vinden van de corresponderende functionaliteit (requirement) wanneer tijdens de testuitvoering een testgeval faalt. Met name van belang bij regressietesten of geautomatiseerd testen.
  • Het helpt bij het analyseren of het inschatten van de hoeveelheid werk bij wijzigingen in de reeds gerealiseerde requirements.

Het opstellen van een traceability matrix:

  • is meestal een handmatig proces
  • vraagt om een goede discipline om hem te blijven onderhouden
  • wordt vaak als erg arbeidsintensief ervaren

Dat laatste is zeer zeker het geval. De genoemde voordelen zijn echter zo waardevol dat het meer dan de moeite waard is om de matrix op te stellen en bij te houden.

Opzet traceability matrix

De matrix kan opgesteld en onderhouden worden in een tool (bijvoorbeeld HP QC), in Excel of in Word.

De volgende velden kunnen onderdeel zijn van de matrix

  • Requirement ID
  • Requirement omschrijving
  • Testbaar (J / N)
  • Testgeval ID
  • Bevinding
  • Status
  • Opmerkingen

Onderstaand is een vereenvoudigd voorbeeld van een traceability matrix

Traceability MatrixBelangrijke aandachtspunten

  • De discipline waarmee testers de matrix opzetten en onderhouden is bepalend voor de effectiviteit van het gebruik ervan.
  • De matrix kan zowel gebruikt worden voor handmatige testen als geautomatiseerde testen.
  • Er is geen algemene standaard. Je kunt zelf bepalen welke velden je in de matrix wilt opnemen. Minimaal uiteraard wel de requirements en de testgevallen.
  • Maak gebruik van een versie controle systeem om gelijktijdig updaten te voorkomen.

A

Ook interessant?

Opbouw van een testgeval

Testgeval bij software testen

Bij het testen van software is een testgeval een beschrijving van een situatie waarmee vastgesteld kan worden of de software ...
Meer Lezen
Testbasis

Testbasis bij software testen

De testbasis zijn alle bronnen, waaruit de eisen zijn af te leiden, die aan een informatie systeem worden gesteld. Je ...
Meer Lezen
Stoplicht als voorbeeld voor beslispunt

Testsituatie bij software testen

In de functionaliteit zitten diverse keuze momenten, voorwaarden of beslismomenten op basis waarvan de software een specifiek gedrag moet vertonen ...
Meer Lezen
Procesflow

Wat zijn goedpaden en foutpaden

In dit artikel zullen we het verschil tussen goed- en foutpaden uitleggen aan de hand van een procesflow (PFD). PFD ...
Meer Lezen
Blijf op de hoogte van onze nieuwste ontwikkelingen, schrijf je hier in voor de nieuwsbrief!