Joel on Software   Joel over Software

Andere "Joel on Software" artikelen in het Nederlands

Andere "Joel on Software" artikels in het Engels

Email de auteur (uitsluitend in het Engels)

TRS-80 Level-I BASIC kon slechts twee string variabelen opslaan, A$ en B$. Ik ben geboren met slechts twee 'geheugenplaatsen' voor bugs. Ik kan op eender welk moment maar twee bugs onthouden. Als je me vraagt om er drie te onthouden, zal er één van de tafel vallen.

Het bijhouden van een bug-database is één van de tekenen van een goed software team. Het blijft me verbazen hoe weinig teams dit werkelijk doen. Programmeurs blijven maar geloven dat ze alle bugs kunnen onthouden door overal Post-It's te plakken.

Als je even de tijd hebt, wil ik je een vrij pijnloze manier uitleggen om bug tracking te doen, vergelijkbaar met m'n vorige artikels over pijnloze software planning en pijnloze specificaties.

Je hebt allereerst een echte database nodig. In een team van twee mensen die wat code schrijven op een regenachtige zondagmiddag kan je waarschijnlijk wel een tekst bestand gebruiken, maar is het team groter, gebruik dan een echte database. Er zijn ontelbare bug tracking databases te koop (schaamteloze zelfpromotie: degene die we bij Fog Creek Software schreven, FogBUGZ, is web-gebaseerd, vrij gemakkelijk te gebruiken, en aardig krachtig, al zeg ik het zelf).

Laten we het leven van een bug eens volgen, van het moment dat ze ontdekt wordt totdat ze wordt opgelost. De bug heeft nummer 1203 en dit laat de bug database zien:

Dit is wat er gebeurd is.

Mikey de Programmeur is lekker code aan het kloppen voor de nieuwe FTP client feature van z'n geweldige Macintosh software. Op een gegeven moment, schrijft hij z'n eigen string-copy functie. Ach code hergebruiken - de mijne is vast sneller & beter - ha ha ha!

Dat soort dingen gebeurt wanneer je geen code hergebruikt, Mikey. En deze keer was Mikey vergeten om de gekopieerde string met een null af te sluiten. Dit probleem kwam bij hem nooit boven water, omdat hij vaak de strings kopieerde naar geheugen dat vooraf gevuld was met null waarden.

Later die week wacs Jill de Hele, Hele Goede Tester z'n code aan het mishandelen door met haar voorhoofd op het toetsenbord over en weer te rollen, of iets in die aard. (Overigens, de meeste goede testers heten Jill, of hebben een naam die daar op lijkt.) Opeen gebeurde er iets erg vreemds: de ftp daemon die gebruikt werd voor de testen die crasht. Ja, ik weet dat het een Linux machine is, en Linux machines crashen nooit (geen gegniffel van de slashdotters, graag), maar dit zotte ding crashte. En ze gebruikte die server zelfs niet, ze was enkel bestanden naar het ding aan het FTP-en met Mikey's Mac code.

Nu, Jill is een hele, hele goede tester, en dus houdt ze systematisch bij hoe ze test en wat ze doet (de snelheid waarmee haar voorhoofd over de toetsen rolde kan je terugvinden in haar testboek, bijvoorbeeld). Ze start de machines op nieuw, herhaalt de stappen, en wat schetst haar en onze verbazing: het gebeurt opnieuw! De Linux ftp daemon crasht opnieuw! Twee keer in één dag! Wat nu, Linus?

Jill staart naar de stappen die ze heeft opgeschreven. Het zijn er ongeveer 20. Sommige lijken niet gerelateerd. Na enkele experimenten kan Jill het probleem reduceren tot vier stappen die altijd hetzelfde gevolg hebben. Nu is ze klaar om de bug te beschrijven.

Jill voegt de bug toe aan de bug tracking database. Het toevoegen van een bug vergt wat discipline: er zijn goede bug rapporten en slechte bug rapporten.

De Drie Onderdelen voor Goede Bug Rapportage

