Antwoord.

Verificatie en validatie zijn twee belangrijke concepten in testing, die de overeenstemming van een product met verwachtingen en vereisten bepalen.

Achtergrond:

In software engineering is er een onderscheid gemaakt tussen de begrippen verificatie (overeenstemming van het product met de specificatie) en validatie (overeenstemming met de verwachtingen van de gebruiker) om twee verschillende facetten van kwaliteit te beschrijven.

Probleem:

Specialisten verwarren deze termen en passen de benaderingen verkeerd toe: ze testen alleen op basis van de specificaties, waarbij ze de ervaring van de gebruiker negeren, of andersom, ze baseren hun oordeel alleen op de logica van "juist/handig", waarbij ze formele vereisten vergeten.

Oplossing:

Verificatie (Bouwen we het product op de juiste manier?) — controle of het product voldoet aan alle vereisten van de specificatie (documentatie).
Validatie (Bouwen we het juiste product?) — bevestigen dat het product een gebruikersprobleem oplost en overeenkomt met de werkelijke verwachtingen.
Beide benaderingen gebruiken: verifiëren volgens specificaties, valideren — door middel van "echte" verkennende testing, gebruikersscenario's, acceptatietests.

Belangrijke kenmerken:

Verificatie = formele controle van vereisten.
Validatie = empathie voor de gebruiker, simulatie van realistische scenario's.
Beide fasen zijn nodig voor een volledig overzicht van fouten.

Vragen met een twist.

Wat betekent "het product is geverifieerd, maar heeft de validatie niet doorstaan"?

Het voldoet aan de specificaties, maar is ongemakkelijk, lost het gebruikersprobleem niet op en is niet nodig op de markt.

Kan validatie eerder beginnen dan verificatie?

Nee, eerst moet een basisset van vereisten worden gecontroleerd, anders zal een onvolledige functionaliteit het moeilijk maken om de gebruikerservaring te evalueren.

Lijkt het ontbreken van gebruiksgemak op een bug bij verificatie?

Nee, dit is een UX-probleem dat pas naar voren komt tijdens de validatiefase van gebruikersscenario's.

Typische fouten en anti-patronen

Alleen gericht op specificaties, negeren van UX.
Het overslaan van acceptatietests.
Onvoldoende communicatie met degenen die het product echt zullen gebruiken.

Voorbeeld uit het leven

Negatieve case

Er is alleen getest op overeenstemming met de documentatievereisten. Na de lancering bleek: gebruikers begrijpen de logica van het bestelproces niet, ondanks formele overeenstemming met de gedocumenteerde scenario's.

Voordelen:

Alle specifieke vereisten zijn gerealiseerd.

Nadelen:

Lage betrokkenheid van gebruikers, klachten en afwijzing van het product.

Positieve case

We hebben verkennende testing gebruikt en een UX-test georganiseerd met echte gebruikers. We hebben ongemakken ontdekt en het bestelproces verbeterd. Resultaat — positieve feedback, hoge conversies.