Antwoord.

Handmatige UI-testing is oorspronkelijk ontstaan uit de noodzaak, omdat automatische tools slecht in staat zijn om fouten te detecteren die verband houden met visuele waarneming en gebruiksvriendelijkheid van de interface (geschiedenis). Alle elementen moeten toegankelijk zijn, correct worden weergegeven en interageren zoals verwacht door de gebruiker.

Het grootste probleem van handmatige UI-testing is de subjectieve beoordeling: verschillende mensen kunnen dezelfde interface op verschillende manieren waarnemen. Bovendien komt het vaak voor dat visuele defecten niet worden gedocumenteerd of worden genegeerd (‘probleem’). Om subjectiviteit te vermijden, moeten duidelijke acceptatiecriteria voor visuele elementen worden ontwikkeld, isometrische richtlijnen worden gebruikt en moeten gevonden problemen worden vastgelegd met behulp van screenshots, duidelijke beschrijvingen en vergelijkingen met de oorspronkelijke ontwerpen (‘oplossing’).

Belangrijke kenmerken:

Visuele controle van de positionering, kleuren, en afmetingen van elementen
Controle van de toegankelijkheid en responsiviteit van bedieningspanelen
Gebruik van ontwerpen, richtlijnen en specifieke acceptatiecriteria

Misleidende vragen.

Is het voldoende om de UI alleen in één browser of op één apparaat te testen?

Nee, elementen kunnen anders worden weergegeven vanwege verschillen in browser-engines en schermresoluties.

Als een tester een defect niet ziet, kan hij dan concluderen dat er geen bug is?

Nee, het is noodzakelijk om de interface te vergelijken met richtlijnen en ontwerpen, en niet alleen te vertrouwen op eigen subjectieve waarnemingen.

Kun je eisen voor toegankelijkheid (accessibility) negeren bij het testen van de UI?

Nee, toegankelijkheidseisen zijn belangrijk voor eindgebruikers, inclusief mensen met een beperking.

Veelvoorkomende fouten en anti-patterns

Negeren van cross-browser compatibiliteit en responsiviteit
Ontbreken van uniforme visuele acceptatiecriteria
Negeer kleine visuele defecten en toegankelijkheidsfouten

Voorbeeld uit de praktijk

Negatieve case

De tester controleerde de UI alleen op zijn eigen computer en in één browser, en vergeleek alleen visueel met de vorige versie, zonder op het ontwerp te vertrouwen. Uiteindelijk zagen gebruikers op mobiele apparaten een gebroken interface.

Voordelen:

Testen werd snel uitgevoerd

Nadelen:

Kritische visuele bugs gemist, geen aanpassing van de interface

Positieve case

De tester controleerde de UI op verschillende apparaten en browsers, vergeleek met het ontwerp en hield rekening met toegankelijkheidsgidsen. Hij gebruikte checklists voor visuele criteria.