Antwoord.

Achtergrond:

Het probleem van testdekking ontstond toen projecten groot werden en er weinig tijd was. Het werd noodzakelijk om te begrijpen wanneer het tijd was om met testen te stoppen om middelen effectief te gebruiken. De tester moet het bedrijf uitleggen dat er "voldoende" is getest en de risico's minimaal zijn.

Probleem:

Handmatig testen kan nooit volledig zijn - er zijn altijd beperkingen op tijd en middelen. Onvoldoende dekking leidt tot gemiste defecten, terwijl overmatige dekking leidt tot budgetoverschrijdingen en vertragingen.

Oplossing:

Gebruik meetwaarden voor dekking: percentage van voltooide vereisten, code-dekking (wanneer beschikbaar), verhouding van unieke scenario's/modules.
Implementeer traceability matrices voor de overeenkomst tussen testcases en vereisten.
Voer gezamenlijke reviews van testcases en defecten uit met het team.

Belangrijke kenmerken:

Harmonisatie tussen vereisten, testcases en functionele modules.
Risico-evaluatie voor prioritering.
De mogelijkheid om duidelijk te argumenteren waarom de testen zijn beëindigd.

Vragen met een valstrik.

Kan men zich alleen op de dekking van testcases richten zonder rekening te houden met risico's?

Nee. Men moet rekening houden met de prioriteiten van functionaliteit: welke gebieden zijn het meest kritisch voor het bedrijf.

Zegt het aantal testcases altijd iets over de kwaliteit van de dekking?

Nee. Veel ongefundeerde of dubbele testcases zijn geen teken van hoge dekking.

Moet exploratory testing in de dekkingmetric worden opgenomen?

Ja, absoluut. Exploratief testen onthult onverwachte defecten die niet door formele testcases zijn gevonden en moet deel uitmaken van het algemene dekkingsbeeld.

Typische fouten en antipatterns

Richten op alleen formele indicatoren, waarbij belangrijke risicovolle gebieden worden genegeerd.
Het verbergen van tekortkomingen in de dekking (niet-getoetste vereisten, niet-gewerkte scenario's).
Deadlines missen door de drang om "alles te dekken".

Voorbeeld uit het leven

Negatief geval

De tester beschouwt de dekking alleen op basis van het aantal testcases zonder rekening te houden met de impact van bugs of gebruikersscenario's.

Voordelen:

Makkelijk om mooie rapporten te presenteren.

Nadelen:

Kritieke bugs kunnen buiten het zicht blijven.

Positief geval

De tester schakelt samen met de analist de risico's in, corrigeert de dekking en legt de nadruk op de belangrijkste componenten.