Om duidelijk te kunnen maken wat acceptatiecriteria zijn moeten we eerst stil staan bij het begrip requirements. De eisen die gesteld worden aan informatiesystemen kunnen worden onderverdeeld in functionele (de wat vraag) en niet-functionele (de hoe vraag) eisen . Dit wordt ook wel aangeduid als de requirements waar het systeem aan moet voldoen.
In theorie moet het systeem dus voldoen aan de gestelde requirements. Voldoet het systeem daar niet aan dan wordt het systeem niet geaccepteerd door de stakeholders. Het moeten voldoen aan de requirements is eigenlijk het begrip acceptatiecriteria.
In de praktijk blijkt echter vaak dat de stakeholders voor sommige requirements een versoepeling willen hanteren indien niet aan de oorspronkelijke requirements worden voldaan. De versoepelingen zijn de acceptatiecriteria.
De acceptatiecriteria dienen opgesteld te worden door de stakeholders en zijn input voor het testtraject. Het testtraject is zelf ook stakeholder voor het opstellen van de requirements en bijbehorende acceptatiecriteria die betrekking hebben op het op een goede manier kunnen uitvoeren van het testproces.
Entry- en exit criteria van de verschillende testsoorten zijn afgeleid van de acceptatiecriteria.
Voorbeelden van requirements en accepatiecriteria
Hieronder volgen een aantal voorbeelden om de verschillen duidelijk te maken.
Requirements | Acceptatiecriteria |
---|---|
Bij het raadplegen van klantgegevens dienen deze binnen 2 seconden op het scherm te worden getoond. | 90% van de raadplegingen dienen binnen 2 seconden op het scherm te worden getoond. 10% van de raadplegingen dienen binnen 4 seconden op het scherm te worden getoond. |
Bij het berekenen van een prijs inclusief BTW dient het bij het product behorende BTW-percentage te worden gebruikt. Dus 0%, 6% of 21%. | Bij 99% van de berekening dient het correcte % te worden gebruikt. Bij 1 % van de bereken mag een onjuist BTW percentage worden gebruikt. |
Voor het kunnen gebruiken van de EVT testontwerptechniek dienen de functionele specificaties pseudo code te bevatten. | 2% van de specificaties hoeven geen pseudo code te bevatten. |
ab
c
Tool voor uitvoeren productrisico analyse (PRA)
Deze gratis tool ondersteunt alle activiteiten bij het uitvoeren van een productrisicoanalyse (PRA) en het opstellen van een teststrategie het Mastertestplan.
De tool heeft de volgende features voor PRA en teststrategie op niveau van Mastertestplan:
- Ondersteuning van TMap Next en ISO 25010 kwaliteitsattributen
- Onbeperkt aantal testdoelen
- Minimaal 1 en maximaal 5 kwaliteitsattributen per testdoel
- Risicotabel voor in Mastertestplan
- Maximaal 5 testsoorten
- Koppelen van “Testzwaarte” per testsoort
- Teststrategie voor in Mastertestplan
Tool