And the Lord spake, saying, "First shalt thou take out the Holy Pin. Then, shalt thou count to three, no more, no less. Three shall be the number thou shalt count, and the number of the counting shalt be three. Four shalt thou not count, nor either count thou two, excepting that thou then proceed to three. Five is right out. Once the number three, being the third number, be reached, then lobbest thou thy Holy Hand Grenade of Antioch towards thou foe, who being naughty in my sight, shall snuff it."

-- Monty Python and the Holy Grail

De stappen voor goede bug rapportage zijn eenvoudig.  Elk  goede bug rapport heeft slechts drie dingen nodig.

Simpel, niet? Misschien niet. Ik krijg regelmatig bug rapporten toegewezen waar één van de bovenstaande drie items niet in voor komt.

Als je me niet vertelt hoe ik de bug kan reproduceren, heb ik waarschijnlijk geen idee waar je het over hebt. "Het programma crashte en liet een stinkend hoopje achter op het bureau." Da's leuk, schatje. Ik kan er niets mee als je niet verteld waarmee je bezig was. Toegegeven, er zijn keren dat het moeilijk is om de exacte stappen te verkrijgen. Soms weet je gewoon niet meer welke stappen je gedaan hebt, of je bent een bug aan het beschrijven uit "the field" (het veld? Rare naam eigenlijk. Welk veld bedoelen ze, een maïsveld?) . Wanneer een bug zich soms voordoet, maar niet altijd, is het ook niet evident om de stappen te noteren. Maar doe het toch, en schrijf erbij dat de bug zich niet altijd voordoet. Dit zijn de moeilijkste bugs om te vinden.

Als je niet beschrijft wat je verwachtte te zien, begrijp ik misschien niet waarom het een bug is. "Het info-scherm zit onder het bloed." Nou, en? Ik sneed in m'n vingers terwijl ik die code schreef. Wat verwacht je dan? Ah, in het ontwerp staat dat er geen bloed te zien mag zijn. Nu begrijp ik waarom je dit een bug vindt.

Deel drie. Wat je wel zag. Als je me dat niet verteld weet ik niet wat de bug is. Lijkt me duidelijk.

Terug naar Jill & Mikey

Maar goed. Jill voegt de bug toe. En in een goed bug tracking systeem wordt deze automatisch toegewezen aan de hoofdontwikkelaar van het project. En hier zien we het tweede belangrijke concept: elke bug moet altijd aan één enkele persoon zijn toegewezen, totdat het bug rapport gesloten wordt. Een bug is zoals een hete aardappel - als je 'm hebt ben je verantwoordelijk om 'm op te lossen, of je geeft hem aan iemand anders.

Willie, de hoofdontwikkelaar, bekijkt de bug en beslist dat het waarschijnlijk iets te maken heeft met de ftp server, en klasseert het als "geen wijzigingen". Want wij hebben die ftp server niet geschreven.

Wanneer een bug opgelost is wordt deze toegewezen aan diegene die de bug heeft geopend. Dit is cruciaal. De bug is niet opgelost omdat de programmeur dat wil. De gouden regel luidt: "Enkel diegene die een bug opent kan hem sluiten." De programmeur kan de bug oplossen (ha, weer een bug opgelost), maar om de bug echt te sluiten moet de persoon die de bug geopend heeft beamen dat de bug inderdaad opgelost is, of besluiten dat deze bug niet moet worden opgelost voor één of andere reden.

Jill krijgt een e-mail waarin staat dat de bug terug in haar kamp is. Ze bekijkt het commentaar van Willie de Hoofdontwikkelaar, maar dat zint haar niet. De halve wereld gebruikt deze ftp server en die crasht niet. Enkel als je Mikey's code gebruikt. Dus Jill reactiveert de bug, en schrijft haar verhaal erbij. De bug komt dat terug bij Willie, en deze keer kent Willie de bug toe aan Mikey.

Mikey bestudeert de bug, denkt en denkt en denkt, en mist de plank volledig. Hij ziet een andere bug voor deze bug aan, lost die op en zet de status op opgelost.

