Get in touch!

  • Dit veld is bedoeld voor validatiedoeleinden en moet niet worden gewijzigd.

Help ! Het werkt niet

Prosteps > Development  > Help ! Het werkt niet

Help ! Het werkt niet

Iedereen die software ontwikkelt heeft minstens één nietszeggende melding ontvangen  “het werkt niet !”. Rapporten die geen hout snijden, onvolledige of zelfs verkeerde informatie geven, rapportering van problemen die een fout gebruik of fouten van een ander(mans) programma zijn, rapportering van problemen die door een slecht netwerk of hardware zijn veroorzaakt.

 

Er is een reden waarom technische ondersteuning als vreselijke wordt beschouwd en deze reden is verkeerde foutenrapportages. Niet alle foutmeldingen zijn echter onplezierig. Af en toe krijgen we wonderbaarlijk heldere, behulpzame en informatieve storingsrapporten binnen.

 

In dit document wordt duidelijk gemaakt wat een goede foutenrapportage inhoudt. Idealiter had ik graag dat iedereen ter wereld voordat hij of zij een fout aan iemand meldt deze pagina ter harte neemt.

 

In een notendop, het doel van een foutenrapport is de ontwikkelaars in staat stellen de programmafouten voor zich te zien. U kunt ze persoonlijk tonen of zorgvuldige en gedetailleerde aanwijzingen geven op welke wijze het programma mislukt. Als dat inderdaad het geval is kunnen ze zelf extra informatie verkrijgen totdat de oorzaak boven water komt. Zo niet zal men die informatie van u verlangen.

 

Geef in foutenrapporten heel duidelijk aan wat er feitelijk aan de hand was (“Ik zat achter de computer en toen gebeurde dit”) en wat u aanneemt (“Ik denk dat dit het probleem zou kunnen zijn”). Aannames kunt u desgewenst weglaten, maar vermeld de feiten.

 

U meldt een fout, omdat u die op wil laten lossen. Schelden op de ontwikkelaars is zinloos of op zijn minst onbeholpen: het kan wel hun schuld en uw probleem zijn en u kunt terecht kwaad op hen zijn, maar de storing is sneller opgelost als u hen alle nodige informatie verstrekt.

 

 

Het werkt niet !”


Geef de programmeur ook wat krediet voor basisintelligentie: als het programma helemaal niet werkt hadden ze dat waarschijnlijk al gemerkt. Aangezien dat niet het geval is moet het bij hen gewerkt hebben of moeten ze de fout niet opgemerkt hebben. Mogelijk hebt u iets anders gedaan of u werkt in een andere omgeving dan zij. Ze hebben informatie nodig :  het verstrekken van die informatie is het doel van een foutenverslag. Het verslag is beter naarmate het meer informatie bevat.

 

 

“Toon me.”

 

Een van de beste manieren om een fout te melden is deze zichtbaar te maken voor de ontwikkelaars. Vandaag beschikt uw software leverancier wel over de nodige hulpmiddelen om uw computer over te nemen vanop afstand indien dit noodzakelijk is om het probleem duidelijk te maken.

 

Het belangrijkste is dat de programmeur naar de computer kijkt wanneer het fout gaat. Wanneer ze eenmaal het probleem hebben zien optreden kunnen ze van daaruit een begin maken met het zoeken naar een oplossing.

 

 

“Leg het me uit.”

 

Als u een fout moet melden aan programmeurs die niet zal meekijken op uw scherm, is het de kunst ze in staat te stellen de onvolkomenheid zelf te reproduceren. U wil dat de ontwikkelaars op hun eigen installatie dezelfde dingen doen en op gelijke wijze mis laten lopen. Wanneer ze het probleem voor ogen zien kunnen ze actie ondernemen.

 

Vertel ze exact wat u deed. Zeg welke knoppen u in welke volgorde indrukte. Als het programma door middel van het typen van commando’s werkt, schrijf precies welk(e) commando(s) u typte. Voeg zo mogelijk een letterlijk verslag van de sessie bij, waarin te lezen is wat de antwoorden op welke commando’s waren.

 

 

“Werkt bij mij. Dus wat gaat er mis?

Als u de ontwikkelaars een lange lijst met invoer en acties geeft en zij zetten hun exemplaar aan het werk en er gaat niets fout dan heeft u niet genoeg informatie verstrekt. Een ontwikkelaar kan u soms melden “bij mij werkt dat”.  Hij wil niet zeggen dat hij u niet geloofd, maar enkel aangeven dat u waarschijnlijk iets anders doet of dat er andere omstandigheden zijn dan bij hem die het doen mislopen.

Misschien treedt de fout niet op elke computer op, is uw systeem een beetje anders dan die van hen. Misschien had u een ander idee van wat het programma zou behoren te doen, ziet u beide hetzelfde, maar denkt u dat het fout is en weten zij dat het goed is.

Geef dus ook aan wat er gebeurde. Vertel ze exact wat u zag. Zeg ze waarom u denkt dat wat u zag verkeerd is; nog beter wat u verwachtte te zien. Als u zegt “en toen ging het mis” heeft u essentiële informatie achtergehouden.

