Jag sitter idag i ett projekt som pågått ett halvår. När jag kom in i det som enda testresurs (idag har jag en side-kick) fanns inga testaktiviteter gjorda och inga gamla testprocesser fanns att tillgå hos kunden. Jag fick börja tänka från noll, blankt blad, tabula rasa.
Min första reflex var att lägga in en massa dokument, mallar och aktiviteter i en plan. Min verktygslåda är sedan ett par år i yrket full av smarta processer och verktyg såsom kravgranskningar, intelligent testdesign, utforskande test, pedagogiska avrapporteringar, mm, mm. Jag ville ha med allt. Sen upptäckte jag verkligheten. Tidsbegränsningen.
Att testa i ett agilt projekt, att vara systemtestare för ett utvecklarteam på 5-10 utvecklare handlar inte om att följa alla regler och riktlinjer utefter vad som är det bästa valet ur en ideal värld. Nej, eftersom vår tid är begränsad handlar det istället om att vara medvetenheten kring vilka verktyg vi KAN använda när problem uppstår. Kravspecifikationerna i ett agilt projekt utvecklas på liknande sätt. De författas kanske först grovt i ett par användarscenarion och sedan detaljeras de ytterligare under resans gång utefter våra behov.
På samma sätt utvecklas min testprocess likt en levande organism, där jag tar beslut kring granskningar och testverktyg utefter resans gång. Jag tar inte in någonting som jag inte ser ett klart syfte med. Jag väljer bort sådant som bara anses som “det är så man borde göra” till förmån för allt som jag måste göra.
Jag anser att vårt jobb som testare har ett och endast ett syfte och det är att ta reda på information om testobjektet och presentera denna för våra intressenter. Ser jag inte att den aktivitet jag tänkt göra på något sätt faller in i denna arbetsbeskrivning, då är det antagligen inget som jag bör lägga tid på.
Så, mitt processtips:
- Börja med en enkel processidé,
- testa din process,
- lär dig av processen och iaktta resultatet
- identifiera nödvändiga förbättringar och implementera dessa
Jag har sedan länge förstått att jag aldrig kommer att uppleva den optimala processen, alla förbättringar kommer aldrig att hinna implementeras, men efter ett bra tag kommer jag kanske komma tillräckligt nära. Fast bara tills förutsättningarna ändras, vilket de alltid gör i vår bransch. Ingen kan därför heller säga att de har uppfunnit den ultimata processen som passar alla, eftersom alla utvecklingsprojekt har olika förutsättningar. Motbevisa mig gärna.
Som ni kanske inser applicerar jag samma regler på testprocesser som jag använder mig av när jag testar varför jag brukar benämna detta processtänk som “Utforskande processutveckling”
För att citera den första principen i den kontext-drivna skolans manifest:
The value of any practice depends on it’s context
Det är väl precis vad det här handlar om, att anpassa sitt arbetssätt efter vad projektet kräver och tillåter.
Det svåra i det hela är att utvärdera metoden tycker jag, speciellt om man jobbar som enda testresurs i ett projekt. Vilka frågor ska man ställa sig själv? Hur mycket tid ska man ge en idé innan man överger den? Det handlar väl mycket om erfarenhet och hur min egen verktygslåda ser ut.
Ett annat problem som jag ser är om utrullningen av en process kostar mycket i form av tid och pengar.
Då kan det bli kostsamt om man inte gör ett ordentligt upfront-arbete, och försöker skapa en robust process.
Så klart kommer man inte att nå den optimala processen, och det kommer ändå att krävas omarbetningar över tiden, men kanske inte lika mycket som om man rullar ut en halvfärdig process som man sedan måste omarbeta om och om igen när små förändringar sker.
Sen måste man så klart vara försiktig med att överarbeta processen. Att detaljera för mycket ger ofta i min verklighet ingen return-of-investment, eftersom detaljerna ändras kontinuerligt. Men med ett robust processramverk som är tillräckligt flexibelt så brukar det lösa sig.
Detta är ofta min verklighet när processen ska nå ut till flera hundra personer, och utrullningen tar flera månader att slutföra. Men i fallet när man är en eller ett fåtal testare, så är så klart det du beskriver säkert ett bättre tillvägagångssätt.
Då kan man ju fråga sig hur man tror att man ska lyckas hitta en process som ska passa flera hundra personer som, förmodar jag, sitter i olika projekt. Olika typer av projekt mår olika bra av en standardiserad process.
Vad en sådan utrullning av en gemensam process förmår är väl att försöka likrikta projekt som då får lägga energi på att passa in sitt eget arbetssätt till det gemensamma. Ger det en vinst för projekten eller är det högre upp i organisationen man tror sig vinna något?
Jag vill inte vara helt kritisk egentligen. Jag kan förstå värdet av en övergripande, gemensam, processbeskrivning i stora organisationer så länge den inte befattar sig med arbetsrutiner och projektdetatljer.
Vad man snarare borde uforma är kanske en kommunikationsplan.
Vilken information behöver vi från varje projekt och hur ska informationen kommuniceras? Vilka är de riktiga intressenterna till det individuella projektet?
Tack för era intressanta och genom tänkta kommentarer Oscar och Johan! Jag kom på en annan aspekt av det hela. Människan tenderar ofta till att vara trygghetssökande och är en projektledare eller linjechef van vid att vi gör saker på ett visst sätt eller om de är vana att få en viss rapport så vill de gärna ha det så även i framtiden, oaktat om syftet av aktiviteten eller informationsvärdet av rapporten kvarstår. Det är således lättare att lägga till aktiviteter och steg i processen när behovet blir tydligt än att ta bort onödiga steg.
Cosmo: Min första kommentar syftade till när hundratals personer sitter i samma projekt, vilket ofta kan vara fallet i min verklighet.
Fredrik: Det är definitivt någonting jag också har sett. Projektledaren/linjechefer har vant sig vid att fatta beslut efter ett KPI/aktivitet, och trots att man förklarar att detta KPI inte säger någonting längre, så används ändå KPI:et som underlag för beslut.
Ja, jag ska inte vara så skenhelig. Jag kan glatt erkänna att jag själv känt dåligt samvete när jag slutat att skriva testrapporter som jag iofs känt att ingen läst eller brytt sig om längre. Jag har som testledare också känt en gnagande oro när vi skippat onödiga steg i processen, men jag har ännu inte varit med om att ett väl avvägt avsteg från processen visat sig vara en dålig idé i slutändan.