Maandelijks archief: april 2015

You are here: Home / Archive

Hoe log ik een bug?

Rudolph, is that a bug on your nose?

En iets over een rendier…

Mijn eerste blog

Per 30 maart ben ik gestart als zelfstandig ondernemer! Daar hoort natuurlijk ook een website bij én daarop een eigen blog. In mijn eerste blog post iets over hoe je nou een goede bug logged.

Hoe log ik een bug?

Ik ben nu al 10 jaar ontwikkelaar. Ontwikkelen is cool! Grofweg kun je al het ontwikkelwerk opdelen in twee categorieën
1) nieuwe funcionaliteit maken en
2) bestaande functionaliteit wijzigen/fixen.

Nieuwe functionaliteit maken vind ik toch het leukst en meest creatief, maar in de praktijk ben je vaak meer uren bezig bestaande functionaliteit te wijzigen. En het grootste deel daarvan bestaat weer uit bugs fixen. De term bug is afkomstig uit de beginjaren van de informatica, toen af en toe een echt insect nog echt in de grote computer kasten uit die tijd belandde en tot een rekenfout leidde. Maar tegenwoordig is de standaardterm voor een stukje programmeerwerk dat leidt tot een foutmelding of stuk ongewenst gedrag. Met de complexe systemen van tegenwoordig voorkom je niet dat er fouten in sluipen en het wordt door sommigen zelfs gevaarlijk genoemd om het idee te hebben dat je bugs geheel zou kunnen voorkomen tijdens het ontwikkelen.

Maar eenmaal gevonden moet een bug wel opgelost – of gefixed – worden. En om al die bugs beheersbaar te houden zijn er in de loop der jaren allerlei issue tracking systemen gekomen, en er komen er nog steeds nieuwe bij. Enkele van de bekendere zijn BugZilla, Jira, of het wat recentere GitHub issues. Het kan voor bakken geld (TFS) of gratiesch, dus elk zichzelf respecterend software moet zo´n bug database’ hebben, zoals Stack Overflow´s Joel Spolsky het noemt. Dit levert je weer een punt op in zijn befaamde Joel Test. En je krijgt nog een punt als bugfixing prio krijgt over de realisatie van nieuwe functionaliteit. Als Joel het zegt moet het wel waar zijn, dus bugfixing is de shit!