Als u foutmeldingen zag, vertel dan zorgvuldig en precies aan de programmeurs welke dat waren.  Omdat u de betekenis niet inziet betekent dat niet dat deze er niet is.

 

Nu gaat de ontwikkelaar met effectief onderzoekswerk aan de slag. Ze weten niet wat er gebeurde en kunnen niet dicht genoeg bijkomen om het gebeuren met eigen ogen te zien dus zoeken ze naar aanwijzingen om het duidelijk te krijgen. Foutboodschappen, onbegrijpelijke rijen getallen en zelfs onverklaarde wachttijden zijn net zo belangrijk als vingerafdrukken op de plaats van een misdrijf. Hou ze in ere!

 

 

“En toen probeerde ik . . .”

 

Er zijn veel dingen die u zou kunnen doen als een verstoring optreedt.  Als het u lukt uit de problemen te komen, hetzij door het programma af te sluiten, danwel de computer te herstarten, dan is het goed dit nog eens te laten gebeuren. Programmeurs zijn dol op terugkerende problemen. Vrolijke ontwikkelaars verhelpen storingen sneller en efficiënter.

 

 

“Geef de symptomen, geen diagnose.”

 

Je gaat niet naar een doktor en zegt “Dokter, Ik wil graag een recept voor Hydroyoyodyne.”  Mensen weten wat ze tegen een arts moeten zeggen: U beschrijft de symptomen, de werkelijke ongemakken, kwalen, pijnen, uitslag en koorts en laat de diagnose wat er aan de hand is en wat er tegen te doen aan de geneesheer over.

 

Dat is met ontwikkelaars net zo. Uw eigen diagnose stellen mag dan soms helpen, maar beschrijf altijd de symptomen. De diagnose is een optie bij, maar geen alternatief voor het geven van symptomen.

 

Als een programmeur u meer informatie vraagt, verzin die dan niet!

 

Uw verstand gebruiken om de programmeur te helpen is prima. Zelfs als uw redenering niet klopt zullen de ontwikkelaars blij zijn dat u uw best heeft gedaan hun leven te veraangenamen, maar geef ook de symptomen weer of u loopt goede kans dat u het hen inplaats daarvan moeilijker maakt

 

 

“Heldere taal”


Heldere taal is essentieel in een foutenrapport. Als de programmeur niet kan zeggen wat u bedoelde hebt u vast niet veel gezegd.

 

Wees specifiek: Als u hetzelfde kan doen op twee verschillende manieren, zeg welke u gebruikte. “Ik koos Laad”zou kunnen betekenen “ik klikte op Laad” of “ik typte Alt-L” hetgeen u deed. Soms maakt dat wat uit.

 

Wees uitgebreid: Geef bij voorkeur te veel informatie dan te weinig. Als u te veel zegt kunnen de ontwikkelaars wat negeren. Wanneer u te weinig zegt moeten ze weer aankloppen voor aanvullende gegevens.

 

Wees voorzichtig met voornaamwoorden: Vermijd woorden als “het” of verwijzingen als “het venster” wanneer niet duidelijk blijkt waar ze op slaan.

 

Lees wat u schreef: Lees het verslag voor u zelf na en kijk of u denkt dat het duidelijk is. Als u een serie acties hebt opgesomd die de fout teweeg zouden brengen probeer ze voor uzelf te volgen om na te gaan of u geen stap hebt overgeslagen.

 

 

Conclusie


Het eerste doel van een foutenverslag is de programmeurs de fout met eigen ogen te laten zien. Als dat niet lijfelijk kan, geef ze dan gedetailleerde instructies hoe ze deze mislukking bij zichzelf kunnen naspelen.

 

In het geval dat het eerste doel niet slaagt en de programmeurs zijn niet in staat de fout voor zichzelf te reproduceren is het tweede doel van een foutenverslag et beschrijven van hetgeen verkeerd liep. Beschrijf alles tot in de puntjes. Leg uit wat u zag en vermeld tevens wat u verwachtte te zien. Schrijf de foutmeldingen op. Wanneer uw computer iets onverwachts doet, houd u gedeisd. Doe niets totdat u tot rust gekomen bent en doe zeker niet iets waarvan u denkt dat het riskant zou kunnen zijn. Probeer in ieder geval de fout voor uzelf te diagnosticeren als u daar toe in staat denkt te zijn, maar als u dat doet stuur dan toch het verslag op met daarin ook de symptomen. Wees bereid de ontwikkelaars van alle gewenste informatie te voorzien. Als ze het niet nodig hadden zouden ze er niet om vragen. Ze doen niet met opzet vervelend. Schrijf helder. Zeg wat u bedoelt en verzeker u ervan dat het niet verkeerd begrepen kan worden.

 

Boven alles, wees precies. Programmeurs houden van precisie.

 

 

Dit document is gemaakt op basis van http://www.chiark.greenend.org.uk/~sgtatham/bugs-nl.html .  Verkort, aangepast naar eigen inzichten en toegepast op onze sector.