Smärtfri bugghantering
From The Joel on Software Translation Project
Denna artikel är ännu inte färdigöversatt, tills dess rekommenderas originalartikeln 'Painless Bug Tracking' om du inte vill hjälpa med översättningen och språkgranskningen. This article is a translation in progress and has yet to be fully translated and copy-edited.
Återstår:
-
översätta färdigt - kontrollera länkar till andra artiklar
- ta bort originaltexten
- språkgranska
Contents |
[edit] Smärtfri bugghantering
Av Joel Spolsky
Översatt av David Hall
Bearbetat av (ingen)
onsdag 8 november 2000
TRS-80 Level-I BASIC kunde bara lagra två strängvariabler, A$ och B$. På samma sätt föddes jag med enbart två platser i min hjärna för att lagra buggar. Jag kan bara hålla två buggar i huvudet samtidigt. Om du ber mig hålla ordning på en tredje, kommer någon av dem att ramla ut, falla ned på golvet och rulla in till dammråttorna under sängen, som äter upp den.
Att hålla sig med en databas över sina buggar är ett av kännetecknen för en bra programmeringsgrupp. Jag upphör aldrig att förvånas av hur få programmeringsgrupper som faktiskt gör detta. Ett av de mest felaktiga antaganden som programmerare ofta verkar göra, är att tro att de kan komma ihåg alla sina buggar eller hålla koll på dem genom att skriva ned dem på post-it-lappar.
Om jag kan få låna ditt öra nu, så skulle jag vilja förklara ett ganska smärtfritt sätt att hantera buggar, i stil med mina tidigare artiklar om smärtfri programvaruplanering och smärtfria specifikationer.
För det första behöver du en riktig databas. I en grupp om två personer som skriver lite kod över en helg går det förmodligen bra att använda en textfil som databas. Större grupp än så, och du kommer att behöva en riktig bugghanteringsdatabas. Det finns oräkneliga bugghanteringsdatabaser du kan köpa. (Skamlös egenreklam: den vi skrivit på Fog Creek Software, som vi kallar FogBUGZ, är webbaserad, enkel att använda och ganska kraftfull, om jag får säga det själv.)
Låt oss följa en bug i åskådliggörande syfte, från det ögonblick då den föds och ända fram tills dess att någon i barmhärtighet gör slut på dess lidande. Vi kommer att följa den beryktade buggen 1203. Följande är vad buggdatabasen visar för denna bugg:
| ID | 1203 | |
| Projekt | Bee Flogger 2.0 | |
| Område | FTP-klient | |
| Titel | Uppladdning av fil får FTP-servern att krascha. | |
| Delegerat till | STÄNGD | |
| Status | STÄNGD (ÅTGÄRDAT) | |
| Prioritet | 2 - Måste åtgärdas | |
| Åtgärdas innan | 2.0 Alfa | |
| Version | Build 2019 | |
| Dator | Jills iMac, Mac OS 9.0, 128M RAM, 1024x768 miljoner färger | |
| Beskrivning | 11/1/2000 Öppnad av Jill, den jätte-jättebra testaren
* Starta Bee Flogger 11/1/2000 Delegerat till Willie, utvecklingsledaren av Jill, den jätte-jättebra testaren 11/2/2000 (igår) AVKLARAT - TÄNKER INTE ÅTGÄRDA av Wille, utvecklingsledaren Inte vår kod, Jill. Det beror bara på proftpd som kommer med Linux. 11/2/2000 (igår) Återaktiverad(delegerat till Wille, utvecklingsledaren) av Jill, den jätte-jättebra testaren Det kan inte stämma. Jag har aldrig lyckats krascha proftpd genom att koppla upp med en vanlig ftp-klient. Vår kod kraschar den varenda gång. FTP-servrar "kraschar" bara inte. 11/3/2000 (Idag) Delegerat till Micke, programmeraren av Wille, utvecklingsledaren Micke, kan du titta på detta? Kanske är det din klientkod som spökar. 11/3/2000 (Idag) AVKLARAT - ÅTGÄRDAT av Micke, programmeraren Jag tror jag skickade användarnamnet istället för lösenordet eller nåt... 11/3/2000 (Idag) Återaktiverat (delegerat till Micke, programmeraren) av Jill, den jätte-jättebra testaren Inträffar fortfarande i bygge 2021. 11/3/2000 (Idag) Redigerat av Micke, programmeraren Oj. Skumt. Låt mig debugga detta. 11/3/2000 (Idag) Redigerat av Micke, programmeraren Jag tror det beror på MickeStrCpy()... 11/3/2000 (Idag) AVKLARAT - ÅTGÄRDAT av Micke, programmeraren Ahhh! 11/3/2000 (Idag) Stängt av Jill, den jätte-jättebra testaren Ser ut att vara åtgärdat i bygge 2022, så jag stänger denna nu. |
Följande har hänt.
Micke, programmeraren, hackar på den nya FTP-klientsfunktionen i sin fräcka Mac-programvara. Vid något tillfälle, när han känner sig yster, skriver han sin egen strängkopieringsfunktion. Det ska visa de där återanvändningsivrarna! Muahahah!
Det händer dåliga saker när du inte återanvänder kod, Micke. Och det dåliga som inträffade idag var att Micke glömde att avsluta den kopierade strängen med null. Men han märkte aldrig något, eftersom han oftast råkade kopiera strängar till delar av internminnet som redan innehöll null.
Senare samma vecka ger Jill, den jätte-jättebra testaren, koden en ordentlig omgång. Hon rullar huvudet fram och tillbaka på tangentbordet eller genomför något annat, lika elakt testfall. (Händelsevis heter de flesta bra testare Jill, Gillian eller något liknande.) Plötsligt inträffar något märkligt: ftp-serverprogrammet som hon testar mot kraschar. Ja, jag vet att det är en linuxmaskin och att linuxmaskiner aldrig kraschar (inga snobbiga fnysningar från slashdot-horden nu, tack) men den här rackarns saken krashade. Och hon rörde inte ens servern, hon skickade bara filer via FTP med Mickes Mac-kod.
Nu är Jill en jätte-jättebra testare, så hon förde noggranna anteckningar över vad hon gjorde (den exakta lutningen och svängningen på huvudet när hon rullade det över tangentbordet finns till exempel i hennes labbhäfte). Hon startar om allting, börjar om med en ren maskin, repeterar stegen och -- håll i dig nu -- det händer igen! FTP-serverprogrammet på linuxmaskinen kraschade igen! Det är två gånger på en och samma dag! Sug på den, Linus!
Jill sneglar på listan med steg för att återskapa felet. De är ungefär 20 stycken. Några av dem verkar vara irrelevanta. Efter lite experimenterande lyckas Jill få fram felet med bara fyra steg som alltid ger samma beteende. Nu kan hon rapportera buggen.
Jill skriver in den nya buggen i buggrapporteringsdatabasen. Nu är det så, att själva upprättandet av en buggrapport kräver lite disciplin: det finns bra buggrapporter och det finns dåliga buggrapporter.
[edit] De tre delarna i varje bra buggrapport
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
Det är ganska enkelt att komma ihåg regeln för en bra buggrapport. Varje bra buggrapport behöver exakt tre saker.
- Stegen för att återskapa buggen.
- Vad du förväntade dig att se, och
- Vad du fick se istället
Verkar enkelt, eller hur? Kanske inte. Som programmerare får jag regelbundet buggrapporter där någon del saknas.
Om du inte berättar för mig hur du gör för att återskapa felet, så kommer jag förmodligen inte att ha en aning om vad du pratar om. "Programmet krashade och lämnade ett lortliknande, pruttluktande föremål på bordet." Det är fint, lilla vän. Jag kan inte göra något åt det om du inte berättar för mig vad du vad du höll på med. Dock medger jag att det finns två fall där det är svårt att få fram exakta steg att återskapa. Ibland minns man helt enkelt inte, eller så antecknar man en bugg som man fått "från fältet". (Förresten, varför kallas det "fältet"? Är det ett rågfält eller nåt? Hur som helst...) Det andra tillfället, när det är okej att stegen för att återskapa felet saknas, är när buggen inträffar ibland men inte alltid. Även då bör man dock fortfarande bifoga steg för att återskapa, med en liten notis om att det inte inträffar så ofta. I dessa fall kommer det bli väldigt svårt att hitta buggen, men vi kan försöka.
Om du inte berättar vad du förväntar dig få se, kanske jag inte förstår varför det är en bugg. Det är blod på startskärmen. Än sen? Jag skar mig i fingret när jag kodade den. Vad förväntade du dig? Jaså, du säger att specifikationen kräver att det är blodfritt! Nu förstår jag varför du anser att detta är en bugg.
Del tre. Vad du såg istället. Om du inte berättar detta vet jag inte vad buggen är. Denna är ganska uppenbar.
[edit] Tillbaka till vår berättelse
Hur som helst. Jill skriver in buggrapporten. I ett bra bugghanteringssystem delegeras den automatiskt till utvecklingschefen för projektet. Däri ligger den andra idén: varje bugg måste vara delegerad till exakt en person vid varje given tidpunkt, tills den stängs. En bugg är som en het potatis: när den är delegerad till dig är du ansvarig att lösa den, på något sätt, eller delegera den till någon annan.
Wille, utvecklingschefen, tittar på buggen, bestämmer sig för att det troligen är fel på ftp-servern och löser buggen som "åtgärdas inte". Det var ju faktiskt inte de som skrev ftp-servern.
När en bugg är löst, delegeras den tillbaka till personen som öppnade den. Det här är ett avgörande steg. Den försvinner inte bara för att programmeraren tycker att den borde göra det. Den gyllene regeln är att endast personen som öppnade buggen kan stänga den. Programmeraren kan lösa buggen, i bemärkelsen "hallå, jag tror det är fixat" men för att faktiskt stänga buggrapporten måste personen som öppnade den bekräfta att den verkligen åtgärdats, eller instämma i att den, av någon anledning, inte behöver åtgärdas.
Jill får ett e-post som berättar att hennes bugg är tillbaka hos henne. Hon tittar på den och läser utvecklingschefen Willes kommentar. Någonting känns fel. Folk har använt den här ftp-servern i åratal utan att den krashat. Den kraschar bara när man använder Mickes kod. Så Jill återaktiverar buggrapporten och förklarar sin ståndpunkt, och buggen går tillbaka till Wille. Den här gången delegerar Wille buggen till Micke för åtgärd.
Micke studerar buggrapporten, funderar länge och väl, och missbedömer den fullständigt. Han fixar sålunda en helt annan bugg, men noterar Jills buggrapport som löst.
Buggen är tillbaka hos Jill, denna gång märkt som "LÖST-ÅTGÄRDAD". Jill provar sina återskapningssteg med det senaste bygget och, skåda och begrunda, linuxservern kraschar. Hon återaktiverar buggen igen och delegerar den återigen till Micke.
Micke är helt ställd, men han lyckas till slut leta rätt på orsaken till buggen. (Har du kommit på vad det är ännu? Det lämnas som en uppgift till läsaren att fundera ut. Jag har gett dig tillräckligt med ledtrådar!) Han fixar felet, testkör och -- Eureka! Återskapningsstegen kraschar inte längre ftp-servern. Ännu en gång löser han buggen som ÅTGÄRDAD. Jill kör också igenom återskapningsstegen, upptäcker att buggen är fixad och stänger den.
[edit] Topp-tio tips för bugghantering
- En bra testare ska alltid försöka reducera antalet återskapningssteg; detta är till extremt stor hjälp för programmeraren som ska hitta buggen.
- Kom ihåg att det är bara personen som öppnat buggen som kan stänga den igen. Vem som helst kan lösa den, men endast personen som såg buggen kan vara riktigt säker på att det som sågs är åtgärdat.
- Det finns många sätt att lösa en bugg. FogBUGZ låter dig lösa en bugg som åtgärdad', tänker inte åtgärda, uppskjuten, kan inte återskapa eller enligt design.
- Kan inte återskapa innebär att ingen någonsin kunde återskapa buggen. Programmerar användare ofta detta när buggrapporten saknar återskapningsstegen.
- Du kommer att vilja ha noggrann ordning på versioner. Varje bygge av programvaran som du skickar till test bör ha ett bygg-ID-nummer så att den stackars testaren inte ska behöva återtesta buggen i en version av programvaran där det inte ens var meningen att det skulle vara åtgärdat.
- Om du är programmerare och har problem med att få testare att använda buggdatabasen, acceptera då inte buggrapporter lämnade på något annat sätt. Om dina testare är vana att skicka dig e-post med buggrapporter, skicka då bara tillbaka e-posten med en kort uppmaning: "var snäll och lägg in det här i buggdatabasen. Jag kan inte hålla ordning på buggar i e-post."
- Om du är testare och har problem med att få programmerare att använda buggdatabasen, så får du helt enkelt låta bli att berätta om buggarna - lägg dem i databasen och låt databasen e-posta programmerarna.
- Om du är programmerare och endast ett fåtal av dina kolleger använder buggdatabasen, börjar delegera dem buggar i databasen. Så småningom kommer de att fatta vinken.
- Om du är chef och endast ett fåtal verkar använda buggdatabasen som du betalade dyra pengar för att få installerad, börja delegera nya uppgifter till de anställda med hjälp av buggrapporter. En buggdatabas är en fantastisk databas för "ännu ej implementerade funktioner" också!
- Undvik frestelsen att lägga till nya fält till buggdatabasen. Ungefär en gång i månaden kommer någon att få ett lysande uppslag till ett nytt fält som man kan lägga in i databasen. Du kommer att få höra alla möjliga klyftiga ideér, exempelvis att hålla reda på i vilken fil buggen hittades, notera i hur många % av testfallen som buggen uppträder, hålla koll på hur många gånger buggen har inträffat, hålla koll på exakt vilken version av alla DLL-er som var installerade på maskinen där buggen hittades. Det är väldigt viktigt att inte ge vika för sådant. Om du gör det så kommer ditt bugginmatningsformulär att innehålla tusentals fält som man tvingas fylla i och ingen kommer att vilja föra in buggrapporter längre. Om buggdatabasen ska fungera så måste alla använda den, och om det blir för mycket jobb att registrera en bug "formellt" så kommer folk att gå runt buggdatabasen.
Om du utvecklar programvara, om så bara i ett enmansteam, utan en organiserad databas som innehåller alla kända buggar i koden, så kommer du helt enkelt att leverera kod av låg kvalitet. Hos bra mjukvarutvecklare används inte bara buggdatabasen av alla, utan folk gör det också till en vana att använda databasen som sin egen personliga "att göra"-lista. De ställer in startsidan i sin webbrowser på sin lista över delegerade buggar och önskar så småningom att de kunde tilldela sin kontorschef buggar om att det behövs mer Jolt-cola till kontoret.
Originalartikeln på engelska heter Painless Bug Tracking
