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?
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.
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.
.
Ook interessant?

Systeemtest
Meer Lezen

Acceptatietesten
Meer Lezen

Teststrategie
Meer Lezen

Testen binnen scrum – Test Talk Whiteboard
Meer Lezen