De bug komt dan weer terug bij Jill, deze keer gemarkeerd als "OPGELOST-GEWIJZIGD". Jill probeert de bug opnieuw te reproduceren, en geloof het of niet, de Linux server crasht weer. Ze reactiveert de bug opnieuw, en kent hem direct toe aan Mikey.

Mikey staat perplex, maar uiteindelijk vindt hij de bron van alle ellende (weet je wat het was? Dat laat ik aan jou over - ik heb genoeg aanwijzingen gegeven!).  Hij fikst de bug, test het, en -- Eureka! De ftp server crasht niet meer. Hij markeert de bug opnieuw als OPGELOST. Jill probeert de bug dan nogmaals te reproduceren, ziet dat alles in orde is, en sluit de bug voorgoed.

Tien Top Tips voor Bug Tracking

1. Een goede tester probeert het aantal stappen terug te brengen tot het minimum; dit is uitermate nuttig voor de programmeur die de bug moet vinden.
2. Denk eraan dat de enige persoon die de bug kan sluiten is degene die de bug heeft geopend. Iedereen kan de bug oplossen, maar enkel de persoon die de bug heeft gezien kan zeker zijn dat dat wat hij zag opgelost is.
3. Er zijn vele manieren om een bug op te lossen. FogBUGZ laat je toe om een bug op te lossen als: gewijzigd, geen wijzigingen, uitgesteld, niet reproduceerbaar, duplicaat of volgens ontwerp.
4. Niet reproduceerbaar betekent dat niemand deze bug kan herhalen. Programmeurs gebruiken dit vaak wanneer de stappen ontbreken in het bug rapport.
5. Je moet je versies nauwkeurig nummeren. Elke versie van de software die je aan de testers geeft moet een uniek nummer hebben, zodat de testers geen bugs testen die in die versie nog niet opgelost zijn.
6. Als programmeur moet je enkel bugs behandelen die in de bug database staan. Accepteer geen enkele andere methode. Als de testers e-mails sturen met bug rapporten, antwoord je slechts met: "wil je deze in de bug database zetten."
7. Als je als tester problemen ondervindt om de programmeurs de bug database te laten gebruiken, geef je hen gewoon geen bugs meer door. Je stopt ze in de bug database, en die e-mailt ze wel naar de programmeurs.
8. Als slechts enkele van je collega-programmeurs de bug database gebruiken, dan ken je gewoon een aantal bugs toe aan de rest. Na een tijdje hebben ze je hint wel door.
9. Als je als manager alle moeite gedaan hebt om zo'n bug database op te zetten, en je merkt dat niemand die gebruikt, kan je die ook gebruiken om nieuwe features hierin te introduceren. Een bug database kan ook dienen als een database voor nieuwe features.
10. Geef niet toe aan de verleiding om nieuwe velden toe te voegen aan de bug database. Elke maand komt er wel iemand met een goed idee voor een nieuw veld in de database. Je krijgt allerlei slimme ideeën, zoals bijhouden in welk bestand de bug gevonden was; bijhouden welk percentage van de bugs te reproduceren is; hoe veel keer een bug voorkomt; welke DLLs op de machine geïnstalleerd was op het moment van de bug. Doe dit niet. Want anders wordt het bug formulier dat ingevuld moet worden zo groot en niemand vult ze meer correct in. Een bug database die werkt is er een die iedereen gebruikt, en als je het de testers moeilijk maakt om de bugs "formeel" te noteren, zullen ze eromheen werken.

Als je programmeert, zelfs in je eentje, zal je een slecht resultaat afleveren zonder een bug database. Bij goede software teams wordt de bug database door iedereen gebruikt, en zie je dat mensen de bug database gebruiken om hun professionele "te-doen" lijst hier in bijhouden, de start pagina van hun internet browser zetten naar hun lijst met bugs, en er aan denken om bugs toe te kennen aan de office manager om meer cola te kopen.