Acceptatiecriteria

AcceptatiecriteriaOm 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.

Definitie:
Requirements zijn de eisen, van alle verschillende stakeholders, waaraan het systeem moet voldoen, functioneel en niet-functioneel.

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.

Definitie:
Acceptatiecriteria zijn versoepelingen op de gestelde requirements.

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.

RequirementsAcceptatiecriteria
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

Ook interessant?

Omgaan met requirements - Test Talk whiteboard

Omgaan met requirements – Test Talk whiteboard

Deze Test Talk whiteboard gaat over het omgaan met "Requirements". En dan toegespitst op ontbrekende of slechte requirements. De volgende ...
Meer Lezen
ISO 25010 Kwaliteitsattributen

Wat zijn kwaliteitsattributen?

Kwaliteitsattributen is een raamwerk om de kwaliteit in kaart te brengen van een software systeem. Hiervoor is een ISO norm ...
Meer Lezen
Testplan

Plan van aanpak voor testen

Aan het begin van een testtraject stel je een testplan op. Dit is vergelijkbaar met een Plan van Aanpak die ...
Meer Lezen
Testen binnen scrum - Test Talk Whiteboard

Testen binnen scrum – Test Talk Whiteboard

In deze Test Talk whiteboard wordt ingegaan op het testen binnen de Scrum methodiek. Veel kijk plezier. Videotranscriptie Welkom bij ...
Meer Lezen
Blijf op de hoogte van onze nieuwste ontwikkelingen, schrijf je hier in voor de nieuwsbrief!