De requirements die gesteld worden aan software kunnen worden onderverdeeld in functionele en niet-functionele eisen. Functioneel testen richt zich op het testen van de functionele eisen.
Er is vaak onduidelijkheid over het verschil tussen deze 2 soorten eisen. In dit artikel proberen we hier wat inzicht in te geven. We gaan daarnaast ook in op wie functionele testen zouden kunnen uitvoeren.
Functionele eisen: Dit is de wat vraag. WAT moet het informatiesysteem bieden aan functies om het bedrijfsproces te kunnen ondersteunen. Welke activiteiten/taken moet het systeem kunnen uitvoeren?
Voorbeeld functionele eis:
Het kunnen berekenen van het BTW bedrag op basis van verkoopprijs exclusief BTW en voor product geldend BTW-percentage.
Niet functionele eisen: Dit is de hoe vraag. HOE moet het informatiesysteem de gewenste functionaliteit aanbieden. Welke overige eisen worden er aan het informatiesysteem gesteld? Het beschrijft niet de functie zelf, maar een aspect van de wijze waarop de functie zich moet gedragen. De niet-functionele eisen worden gedefinieerd met behulp van kwaliteitsattributen.
Voorbeeld niet-functionele eis:
Er moeten 1000 BTW-berekeningen per minuut uitgevoerd kunnen worden.
TMap® Next gaat uit van de volgende kwaliteitsattributen:
- beheerbaarheid
- beveiliging
- bruikbaarheid
- connectiviteit
- continuïteit
- controleerbaarheid
- flexibiliteit
- functionaliteit
- gebruikersvriendelijkheid
- herbruikbaarheid
- (geschiktheid) infrastructuur
- Inpasbaarheid
- onderhoudbaarheid
- performance
- portabiliteit
- testbaarheid
- zuinigheid
Een andere bekende set van kwaliteitsattributen is te vinden in de internationale standaard ISO25010. Uiteraard kan ook deze set gebruikt worden bij het opzetten en uitwerken van een teststrategie.
Wie is verantwoordelijk voor functioneel testen?
Het testen of het systeem voldoet aan de functionele eisen is zowel de verantwoordelijkheid van de ontwikkelaars als van de acceptanten.
De ontwikkelende partij toont met een systeemtest aan dat het systeem voldoet aan de functionele eisen. De accepterende partij stelt met een acceptatietest vast of het systeem voldoet aan de functionele verwachtingen.
Wie wat test en met welke diepgang wordt vastgelegd in de teststrategie. Binnen de IT-wereld is er vaak “verwarring” over wie wat moet testen. Ten gevolge hiervan kunnen ongewenste situaties ontstaan. Een aantal voorbeelden hiervan zijn:
- De ontwikkelende partij voert geen systeemtest uit. Gevolg is dat de accepterende partij met een niet goed werkend systeem wordt geconfronteerd en vervolgens zelf een volledige functionele test gaat uitvoeren.
- De ontwikkelende partij voert wel een systeemtest uit. De tests en resultaten zijn echter niet gedocumenteerd. Omdat de resultaten van de systeemtest niet te controleren zijn, gaat de accepterende partij een volledige functionele test uitvoeren.
- De ontwikkelende partij voert wel een gedocumenteerde systeemtest uit. De accepterende partij gaat alsnog een volledige functionele test uitvoeren in plaats van de uitgevoerde systeemtest te beoordelen op juistheid en volledigheid.
Tip!
Zorg voor een goed afgestemde teststrategie waar zowel de ontwikkelende- als accepterende partij zich aantoonbaar aan moeten houden.
.
Ook interessant?
Systeemtest
Acceptatietesten
Teststrategie
