Antwoord

Achtergrond van de vraag:

Naarmate de complexiteit van software toeneemt, is opgemerkt dat een deel van de bugs alleen buiten testgevallen of specificaties wordt ontdekt - vaak zijn deze bugs het kritischst voor echte gebruikers. Testers gebruiken speciale technieken om dergelijke defecten te vinden, waarbij ze standaardtests combineren met hun eigen ervaring.

Probleem:

Verborgen bugs, die verband houden met de interactie van componenten, onjuiste verwerking van niet-overduidelijke situaties of het ontbreken van vereisten, zijn het moeilijkst te detecteren en vast te leggen. Vaak zijn testers niet zeker of ze het gevonden probleem moeten documenteren als het "niet is vastgelegd in de eisen".

Oplossing:

Ze gebruiken methoden van exploratief testen, paren testen en ervaring met vergelijkbare producten. Documenteer altijd zo'n bug zo gedetailleerd mogelijk: stappen, observaties, waarom je denkt dat het een defect is, links naar gerelateerde vereisten of aangenomen logica.

Belangrijke kenmerken:

De noodzaak van initiatief en kritisch denken.
Het is belangrijk om te onderbouwen waarom dit juist een defect is.
In sommige gevallen moet je deelnemen aan discussies met analisten/PO.

Vragen met een valstrik.

Kun je bugs die niet in de vereisten zijn beschreven negeren of niet documenteren?

Nee, informeer altijd, zelfs als er geen exacte verwijzing naar de vereiste is, anders komen kritieke problemen bij de klant terecht.

Is gebruikersongemak een bug of een verbetering (feature request)?

Als het gedrag duidelijk onlogisch is, verwarring of risico's opwerpt, documenteer het dan als een bug, anders als een verbetering.

Moet een tester over elk niet-overduidelijk defect overleggen met het team?

Het wordt aanbevolen om een betwist geval vooraf te bespreken met een analist of ontwikkelaar om zinloze tickets te voorkomen.

Typische fouten en anti-patterns

Het negeren van voor gebruikers voor de hand liggende defecten die niet in de vereisten zijn beschreven.
Zwakke/onvolledige documentatie van verborgen bugs.
Ontbreken van onderbouwing voor bugrapportages.

Voorbeeld uit het leven

Negatieve case

Een tester merkte op dat het systeem vastloopt bij het gelijktijdig openen van twee vensters, maar documenteerde de bug niet omdat zo'n scenario niet in de vereisten en testgevallen was beschreven.

Voordelen:

Heeft geen "overbodige" bug toegevoegd, maakte de handen van de ontwikkelaars vrij voor andere taken.

Nadelen:

Het systeem ging met een kritieke kwetsbaarheid de release in, klanten hebben eronder geleden.

Positieve case

Een tester documenteerde de bug met een beschrijving van de stap (het openen van twee vensters, volgorde van acties), voegde een screenshot toe en legde uit waarom hij dit als een bug beschouwde (een echte gebruiker kan in deze situatie terechtkomen).