Är det en Bugg, en CR eller förbättrings förslag?
Min fråga är: Spelar det någon roll? Borde vi inte istället fråga oss om det är ett beteende i produkten som vi vill förändra eller ej?
Anledningen till att jag tar upp denna fråga är att jag i många projekt jag varit i kontakt med sett att väldigt mycket tid spenderas på att följa processen istället för att testa produkten eller på att agera på den information test tar fram. Ett exempel på detta är med vilken process man hanterar förändringar i systemet. Om vi genom vår testning kan peka på ett beteende i produkten som vi tycker är märkligt, så vill vi naturligtvis förmedla denna information snabbt och smidigt.
Ofta bollas informationen runt i stora system om man angett den som en bugg från början. Om någon bestämmer att det är ett förändringsförslag så kastas man ut ur buggprocessen och in i CR-processen, gärna med en tillhörande change control board som inte träffas så ofta. Samtidigt går tiden. Information är en färskvara med ett bäst före datum, problemet är att vi inte vet exakt vilket detta bäst före datum är. Därför är det väldigt viktigt att informationen som testningen tar fram faktiskt behandlas så fort som möjligt och att vi minimerar tiden som den slungas runt i processen.
Jag blir ofta väldigt imponerad (eller förskräckt är kanske ett rättvisare ord) när jag ser hur många olika status en bugg kan ha och hur buggen dribblas runt mellan dessa. Det kan ibiland tolkas som att man bygger en lång och komplicerad process bara för att faktiskt slippa ta itu med informationen. Om vi bara följer processen så kan ingen klandra oss för att vi inte gör något produktivt. Speciellt gillar jag statusen “works as designed”. För att citera min danske vän Carsten Feilberg: “Well, Mr Developer, maybe there is something wrong with your design then.”. “Works as designed” är bara en bakdörr för utvecklare att slippa göra om sin implementation, ett “get out of jail”-kort.
Ett annat problem med att inte behandla informationen direkt är att man ofta sparar den i ett fräckt bugghanteringsverktyg (gärna med dyra licenser kopplade till sig). Där slänger man ohämmat in alla buggar och så låter man dom ligga där tills någon behagar titta på dem. Dessa databaser blir snabbt stora och ohanterliga och efter ett tag börjar utvecklare klaga på att testaren lägger in samma bugg två gånger. Den naturliga lösningen på detta är då att säga åt testarna att dom måste säkerställa att den bugg dom hittat inte redan är inlaggd i databasen. Hur vore det om utvecklaren behandlade informationen direkt istället.? Detta resulterar i att alla testare spenderar en enligt min mening oförsvarbart lång tid att leta i en databas av gamla fel. Givetvis skriver inte alla personer samma sak i sina buggrapporter, så det är väldigt svårt att ta reda på om exakt den bugg man har hittat finns där redan eller ej.
Ofta ser man också att en utvecklare börjar kika på en gammal bugg och det första han gör är att skicka tillbaka den till test med frågan om buggen fortfarande finns kvar i produkten. Så nu ska vi testa samma sak en gång till för att ta reda på om informationen vi tidigare la in fortfarande är gilltig. Var det då lönt att vi testade detta första gången om vi ändå måste göra om det senare? Är inte detta slöseri med tid så säg.
Lösningen på detta problem är att behandla information direkt och inte spara undan den till senare. Ska något rättas gör det då direkt annars lev med beteendet. Undvik att spara information i oöverskådliga databaser. De sväljer allt och det är inte lätt att få en uppfattning om hur mycket relevant information som ligger där inuti. Har ni en sådan buggdatabas nu så släng den (bry er inte om att försöka rädda någon data som finns i den) och börja om från början, fast på ett sätt som passar er bättre.
En annan oönskad effekt av att inte behandla information från testningen direkt är att man ständigt bygger ny funktionallitet på en sedan felaktig och instabil kodbas, vilket leder till att man kontinuerligt adderar mer och mer skräp in i kodbasen och sakta men säkert bryter ner den.
Till min förvåning ser jag även projekt som kallar sig agila gå rakt in i denna fälla. Här har vi en beslutsfattare närvarande och tillgänglig i form av produktägaren som direkt kan proiritera och ta beslut utan några långa omvägar. Jag coachar för närvarande ett Scrum-team där vi förändrat vårt arbetsätt till att just agera på information från test direkt och som mål har vi att aldrig vid sprintavslut ha en lista med oanalyserade buggar. Därmed inte sagt att vi rättar alla buggar. Vissa beteenden väljer vi att leva med istället och så kastar vi buggrapporten. Vi sparar inte onödig information och vi använder inte något bugghanteringsverktyg. Vi har papperslappar på vår storyboard. Vi blandar inte heller in produktägaren i alla beslut att rätta en bugg eller ej, utan det är bara om det är ett beteende vi är tveksamma på som vi lyfter det vidare, annars rättar teamet den direkt. Vi ser att vårt arbete flyter på mycket smidigare när vi jobbar på detta sättet. Vi har förbättrat vår kodbas kontinuerligt. Vi spenderar ingen tid att leta i buggdatabaser utan vi lägger vår tid på att test produkten istället. Vi känner ett större värde av testningen och vi ökar efterhand vår tilltro till kodmassan.
Så mina två korvören är att frågan vi bör ställa är om det är ett beteende vi vill förändra eller ej och om vi vill ändra så gör vi det direkt. Skippa alla olika benämningar så som buggar, förändringar, förbättringar o.s.v. Skippa också onödiga tillstånd en benämning kan ha. Allt detta slöar bara ner processen och tillför inget värde. Är ni i stora projekt, bryt ner teamen till en hanterbar storlek och låt varje team ta ansvar för sin producerade kod, så att vi får snabbare komunikationsvägar.
Jag ser väldigt lite nytta med det sätt som man ofta hanterar dessa frågor på och tycker mest att det är ett sätt att fly undan ansvar och att slippa göra värdefullt arbete. Dessa processer är sjuka och vi behöver bota dem omgående. Mycket av det jag tar upp är inte vi testare direkt inblandade i, men min uppmaning är att följ inte en process som fungerar dåligt, utan jobba aktivt för att förändra den. Att blint följa med bara minskar en del av det värde som ni tillför som testare och gör ert jobb både tråkigare och omständigare och er själva mer utsatta.
Jag vet att det finns många som gillar fräcka, stora och komplicerade processer för att hantera detta och ni får gärna motbevisa mig i denna fråga.
Min fråga är: Spelar det någon roll? Borde vi inte istället fråga oss om det är ett beteende i produkten som vi vill förändra eller ej?
Anledningen till att jag tar upp denna fråga är att jag i många projekt jag varit i kontakt med sett att väldigt mycket tid spenderas på att följa processen istället för att testa produkten eller på att agera på den information test tar fram. Ett exempel på detta är med vilken process man hanterar förändringar i systemet. Om vi genom vår testning kan peka på ett beteende i produkten som vi tycker är märkligt, så vill vi naturligtvis förmedla denna information snabbt och smidigt.
Ofta bollas informationen runt i stora system om man angett den som en bugg från början. Om någon bestämmer att det är ett förändringsförslag så kastas man ut ur buggprocessen och in i CR-processen, gärna med en tillhörande change control board som inte träffas så ofta. Samtidigt går tiden. Information är en färskvara med ett bäst före datum, problemet är att vi inte vet exakt vilket detta bäst före datum är. Därför är det väldigt viktigt att informationen som testningen tar fram faktiskt behandlas så fort som möjligt och att vi minimerar tiden som den slungas runt i processen.
Jag blir ofta väldigt imponerad (eller förskräckt är kanske ett rättvisare ord) när jag ser hur många olika status en bugg kan ha och hur buggen dribblas runt mellan dessa. Det kan ibiland tolkas som att man bygger en lång och komplicerad process bara för att faktiskt slippa ta itu med informationen. Om vi bara följer processen så kan ingen klandra oss för att vi inte gör något produktivt. Speciellt gillar jag statusen “works as designed”. För att citera min danske vän Carsten Feilberg: “Well, Mr Developer, maybe there is something wrong with your design then.”. “Works as designed” är bara en bakdörr för utvecklare att slippa göra om sin implementation, ett “get out of jail”-kort.
Ett annat problem med att inte behandla informationen direkt är att man ofta sparar den i ett fräckt bugghanteringsverktyg (gärna med dyra licenser kopplade till sig). Där slänger man ohämmat in alla buggar och så låter man dom ligga där tills någon behagar titta på dem. Dessa databaser blir snabbt stora och ohanterliga och efter ett tag börjar utvecklare klaga på att testaren lägger in samma bugg två gånger. Den naturliga lösningen på detta är då att säga åt testarna att dom måste säkerställa att den bugg dom hittat inte redan är inlaggd i databasen. Hur vore det om utvecklaren behandlade informationen direkt istället.? Detta resulterar i att alla testare spenderar en enligt min mening oförsvarbart lång tid att leta i en databas av gamla fel. Givetvis skriver inte alla personer samma sak i sina buggrapporter, så det är väldigt svårt att ta reda på om exakt den bugg man har hittat finns där redan eller ej.
Ofta ser man också att en utvecklare börjar kika på en gammal bugg och det första han gör är att skicka tillbaka den till test med frågan om buggen fortfarande finns kvar i produkten. Så nu ska vi testa samma sak en gång till för att ta reda på om informationen vi tidigare la in fortfarande är gilltig. Var det då lönt att vi testade detta första gången om vi ändå måste göra om det senare? Är inte detta slöseri med tid så säg.
Lösningen på detta problem är att behandla information direkt och inte spara undan den till senare. Ska något rättas gör det då direkt annars lev med beteendet. Undvik att spara information i oöverskådliga databaser. De sväljer allt och det är inte lätt att få en uppfattning om hur mycket relevant information som ligger där inuti. Har ni en sådan buggdatabas nu så släng den (bry er inte om att försöka rädda någon data som finns i den) och börja om från början, fast på ett sätt som passar er bättre.
En annan oönskad effekt av att inte behandla information från testningen direkt är att man ständigt bygger ny funktionallitet på en sedan felaktig och instabil kodbas, vilket leder till att man kontinuerligt adderar mer och mer skräp in i kodbasen och sakta men säkert bryter ner den.
Till min förvåning ser jag även projekt som kallar sig agila gå rakt in i denna fälla. Här har vi en beslutsfattare närvarande och tillgänglig i form av produktägaren som direkt kan proiritera och ta beslut utan några långa omvägar. Jag coachar för närvarande ett Scrum-team där vi förändrat vårt arbetsätt till att just agera på information från test direkt och som mål har vi att aldrig vid sprintavslut ha en lista med oanalyserade buggar. Därmed inte sagt att vi rättar alla buggar. Vissa beteenden väljer vi att leva med istället och så kastar vi buggrapporten. Vi sparar inte onödig information och vi använder inte något bugghanteringsverktyg. Vi har papperslappar på vår storyboard. Vi blandar inte heller in produktägaren i alla beslut att rätta en bugg eller ej, utan det är bara om det är ett beteende vi är tveksamma på som vi lyfter det vidare, annars rättar teamet den direkt. Vi ser att vårt arbete flyter på mycket smidigare när vi jobbar på detta sättet. Vi har förbättrat vår kodbas kontinuerligt. Vi spenderar ingen tid att leta i buggdatabaser utan vi lägger vår tid på att test produkten istället. Vi känner ett större värde av testningen och vi ökar efterhand vår tilltro till kodmassan.
Så mina två korvören är att frågan vi bör ställa är om det är ett beteende vi vill förändra eller ej och om vi vill ändra så gör vi det direkt. Skippa alla olika benämningar så som buggar, förändringar, förbättringar o.s.v. Skippa också onödiga tillstånd en benämning kan ha. Allt detta slöar bara ner processen och tillför inget värde. Är ni i stora projekt, bryt ner teamen till en hanterbar storlek och låt varje team ta ansvar för sin producerade kod, så att vi får snabbare kommunikationsvägar.
Jag ser väldigt lite nytta med det sätt som man ofta hanterar dessa frågor på och tycker mest att det är ett sätt att fly undan ansvar och att slippa göra värdefullt arbete. Dessa processer är sjuka och vi behöver bota dem omgående. Mycket av det jag tar upp är inte vi testare direkt inblandade i, men min uppmaning är att följ inte en process som fungerar dåligt, utan jobba aktivt för att förändra den. Att blint följa med bara minskar en del av det värde som ni tillför som testare och gör ert jobb både tråkigare och omständigare och er själva mer utsatta.
Jag vet att det finns många som gillar fräcka, stora och komplicerade processer för att hantera detta och ni får gärna motbevisa mig i denna fråga.
Det är lite lustigt då jag sitter mitt inne och är med och skapar en ändringshanteringsprocess. När vi skapar den så har jag satt upp ett par ledord som vi bör pröva alla ingående pilar och bubblor mot samt själva metadatan som vi ska ha i verktyget (Quality Center).
De främsta ledorden är enkelhet och minimalism. I många processer och verktyg så implementeras en jätteprocess som ska klara alla olika händelser som bara kan tänkas. Jag har sett ett projekt som hade runt 30-35 olika metadata som man var tvungen att skriva i för en CR. Kostnaden för att driva runt en sådan process med ett antal CR’s måste vara enorm.
Jag är vän av problemlösning, sätt upp problemet, lös det på bästa sätt. I många fall vill man ha verktyg som gör att man kan få ut data i form av mätetal och rapporter samt att inget hamnar mellan stolarna. Men i vissa projekt skulle man kunna sköta det på ett sådant sätt som du beskriver.
Henrik, tack för en och intressant och välskriven artikel. Det lustiga är att jag precis som Bengt är mitt uppe i att ta fram och implementera en ändringshanteringsprocess. Även i mitt fall så implementerar jag processen i Quality Center. Det som slår en generellt är om man frågar ett antal testledare vilka status de behöver, så får man alltid svaret så få som möjligt, men får ofta ett 15-tal status som minsta möjliga. 15 olika status på en felrapport, det är lite absurt och tyder som Henrik säger på att man fokuserar mera på process än på kvalitetssäkring.
Att som i Henriks fall inte använda något felhanteringsverktyg alls skulle vara en dröm, men tyvärr tror jag bara fungerar i små nyutvecklings projekt som sitter geografiskt samlade och utan kopplingar till allt för många gamla system som ligger i förvaltningsfas. Om man tar ett stort projekt och splitrar det på mindre utvecklings team som behandlar sina felrapporter så är allt väl så långt. Men hur hanterar vi alla de integrations fel som kommer att uppstå mellan teamen och mellan andra system. Och fel som kommer från systemtester som spänner över funktionalitet från flera team. För dessa fel tror jag att det behövs ett felhanteringssystem. Detta felhateingssystem kan ju sedan med fördel vara lätviktigt och utan dyra liscense kostnader.
Ojojoj; det var en provocerande salva som var kul att läsa.
Jag är helt för lättviktiga processer, och så nära samarbete med utvecklarna som möjligt utan hindrande processer.
Och du har rätt i mycket av kritiken, men ett buggsystem skulle jag inte vilja vara utan, bland annat av dessa orsaker:
* det är bra med öppenhet, så att alla kan se rapporterna och ibland även hjälpa till
* fler än testarna och utvecklarna kan rapportera fel och förbättringsmöjligheter
* det går att använda gamla buggrapporter för att komma på nya testidéer
* det går att använda buggrapporter för regressionstestning
* man hittar gamla buggrapporter, och behöver inte rapportera dem igen
* när man ser ett konstigt beteende kan man få hjälp av gamla buggrapporter
* support-avdelningen kan söka i buggsystemet och få hjälp att hjälpa kunder, ex. work-arounds
* det går att analysera buggdatan och förstå mer av utvecklingsarbetet (OBS! Inte metrics, utan analys med kunskap om detaljerna)
* det går att referera till buggar när man ska rapportera status
* jag är rädd att jag skulle glömma någon aspekt av buggen (eller sidoeffekter) när jag ska verifiera fixen
* nya testare kan titta på buggar för att lära sig produkten och dess komplexitet
* man kan skriva ner hur man fixat en bugg, så kan utvecklare få hjälp att fixa liknande buggar i framtiden
* man kan skriva ner varför man valt att inte fixa en bugg
* ingen risk att post-it-lappen blåser bort så att en bugg glöms bort
Alla dessa saker kan naturligtvis åstadkommas på andra sätt, men en välskött buggdatabas med utmärkt sökfunktionalitet kombinerar många av dessa saker på ett effektivt sätt.
Att klara sig utan ett buggsystem funkar nog bäst om man är en testare och en utvecklare, med perfekt minne, utan support-avdelning, och helst med en enda release.
Mina tidigare kollegor och jag har diskuterat denna fråga flera gånger också. Vi bestämde oss då för att behålla Bug och Enhancement, där en Enhancement kunde vara en alternativ väg som inte överensstämde med nuvarande design. Det betydde då ofta att man i dagsläget inte såg denna som intressant, men att den kunde vara det för en framtida release. Sedan var det lite olika med om projektledare faktiskt undersökte dessa vid projektuppstart/inkrementstart eller ej, men vår original tanke kändes ändå som den var god.
Jag håller med helt om att för många olika status ställer till problem. Jag vill dock inte slopa status helt för i personers sinnen behandlar vi ändå buggar som om de har olika status. Vi är intresserade om en bugg som vi trodde var stängd faktiskt har kommit tillbaka, om en bugg är planerad att inte bli fixad osv.
Sedan tycker jag det är viktigt med ett buggrapporteringssystem. Om man har produktutveckling där man förbättrar samma produkt eller att man utvecklar inom samma domän så är buggsystemet en stor informationsbärare. Du kan hitta otroligt många godbitar. Jag tror inte man behöver använda post-it-lappar för att få upp snabbheten kring buggar. Vad är vår smärtgräns för att hålla reda på buggar i huvudet? Om vi är uppe i buggmängder som rör sig kring 50000 buggar så anser jag att ett buggsystem är ett måste.
Jag tycker det är lite roligt att komma ihåg bra/roliga buggar, som sedan dyker upp i ny kontext. Genom bra analys verktyg kan du också söka och gruppera buggar för att vidare hitta nya problemområden. Men som sagt, det är ju helt olika från företag till företag. Man ska t.ex inte underskatta när testteamet har sin dagliga buggquiz (“Vad handlade buggen ‘Magic 8 appears from nowhere?’ om?”)
Det är också helt klart att syftet med buggsystemet kan vara olika. Är syftet ha en snabb och smidig hantering av buggar, att lagra buggar, är det att ta reda på var man hittar buggar? T.ex så använde vi Trac i ett projekt nyligen. Det var endast temporärt och när projektet var klart så fördes öppna buggar över till kundens system. Syfte med buggsystemet i det fallet var att snabbt kunna hantera buggar, där vi inte särskilde bugg från enhancement. I en sådan situation vill man inte ha en tungrodd process.
Nu har Henrik upprört en massa känslor hos testledare som älskar ordning och reda, felrapportstatistik och processer som får stöd av lämpliga verktyg. Och det är kul för det skapar engagemang, debatt och ifrågasättande om vilket värde testadminstration har.
Som vanligt värde gentemot kostnad.
Henrik har tydligen varit med om att ingen utanför rummet och utanför synhåll från från Whiteboard tavlan med gula lappar vill veta vad man upptäckt under testarbetet, oavsett om man kallar det fel, avvikelse, problem, issue, CR. Ingen har informationsbehov om antal, fördelning på sevrity, priority, delsystem, release eller annat som man kan analysera och dra lärdom av.
Undrar när jag hamnar i ett sådant projekt? Finns sådana?
Vad roligt med så många bra och värdefulla komentarer, Tackar!
Fler välkomnas med tacksamhet 🙂
Jag är inte i sig emot att ha en bugghanteringsystem. Jag menar mitt exempel med lapparna är också det ett system. Det jag beskrev var naturligtvis en extrem åt andra hållet och jag förespråkar verkligen inte att folk ska ta och kopiera det sättet rakt av. Det kan gå lika fel det med!
Det jag ifrågasätter är det faktiska behovet av det tungrodda processer som man ofta kopplar på verktyg. Man gör något väldigt komplicerat av något som i grunden inte är så svårt. Jag ska inte ens en gång ge mig in i metrics aspekten på detta.
Vad jag skulle önska är att alla ifrågasatte sin process och skapar en proces som utgår ifrån de grunder som man vill uppnå och skalar bort allt annat. Anpassa er process utefter era behov och ändra den när behoven ändras. Det finns inte en standardlösning eller ett verktyg som alltid är bäst (det finns många som försöker hävda att detta finns). Värdesätt och främja komunikation, försök inte bygga bort den. Se till att ni har de hjälpmedel som ni har behov av, varken mer eller mindre. Uppnår ni det så har ni kommit väldigt långt och tillhör de få.
Att använda sig av QC eller IBMs test management verktyg ser jag som en direkt inkörsport till att gå ner sig i skiten. Då det finns så mycket tröghet inbyggda i dessa system. Dessa verktyg börjar i fel ända och trycker en in i ett arbetssätt (ja dom hävdar att dom är anpassningsbara och flexibla). Det går säkert att med en hel del meckande komma runt detta men jag har inte sett några sådana implementationer och verktygen leder en inte i den riktningen.
Att spara massor av information och säga att den är tillgänglig för alla syftar ofta precis på samma sätt som med dokumentation till att vi ska slippa prata med varandra. Jag föreslår istället att vi bygger upp vårt sätt att arbeta på just komunikation och sen lägger till de tekniska stöd vi behöver för att stödja vår kommunikation. Inte med utgångspunkten att undvika att komunicera som många av denna typen av processer har.
Vill vi lära oss så finns det mycket effektivare och bättre sätt att ta till oss kunskap på än att läsa gamla dokument eller buggrapporter.
Rickard- där finns mycket intresant i din lista och absolut saker som man vill kunna dra nytta av. Dock så vänder jag mig mot din första punkt ”det är bra med öppenhet, så att alla kan se rapporterna och ibland även hjälpa till”. Inte punkten i sig för den är otroligt viktig utan detta är mitt främsta argument för att inte samla mängder med buggar i en databas. Allt bara grumlas och även om databasen är öppen så ligger det så mycket brus i den så synligheten minskar och det blir väldigt tidskävande och kostsamt att faktiskt få ut värdefull information. Jag skanar just tillgänligheten och visualiseringen av informationen.
Ofta så är det lätt att komma på massor av olika aspekter på vad man skulle vilja få ut ur ett felhanteringssystem men om vi ser praktiskt på det så är min känsla att det är väldigt sällan som man faktiskt använder sig av dessa aspekter som man från början säger att man vill ha tillgång till.
Men som du skriver, en välskött databas kan ibland visst vara bra att ha!
Martin- Bra skrivet. Ni böjade med att ifrågasätta vad ni behövde och bestämde er sen för att köra på ett spår, kanon!
Däremot ifågasätter jag verkligen vilken praktisk nytta ni har av en databas med 50000 buggar i. Min gissning är att mycket av den datan som finns där är obrukbar då systemet har förändrats så mycket över tiden och att buggarna är skrivna på så många olika sätt så det är svårt att hitta korrelation. Visst kan man säkert hitta en och anna gobit där men ur vilken del av datan är det ni hittar det, gissningsvis inte den äldsta. Vad kostar det er att faktiskt analysera all denna data, eller är det så att ni faktiskt inte analyserar all data utan bara tittar tillbaks på den ”färskaste”? Finns det inget annat ni kan investera er tid i som skulle ge bättre verkan?
Leif, tack för att du ger dig in i leken!– varför skulle någon annan ha intresse av den informationen om jag redan rättat buggen?
”informationsbehov om antal, fördelning på sevrity, priority, delsystem, release eller annat som man kan analysera och dra lärdom av”. De mertics som ofta används i dessa sammanhang är ändå bara buffel och båg och ett sätt att lura våra intresenter genom att visa upp siffror som ändå inte beskriver det dom utger sig för att vara.
Givetvis så måste vi tillgodose våra intresenters behov men jag tycker inte att vi gör det genom att slänga upp grafer och nyckeltal till höger och vänster. Hur vore det om vi istället riktade den information till de som behöver den och att vi beskrev informationen på ett sätt som ärligt och faktiskt avspeglar den data vi har. Vi från test sitter ofta på väldigt värdefull information och en viktig del i vårt jobb är att förmedla denna information på ett begripligt sätt till våra intresenter utan att vilseleda eller dölja.
Jag är med dig i stort, men tycker kanske att din uppmaning är lite väl subtil.
Att anpassa metoden efter rådande kontext är det viktigaste!
Om jag jobbar i ett projekt där man kör med ett buggsystem á la BugZilla, och utvecklingen kör nån agil utvecklingsmetodik, så brukar jag förorda att programmeraren väljer vilken metod som passar bäst för rapporteringen av buggarna. Om det rör sig om första testerna under en sprint, så kanske det funkar bäst att skriva ner one-liners på ett papper eller i ett mail (det torde gå snabbast för oss alla). Är det i redan releasat bygge så kanske det är bäst om de rapporteras in i bugzilla för att programmeraren inte håller på med det för tillfället och blir ett störningsmoment. Om jag har rapporterat in på papper/email först så brukar jag och programmeraren göra upp om att de buggar som inte kan fixas direkt rapporteras in i bugzilla; detta för att de inte ska glömmas bort.
Jag försöker med andra ord bidra med servicen testning utan att öka på med mer administration än nödvändigt. Ibland får jag höra att det är vi testare som “vill ha buggsystem”, men det stämmer inte för min del. Jag kan tycka att det i många fall är just ett klumpigt och på tok för administrativt krävande system. I andra projekt är det dock helt ovärderligt! Jag har också jobbat som ensam testare i team där jag har suttit i Sverige och andra i teamet har suttit i USA, Indien, England, Finland, osv. Förutom att vi inte jobbar fysiskt tillsammans, så kan ju andra barriärer finnas: Språk, tidszoner, etc. Då kan det kanske finnas fog för (och en vits med) att formulera något så tydligt som möjligt i ett buggsystem. Dvs den innebodda trögheten kan vara positiv för att man undviker slarv.
Så återigen, att anpassa metoden efter rådande kontext är det viktigaste!
Känns inte så sexigt att lägga in kommentar nr 8 men jag kan inte låta bli. Underbar artikel och fantastiskt bra kommentarer! Jag tror sanningen ligger i summan av artikeln och alla dess kommentarer. “Lyft blicken, våga ifrågasätta men var inte korkad”, typ. Kul med ett forum för sådana här frågor! Test Hard!
Jag ger mig i kast med frågan bugg, CR eller ändringsförslag. Den metod jag försöker använda dagligen är att prata om en sak är ett problem eller ej. Visst är det Bachs/Boltons defininition. Vissa felrapporter är så uppenbart fel – beräkningar, saknade data etc – så dessa behöver inte diskuteras. Det intressanta är alla de rapporter jag skriver som är mer subjektiva. Första steget är att jag har klippt alla känslomässiga band till mina felrapporter. Om de inte korrigeras – trist – men jag deppar inte (som jag gjorde förut!). Jag påpekar så ofta jag kan, varje gång jag diskuterar med beställare eller användare att det inte är mitt beslut. Jag har rapporterat något jag anser kan vara ett problem i slutprodukten. Nu är det deras ANSVAR att besluta om åtgärd. Just ansvarsfrågan är nyckeln tror jag. Jag säger ju mer eller mindre direkt att om det blir gnäll så är det de, inte jag, som är orsaken.