I en strukturerad testorienterad organisation så är testplanen ofta något av dokumentet som inte får misslyckas. Många sätter för stor tilltro till planen som skall styra arbetet månader, ja i vissa fall år framöver. Du skall ha identifierat risker, luckor och framförallt kunnat lura ut hur lång tid hela arbetet skall ta.
Och det är här problematiken kommer in. Som vanligt är det arbetet med själva planen som är viktigare än själva dokumentet. Det är nämligen högst svårt och lurigt att se in i framtiden, speciellt när det gäller tiden som skall gå åt. Det är en svår balansgång att lägga tid på att försöka estimera tidsåtgången i ett större projekt och att inte göra det. Risken att misslyckas är stor, näst intill säker. Nu tänker du, ja det är ju bara en plan, såklart kan man inte veta allt från början. Men det som skrivs ner i just testplanen brukar projektledare och andra beställare ta för den maximala tiden som du får. Du har alltså “commit:at” dig i praktiken i en tidpunkt när du vet som minst.
Det finns ett ordspråk som säger: “Han planerade sin dag, sin vecka, sitt år , ja hela sin framtid. Men så kom livet emellan“.
Jag tycker en testplan hellre skall fokusera på typer av test, typer av kompetens och en grov plan vad för miljö som behövs. Att stå en tid in i projektet och komma på att vi behöver en server av typ X som tar minst ett par veckor att beställa och sätta upp kan få vilken testledare som helst att slänga in handduken och sätta sig i stupstocken.
Testplanen för att lyckas måste uppdateras under hela resan, du vet mer under tiden och eftersom nya förutsättningar kommer så är det bättre att ta dem i beaktning och styra om. I nästan alla projekt som jag har varit med i så skrivs testplanen en gång och är det dokumentet som läses minst men ändå när allt dras till sin spets är det som är har högst förväntning på sig.
Det viktigaste kapitlet förutom identifikation av testmiljö och kompetens är helt klart hur man har tänkt att se utmaningen, för allt testarbete kan liknas med ett problem, en utmaning som skall lösas och utföras. Taktiken “läs approachen” är det som jag försöker alltid förankra. Man kan göra allt på tusentals sätt och det är acceptans att denna taktiken är en lämplig ide som är det högst intressanta i en testplan. Att förklara varför just denna strategi är vald för just detta projekts utmaning är nyckeln till framgång. Saknas detta så dra i nödbromsen – risken är stor att problemet eller utmaningen om man vill är inte riktigt förstått eller genomtänkt.
Många gånger vill man ha in hängslen och livremmar. Att ha något att skylla på när planen fallerar (och den kommer att fallera – det är med i definitionen på en plan). Avsnitt såsom milstolpar och processer om t.ex. ingående kvalitet är för dålig. Problemet är ganska ofta att de processer som man vill ha med ofta inte är förankrade i organisationen. Det saknas oftast rutiner att vad händer om utvecklingen är sen när du har X dagar på dig för acceptanstest eller lasttest där man har hyrt in sig i en specifik testmiljö. Startvillkoren är oftast för snällt tilltagen och oftast får man sätta igång även om startvillkoren inte har uppnåtts.
Problematiken bygger på att testplanen bygger på en massa andra planer, där var och en av de planerna har en massa inbyggda risker “eftersom en av definitionerna på en plan är att den misslyckas eftersom den är en plan”. Detta bör man ha i åtanke när man planerar.
Till sist, är testplanen överskattad? Svaret är som ni kanske förstår både ja och nej. Planeringen är nyckeln för att lyckas, att identifiera nycklar och beredda vägen för en lyckad testinsats. Men, tilltron att det skall bli vad planen säger är för stor, speciellt bland de som kräver att det skall skrivas en plan. Inte sällan får man höra “ni har ju skrivit det i testplanen”. Motmedlet är att världen är för komplicerad att beskrivas i en plan, därav är det en plan. Jag hade gärna kallat testplanen för testtaktiken eller teststrategin istället. Det säger mer om syftet än just ordet plan.
Jag håller med dig, Bengt.
Testplanen ska bara beskriva övergripande vilken strategi man tänkt sig, vilka testtyper man behöver köra, vilka testnivåer testplanen täcker etc.
Det kan ju tänka sig att utvecklarna har något eget eller att acceptanstest har en egen testplan. Framförallt det sistnämnda eftersom det inte bör vara samma personer som kör acceptanstest som systemtest.
Detaljerna ska man skriva i iterationstestplanerna om man kör RUP. Gör man inte det finns det säkerligen andra alternativ som t ex “sprint-testplan”.
Bra artikel Bengt.
Det som jag tycker är lustigt kring testplaner är att vi redan innan planen ska skrivas ibland får reda på när vi ska vara klara med testning, hur många resurser vi får samt en klar bild av att man inte vet vad som ska göras. Sedan börjar man planera utifrån detta. Vad är det då vi planerar? Är det någon vits med att skriva hur många resurser vi fick eller ska man säga hur många man vill ha? Den verkliga planen finns oftast i andra typer av dokument eller på en whiteboard i testlabbet.
Testplanering liksom så mycket annat är ju faktiskt kontext-drivet och bör behandlas därefter. Typen av plan och innehållet bör ju kunna se olika ut beroende på vad man kan komma undan med.
Rikard har också skrivit en bra artikel om testplanen på http://thetesteye.com/blog/2008/02/test-plan-an-unnecessary-artefact/
Testplanen fyller ju ett syfte när det gäller att förankra avgränsningar och angreppsätt hos projektledning och andra intressenter. Däremot har jag aldrig förstått varför en testplan skall skrivas i löpande text. Punktlistor, flödesdiagram, färgmarkerade systemkartor m.m. gör jobbet minst lika bra i mitt tycke och minskar framtagnings kostnaden. Dessutom är det mycket svårare att uttrycka sig vagt i punktlistor, ord som iprincip och eventuellt slinker inte med på samma bekväma sätt.
Martin: Tackar!
Du är inne på ett intressant spår som jag försöker belysa. Det är när man frångår ordet plan och tror att det är facit eller realiseringen. Jag har aldrig förstått varför man inte kan göra iterativa testplaner beroende på utfall i projektet. Därför hoppas jag att man framöver byter namn till teststrategi eller något annat än just plan, bara för att visa skillnaden.
Jag ska gå in och läsa lite vad Rikard anser om testplanen. Tack för länken.
Eva: Det du är ute efter är en testplansnedbrytning. Det är ganska vanligt förekommande att man har en ”Master testplan” och bryter ner den i olika testtyper/aktiviter såsom systemtest. Hade man istället sett arbetet som en eller flera problemställningar så hade det fungerat bättre med att ha en strategi för att lösa problemet/en. Sprint-testplan är en underbar ide som borde praktiseras!
Tack för kommentaren.
Jonas: Formatet är oerhört viktigt i kommunikation. Långa texter utan bilder och färger gör hjärnan generellt ointresserad. Det är väl bara att läsa mina texter och jämföra med några av de nya inläggen här på TestZonen för att se skillnaden. Det blir med andra ord mer bilder och färg från mig fortsättningsvis. Man måste leva som man lär. 🙂
Det var visst Henrik som skrivit artikeln. Ber om ursäkt för felaktig referens. Oavsett så är den bra.
Martin: Ära den som äras bör! 🙂
Jag läste igenom den och jag håller med skribenten i det mesta. Kanske kan vi få Henriks åsikter i en utökad artikel här månne. Det finns fler synvinklar på artefakter som hör till V-modellen men som fortfarande åker med in i nya sätt att se dokumentation och styrning.
Bengt skriver många kloka ord om begreppet Testplan och det gör också andra kommentatörer. Vi har alla under årens lopp sett exempel på bra, medel, dåliga och till och med ingen testplan alls. Det sista (ingen testplan) är faktiskt det vanligaste läget och det ger ett lågt betyg när man utvärderar ett projekt eller organisation.
Alla kan nog hålla med om att testexekvering utan förberedelse (testplanering) inte är effektiv. Att vid leverans av testobjektet börja ställa frågor som Vad ska testas, Hur, Var och med vilka testdata och verktyg, vilka personer, låter ju inte effektivt. Så vi kommunicerar och förankrar med vår omgivning så att alla är överens.
På vilken detaljnivå vi dokumenterar har med värdet av detta som skiljer från projekt till projekt, branch eller företag.
Vår svenska skald Geiger sa “Det dunkelt sagda är det dunkelt tänkta” och då blir väl en följd av detta “Det ingenting sagda (avsaknad av Testplan) är det ingenting tänkta”.
Lean förespråkar ju detta med att vi inte ska ha någon Waste. Så tänk på vilket värde en Testplan har för en beställare, en QA person eller en framtida systemförvaltare eller testare.
Leif: Förberedelse är oerhört viktigt och själva aktiviteten att planera. Men, det är just perspektivet, vinklingen och mottagandet av Testplanen som jag har lite funderingar inför.
Just värdet är det som är intressant, precis som du skriver. Vi borde vara mer värde/nytto baserade i vårat arbete än att strikt bara göra saker som en process säger. Det gäller dock att förstå vem som är mottagaren av informationen.
De som inte förbereder eller planerar alls de spelar med väldigt hög risk att misslyckas.
Tack för kommentaren (och för Geigers citat)
@Leif:
Som jag ser det är det väl ingen i denna tråd som har sagt att testplanen ska göras “vid leverans av testobjektet”?
Sedan tycker jag att din tolkning av Esaias Tegnérs(!) citat är att ta det ett steg för långt, det är ju ingenting som säger att man inte kan ha planerat någonting bara för att det inte finns nedskrivet i ett dokument? Citatet är i sin hela form
Ett problem med testplaner, som Bengt tar upp, är att ett dokument av rang blir ett hinder när saker och ting förändras. Och ju större ett sådant dokument är, desto större chans att det inte blir uppdaterat. Dvs, en testplan eller annan plan är det uttänkta innan det ska ske. Men om det inte sker som förväntat, står man inför mer eller mindre problem. Och något ganska typiskt för mjukvaruprojekt är att det sker förändringar, välkomna eller inte. Och som Bengt också säger så är det oftast större chans att testningen blir utsatt eftersom den är beroende av många andra aktörer.
Som en sista brasklapp så tycker jag att det i vissa fall är helt nödvändigt att ha en “tung” testplan som behöver iakttas innan projektet drar igång. Detta är förstås helt beroende på projektets natur.
Mvh
Henrik Emilsson
Esaias Tegnérs citat föll bort ur min tidigare kommentar:
“Vad du ej klart kan säga, vet du ej; med tanken ordet föds på mannens läppar: det dunkelt sagda är det dunkelt tänkta.”
Jag sitter just nu med ett antal enormt stora testplaner (projektet varar ca 1½ år) som jag många gånger ifrågasatt värdet av. Det har slutat med att dom endast fungerar som övergripande beskrivning av omfattningen för att få någon form av godkännande från projektledningen att det är tillräckligt bra och att vi fått med allt. I viss mån ger dom även ytterligare information om hur teststrategin (som är ett eget dokuemnt) ska appliceras.
Det är dock otroligt svårt att få projektledningen att verkligen läsa dokumentet trots att det mest består av bilder och lättlästa texter samt att vi haft muntliga genomgångar och mycket diskussioner. Hur ska vi då veta att vi inte missat något?!? Jag blir dock tvingad till att använda dokumentet som “skydd” mot oss i test, vilket ändå är skönt att kunna ha. Har vi missat att testa något är projektledningen lika skyldiga som vi är. Det bör kanske nämnas att detta är ett projekt där det är otroligt lätt att missa stora och viktiga bitar. Testplanen blir då min fallskräm, hängslen och livboj. Tidplan och detaljer har plockats bort och hanteras löpande pga alla ändringar.
Då jag kört tester i Scrum-projekt har jag dock kastat testplanen helt och hållet! Allt finns ju på scrumtavlan. Visst, en övergripande testplan kan vara bra och ha men inte för varje sprint. Det tycker jag är helt och hållet slöseri med tid.
Sammanfattningsvis anser jag att testplanen är orerhört viktig i vissa projekt och helt värdelös i andra.