Hoewel bedrijven voor het maken van nieuwe functionaliteit vaak functioneel ontwerpers hebben, of requirements analisten en er ook allerlei meer of minder formele technieken bestaan om deze te beschrijven (use cases, user stories), wordt voor bugs nog vaak nog volstaan met slechts een vage one-liner als beschrijving: “Profielscherm geeft database fout” of “Grijstinten goed zetten”. Kortom `Doet het niet´, succces ermee!

Zo is een bug makkelijk gelogd, maar het gevolg is wel dat de ontwikkelaar die de bug moet gaan fixen zelf moet uitzoeken wat bedoeld wordt, hoe de bug te reproduceren en als dat allemaal lukt, hoe deze te fixen. Hij (/zij) komt dus vanzelf weer naar je toe. Terwijl je op het moment van loggen vaak zelf een veel beter idee hebt wat er mis ging. En als je dit niet, loont het de moeite dit even verder uit te zoeken. Dat levert later alleen maar winst op.

Met name in grotere teams is een goede bug beschrijving van zeer veel waarde. Zowel voor ontwikkelaars bij het reproduceren en oplossen ervan, als voor testers bij het hertesten na de fix. Een organisatie doet er daarom goed wat standaarden in te stellen voor een goede bugbeschrijving.

Voor testers is het goed loggen van bugs één belangrijke vaardigheid. Voor de ontwikkelaar is het ideaalbeeld om een ondubbelzinnige, makkelijk reproduceerbare bug te krijgen. Waar je geen verdere navraag meer hoeft te doen. Een aanzienlijk deel van bugs is met een goede omschrijving al voor meer dan 50% opgelost.

Ik geef geen volledig bug template, want deze zal toch per organisatie verschillen, maar hieronder beschrijf ik een aantal belangrijke componenten, die in de praktijk vaak ontbreken.

1. Verwachte uitkomst

Rudolph0

Een vaak vergeten onderdeel bij bugmeldingen is de verwachte uitkomst. Log altijd zowel de daadwerkelijk gekregen resultaat als de verwachte of gewenste resultaat! Wellicht vind je het logisch dat iedereen weet dat Rudolph’s neus rood is, maar sommige ontwikkelaars weten alleen dat hun auto in GTA rood is, en wie Rudolph is hebben ze geen idee van.

Enige uitzondering is eigenlijk als er een foutmelding/systeemmelding of stack trace optreedt, dan spreekt meer voor zich dat dit niet gewenst is. Maar het weglaten van gewenste uitkomst leidt soms ook tot een van de allermoeilijkst oplosbare en meest tijdvretende type bugs die er zijn: de bug die helemaal geen bug is…

2. ScreenshotRudolph2

Een beeld zegt meer dan 1000 woorden. Voeg bij elk beetje serieuze bug een screenshot toe. Dit bespaart je ellenlange beschrijvingen die vervolgens vaak toch niet begrepen worden. Vermeld wel in tekst op welke knop of welk andere actie direct voorafging aan de bug. Nog idealer is als je de fout in het screenshot kunt markeren met een rood blokje oid. Er zijn tegenwoordig allerlei tools voor zoals de Firefox plugin FireShot (is er ook voor Chrome en Internet Explorer). Ik gebruik zelf graag trusty old paint.net (open source bitmap editor).

Als je het kunt is het voor een beetje focus ook wel handig om irrelevante delen uit het screenshot te knippen. Maar let op: als het om een webapplicatie dan in het screenshot wel graag de ‘browser chrome’ opnemen (de randen met knoppen, adresbalk, etc.). Zo weet de ontwikkelaar namelijk meteen om welke browser het gaat. En kan eventueel hier ook nog een URL uitgehaald worden, Hoewel een URL als tekst (copy-paste) veel makkelijker is, zie onder.

3. ReproductiepadRudolph3

Voor de iets moeilijk bereikbare situaties, of die bugs die niet altijd optreden, maar alleen in heel specifieke situatie is het zeer aan te raden een reproductie pad te geven. Dit beschrijft stap voor stap welke stappen je moet zetten vanaf een bepaalde (beschreven) beginsituatie (bv. inloggen in een applicatie), om de bug opnieuw op te laten treden.

Het gebeurt regelmatig dat iemand die een reproductiepad opstelt, erachter komt dat een bug helemaal niet altijd optreedt. Het kost veel tijd, maar zet je Sherlock Holmes pad op, en spoor de foutsituatie nauwkeurig op. Vaak zegt dit ook al erg veel over de bug. Daarnaast kan je op deze manier soms ook een tijdelijke workaround vinden, zodat mensen op de werkvloer verder kunnen, zolang de bug nog niet is opgelost.

4. URL

Tot slot nog een vrij simpele, maar vaak vergeten: het adres van de pagina waarop de fout optrad. Dit is uiteraard alleen van toepassing als het een webapplicatie betreft, en ook als routing hierin van belang is. Maar dit kan een ontwikkelaar zeer veel tijd besparen, zeker als hij in één keer naar een foutsituatie toe kan klikken. En ook al lukt dit niet, en de gebruiker toch moet klikken, dan geeft het toch al wat context.

5. En verder

Merk op dat andere veelvoorkomende zaken nog niet besproken zijn. Er zijn zeker nog andere nuttige infovelden zoals type issue (bug of nieuwe feature), prioriteit van het issue (MoSCoW), gewenste oplevering/milestone waarin de bug gefixed of de versienummer van applicatie waarin de bug geconstanteerd is.

Tot slot

Het is níet de bedoeling dat bovenstaande punten het überhaupt loggen van een bug in de weg gaan staan. Als dat zo is, dan moeten deze eisen maar even naast je neergelegd worden. Maar je kunt dan in ieder geval bij het issue vermelden, bv. `geen tijd reproductiepad te speccen, vraag even mondeling na bij oppakken`.

Bijvoorbeeld van eindgebruikers kun je niet verwachten dat ze alle benodigde informatie aanleveren, en blijft gelden dat dat je beter een slecht omschreven bug kan inschieten, dan helemaal geen bug. De overige info moet dan later in de followup maar proberen te achterhalen. Maar het normale streven moet toch zijn een reproduceerbare, duidelijke bugbeschrijving mét screenshot.

Succes ermee!