Moet je bugs altijd registreren?
25 mei 2019 

Moet je bugs altijd registreren?

Bij het testen van software zullen er verschillen met de verwachte resultaten voorkomen. Dit worden ook wel bevindingen, bugs of issues genoemd.

In dit artikel ga ik in op:

  • De mogelijke oorzaken van bugs
  • Met welk doel worden bevindingen vastgelegd
  • Moeten bugs altijd geregistreerd worden en op de backlog worden geplaatst

Mogelijke oorzaken van bevindingen

Bevindingen kunnen verschillende oorzaken hebben:

  1. Testfout
    • Testgeval is onjuist of verkeerd uitgevoerd
    • Uitgangssituatie van systeeminstellingen of testdata is onjuist
    • Verkeerde versie van de software gebruikt
    • De requirements zijn onjuist of voor meerdere uitleg vatbaar
      De tester en ontwikkelaar hebben de requirements anders geïnterpreteerd.
    • De ontwikkelde code is onjuist

De oorzaak bepaalt hoe de bevinding afgehandeld gaat worden. Als eerste zal er dus vastgesteld moeten worden welke van de genoemde oorzaken van toepassing is.

Dit proces is meestal vastgelegd in een bevindingenprocedure en wordt ondersteunt met tools.

Waarom bugs registreren

Het registreren van bevindingen kan om verschillende redenen worden gedaan:

  • Communicatie
    De registratie zorgt er voor dat alle betrokkenen geïnformeerd worden over de bug en aanvullende informatie kan worden vastgelegd.
  • Rapportage
    Met name bij een waterval werkwijze moet er gerapporteerd worden over aantallen bevindingen. En dan gaat het om: openstaande en opgeloste bevindingen en de daaraan gekoppelde ernstcategorie en prioriteit.
  • Hertesten
    Een bevinding bevat onder andere een beschrijving van hoe de deze gereproduceerd kan worden. Enerzijds van belang voor de ontwikkelaar, maar zeker ook voor de testers om de oplossing op een juiste wijze te kunnen hertesten.

Moeten bugs altijd worden geregistreerd

Wanneer er gewerkt wordt volgens de waterval aanpak zullen bugs altijd geregistreerd moeten worden. Dit wordt met name veroorzaakt door de “afstand” tussen het ontwikkel- en testteam.

Wordt er gewerkt volgens Scrum dan kan daar anders mee worden omgegaan. Er kan dan onderscheid gemaakt worden tussen:

  • Bugs die direct kunnen worden opgelost
  • Bugs die tijdens de sprint zullen worden opgelost, maar niet direct
  • Bugs die niet tijdens de sprint zullen worden opgelost

Bugs die direct kunnen worden opgelost

Bugs die direct worden opgelost zijn doorgaans fouten die gevonden worden in de code die tijdens de lopende sprint is ontwikkeld. Deze hoeft niet aan de backlog te worden toegevoegd (tenzij afgedwongen door regelgeving). De bug kan namelijk direct met de ontwikkelaar worden besproken en worden opgelost.

Bugs die tijdens de sprint zullen worden opgelost, maar niet direct

Bugs die niet direct kunnen worden opgelost, maar wel binnen de lopende sprint zullen toegevoegd moeten worden aan de sprint backlog (dus niet aan de product backlog). Dit omdat de sprint backlog al het werk bevat van de lopende sprint en het oplossen van de bug onderdeel is geworden van de lopende sprint.

Bugs die niet tijdens de sprint zullen worden opgelost

Een bug die niet tijdens de lopende sprint moet worden opgelost wordt toegevoegd aan de product backlog. Dit gebeurt trouwens alleen als de product owner de bug in de toekomst wil laten oplossen.

 

Over de schrijver
Ik ben sinds 1983 werkzaam binnen de ICT. Ooit begonnen als Cobol en Credit programmeur en vervolgens de wereld van kwaliteitszorg en testen in gerold. In 1990 ben ik betrokken geweest bij de ontwikkeling van TMap® De jaren daarna heb ik vele functies vervuld binnen het testwerkveld. Waarbij coaching en doceren mij altijd erg is bevallen. Bij Cygnus ben ik met name verantwoordelijk voor het ontwikkelen van content en opleidingen. Heb je een testinhoudelijke vraag of wil je sparren over het stoppen van software fouten bij de bron? Neem dan gerust contact met mij op. Uiteraard ben ik ook beschikbaar voor consultancy opdrachten en coaching.
Reactie plaatsen

arrow_drop_up arrow_drop_down