de TMAP-definitie van kwaliteit en kwaliteitsrisico in je eigen woorden uitleggen
het verschil tussen fout, fault, failure, incident en anomalie benoemen
verklaren waarom testen bestaat uit verificatie, validatie én exploratie
Examenstof TMAP QCFT: LO50, LO51, LO52
Iedereen roept “dit moet goede kwaliteit hebben”, maar wat betekent dat concreet voor een IT-systeem? TMAP definieert kwaliteit als de totaliteit van eigenschappen en kenmerken van een product of dienst die van belang zijn voor het voldoen aan vastgestelde of vanzelfsprekende behoeften. Kort gezegd: kwaliteit is niet absoluut — het is de mate waarin iets doet wat de gebruiker ervan verwacht.
Van fout tot anomalie
1Fout (error)
Een menselijke vergissing, bijvoorbeeld een vergeten controle.
2Fault
Het gevolg in code of ontwerp: een regel die crasht bij lege invoer.
3Failure
Zichtbaar foutief gedrag: de app crasht bij "bestellen".
4Incident
De melding van een afwijking tussen verwacht en waargenomen gedrag.
Anomalie is de verzamelnaam voor elke afwijking die onderzocht moet worden. Risico = faalkans × impact bepaalt waar je testinspanning naartoe gaat.
Kerndefinitie — kwaliteitsrisico Een kwaliteitsrisico is de specifieke kans dat het product faalt, in relatie tot de verwachte impact als dat gebeurt. De faalkans wordt bepaald door de kans op fouten en de gebruiksfrequentie; de impact hangt samen met het operationele gebruik. Hoe hoger faalkans × impact, hoe meer testinspanning je daar op zet.
Dit is de reden dat je nooit ‘alles’ test: je verdeelt je schaarse tijd op basis van risico. Een knop die zelden gebruikt wordt en weinig schade aanricht als hij stuk is, krijgt minder aandacht dan de betaalmodule van een webshop.
Rond testen zweven veel woorden die door elkaar gebruikt worden, maar in TMAP een precieze betekenis hebben. Testen bestaat uit drie soorten activiteiten: verificatie (voldoet het aan de specificatie?), validatie (voldoet het aan de werkelijke behoefte?) en exploratie (wat ontdekken we als we vrij rondkijken?). Samen leveren ze informatie op over kwaliteit en risico's, zodat het team vertrouwen kan opbouwen dat het testobject de beoogde businesswaarde gaat leveren.
Term
Betekenis (TMAP)
Praktijkvoorbeeld
Fout (error)
Menselijke vergissing tijdens het maken van het systeem
Developer vergeet een null-check
Fault
Het gevolg van de fout in de code/het ontwerp zelf
Een regel code die crasht bij een lege invoer
Failure
Het zichtbare, foutieve gedrag tijdens gebruik of test
De app crasht als je op “bestellen” klikt
Incident
De melding van een afwijking tussen verwacht en waargenomen gedrag
Tester meldt: knop reageert niet
Anomalie
Overkoepelende term voor elke afwijking die onderzocht moet worden
Verzamelnaam voor alle bovenstaande gevallen
Let op: TMAP raadt aan de term defect te vermijden, omdat die in de praktijk voor van alles gebruikt wordt (fault, failure of incident) en daardoor verwarring geeft in rapportages. Gebruik liever het precieze woord.
Waarom is dit meer dan woordenboekwerk? Omdat precieze taal je sneller bij de oorzaak brengt. Als een collega meldt “er is een defect”, weet je niet of hij een crash bedoelt (failure), een melding daarvan (incident) of een regel foute code (fault). Vraag je in plaats daarvan af: wat zag de gebruiker precies, en wat veroorzaakte dat in de code? Die twee vragen leiden je direct naar de juiste term en, belangrijker nog, naar de juiste persoon om het op te lossen: een fault los je op met een developer, een terugkerend patroon van incidenten (een probleem, zie hoofdstuk 5) vraagt om een structurelere aanpak.
Dit precieze taalgebruik is ook de basis van de kwaliteitsrisicoanalyse die je later in deze cursus leert uitvoeren. Je kunt pas verstandig bepalen waar je testinspanning op richt als je weet welke faalkans en welke impact bij een specifiek risico horen. Een betaalmodule die zelden faalt maar bij falen grote financiële schade aanricht, vraagt om een andere aanpak dan een instellingenscherm dat vaak een klein foutje vertoont zonder gevolgen. TMAP noemt dit denken in risico's bewust de basis van elke teststrategie: je test niet omdat het kan, maar omdat het risico dat rechtvaardigt.
Tot slot: onthoud dat testen breder is dan “klikken en controleren”. Verificatie (klopt het met de specificatie), validatie (klopt het met de echte behoefte) en exploratie (wat ontdekken we onderweg) vullen elkaar aan. Een systeem kan perfect voldoen aan de specificatie (geverifieerd) en toch niet doen wat de gebruiker nodig heeft (niet gevalideerd) — denk aan een zoekfunctie die precies werkt zoals gespecificeerd, maar die gebruikers in de praktijk niet vinden omdat het icoon onduidelijk is. Dat soort inzichten vind je vaak pas via exploratie, niet via een vooraf geschreven testscript.
Praktijkopdracht
Pak een bug uit je eigen werk (of verzin een herkenbaar voorbeeld: een winkelmandje dat een verkeerd totaal toont). Beschrijf in 5 regels: wat was de fout (error) die iemand maakte, wat werd daardoor de fault in de code, welke failure zag de gebruiker, en hoe zou jij dit als incident melden? Sluit af met een inschatting van het kwaliteitsrisico: hoe vaak komt dit scenario voor en hoe erg is de schade als het misgaat? (10-15 min)
Samenvatting
Kwaliteitsrisico is de kans dat het product faalt, in relatie tot de impact.
Fout, fault, failure en incident zijn verschillende stappen in dezelfde keten.
Testen bestaat uit verificatie, validatie en exploratie.
