Antwoord

Achtergrond van de vraag:

Testen van niet-functionele aspecten is ontstaan toen duidelijk werd: zelfs functionaliteit die perfect werkt in logica kan onhandig, traag of ontoegankelijk zijn voor een deel van de gebruikers. Dergelijke defecten zijn moeilijk automatisch te detecteren, daarom spelen handmatige testers hier een sleutelrol.

Probleem:

Testers richten zich vaak alleen op functionaliteit en negeren prestatie, gebruiksvriendelijkheid en toegankelijkheid. Niet-functionele defecten zijn moeilijk te formaliseren en uit te leggen; hun subjectiviteit bemoeilijkt het verkrijgen van een eenduidige beoordeling.

Oplossing:

Bij het testen moet men bewust tijd toewijzen voor niet-functionele controles. Voor prestaties, registreer de responstijd (bijvoorbeeld met een stopwatch), voor gebruiksvriendelijkheid beschrijf ongemakken en geef voorbeelden, voor toegankelijkheid gebruik checklisten of hulpmiddelen (bijvoorbeeld, schakel een screenreader in).

Belangrijke kenmerken:

Vereisen duidelijke formulering van acceptatiecriteria.
Beoordelingsresultaten zijn vaak subjectief, daarom is onderbouwing van rapporten belangrijk.
Niet alle dergelijke defecten zijn acceptabel voor de release — sommige zijn kritiek.

Vragen met een addertje onder het gras.

Moet elke niet-functionele defect worden vastgelegd door een bugrapport door de tester?

Niet altijd. Als het probleem subjectief is, kan het soms voldoende zijn om het met het team te bespreken en te documenteren als een verbetering (feature request).

Moet de tester zelf prestatiemetingen doen?

Alleen als ze niet zijn vastgelegd in de vereisten of specificaties, anders kan men daarop steunen.

Is speciale software of tools voor niet-functioneel testen verplicht?

Nee, basiscontroles zijn zeker handmatig mogelijk (bijvoorbeeld handmatig tijd meten, toegankelijkheid analyseren met een checklist).

Typische fouten en anti-patterns

Negeert niet-functionele criteria.
Subjectieve rapporten zonder meetbare bewijzen.
Te algemene of vage titels en beschrijvingen van bugs.

Voorbeeld uit het leven

Negatief geval

De tester merkte op dat de cataloguspagina langer dan 10 seconden laadt, maar registreerde geen bug, in de veronderstelling dat “dit waarschijnlijk voor iedereen geldt”.

Voordelen:

Hij verstoorde het team niet met discutabele tickets.

Nadelen:

Verminderde gebruikerservaring, klanten waren teleurgesteld, het management hoorde over het probleem via klachten.

Positief geval

De tester documenteerde gedetailleerd dat de cataloguspagina 12 seconden laadt bij de eerste toegang, voegde een screenshot van de stopwatch toe en stelde mogelijke optimalisaties voor.