Olika perspektiv inom test

 

Solna-solna

Jag älskar att jobba med test. Jag älskar att jobba som konsult. Och jag älskar kombinationen, det är så enormt skönt att ha ett enkelt nätverk av testare som arbetar i olika organisationer och som hela tiden utmanar mig att tänka nytt. För test handlar om nytt. Test handlar om att hela tiden våga tänka ett steg till, att utmana sina fördomar och göra allting på ett helt nytt sätt. Hela tiden.

 

Av någon helt oförklarlig orsak så kan man bli insåld till nästan vilket bolag som helst när det handlar om test. Har du systemtestat tågsystem så är du kvalificerad för bankens integrationstest. Har du unittestat kommunikationslänkar så är du ett självklart val som prestandatestare i ett ekonomisystem. Och i ärlighetens namn så finns det likheter i angreppssättet, en bra testare har oftast ett tänk som klarar sig mellan olika branscher och testnivåer. Men det finns skillnader, stora sådana och jobbiga gropar att falla i. Den här artikeln är tänkt att handla om dem och att på olika nivåer ställa två specifika tänk emot varandra. I min värld så är nämligen testernas grundfilosofi oftast uppdelad i två hyfsat motsatta förhållningssätt.

Den första och den mest komplicerade vattendelaren

Handlar om de fundamentalt olika sätt att hantera krav och användbarhet som man råkar ut för.

När den ursprungliga kravspecifikationen styr utvecklingen

Vi vill bara leverera – gör tillräckligt med tester för att projektet ska kunna avslutas, skit i om resultatet fungerar eller är användbart.

I ganska många projekt är kravet på att nå i mål mycket högre än kravet på att åstadkomma någonting användbart. Handlar det tex. om en leverantör som levererar till en extern kund så tycker företag ofta att det är dåligt att leverera en komplett och genomtänkt lösning – ”nej, fixa inte det där nu, det kan vi ta betalt för i förvaltning”. Eller, ”ja det är ju en urkorkad produkt som inte kommer att möta kundens behov, men det här står i kravspecen”.  Ah, ni förstår vad jag menar. Att jobba i en organisation som tänker så här kan vara rätt dödande för kreativiteten och arbetsglädjen. Det är liksom aldrig roligt att vara med och skapa någonting oanvändbart. Det är inte roligt att vara delaktig i produkten ”Kalles Kaviar med banan”. Eller hjärnkirurgilasern som lyser coolt, men som när den ska säkerhetsvalideras inte ens visar sig vara säker nog för att användas till försök med möss.

Den totala motsatsen för mig är när man springer mot ett rörligt mål, när teamet vill åstadkomma någonting revolutionerande och där slutprodukten inte har särskilt många kopplingar till de ursprungliga kraven.

Affärsdriven utveckling

En del organisationer är extremt affärsdrivna och det där med krav och eftertanke kanske inte är det som startar upp ett projekt. Man har ett behov och kanske en lösning – och så drar man igång. Ibland kanske man inte ens är intresserad av att ha en kravspec. Organisationen känner inte att man behöver täcka några formella krav, mottagarens godkännande är det enda viktiga. Teamet jobbar nära slutanvändaren och ständig kommunikation förändrar man och förfinar designen. Det är inte alltid helt lätt att vara delaktig i en produkt där de dokumenterade kraven inte helt överensstämmer med vad produkten levererar. Man går glad i hågen hem en kväll med sinnet fyllt av glädjen att äntligen skrivit klart alla tester – och när man börjar testa dan efter så visar det sig att alla testfall är felaktiga eftersom man ändrat en grundfunktion utan att berätta det för alla. En sån här miljö kan vara superfrustrerande att jobba i även om resultatet när det väl är klart känns bra.

Vilket är bäst (eller kanske minst dåligt)

Jag tycker mig ha arbetat med produkter i båda de här lägren. Min personliga läggning gör det lättare för mig att hantera scenario två i det här fallet, men det går, även för mig att komma fram till förhållningssätt som gör att jag kan hantera båda två.

När det gäller kravstyrd utveckling så är det i alla fall för mig viktigt att tänka mig produkten som ett steg på vägen. Att se de prydliga stegen som leder upp till en fungerande produkt och där varje avsats är ett delmål på väg mot toppen. Ibland kan jag känna mig tvungen att acceptera att min slutanvändare som jag vill tillfredsställa är projektledaren och att produkten som jag levererar är en prydlig dokumentation, en bevisföring enligt alla konstens regler på att kraven som fanns är uppfyllda. För att jag ska känna mig helt nöjd i ett sådant här läge så krävs det ofta att jag får lämna in en lista på framtida förbättringsförslag eller ett retrospektiv med mina synpunkter, där jag fått formulera mina visioner om superprodukten, den jag egentligen skulle vilja göra. Ibland finns det någon som tar emot ett sådant retrospektiv. Ibland får man leverera det till någon nära vän på krogen. Men i vilket fall så är det skönt att göra, det är mitt sätt att behålla min yrkesstolthet.

När det gäller affärsdriven utveckling så handlar väldigt mycket för mig om att förstå slutanvändarna. Det är mycket mindre frustrerande att ändra allt man har åstadkommit ifall man förstår hur brilliant ändringen är – Och det är mycket lättare att mota bort korkade förändringar ifall man kan ge bra förklaringar på varför en ny feature är värdelös. Mycket handlar om att själv vara delaktig i kommunikationsprocesserna, att inte vara den där som får reda på allting sist. Och att planera sitt eget arbete utifrån att målet är rörligt, att inte hänga upp sig på en struktur som inte finns. När det gäller att skriva testfall så försöker jag oftast få ett godkännande på min bild av kraven – jag skriver helt enkelt en egen förenklad kravspecifikation eller så är jag övertydlig i mitt testande och ser till att användare, utvecklare, chefer och typ alla som jag hittar får höra hur jag tänker och godkänna mitt förhållningssätt till vad jag testar och hur.

Vattendelare nummer två

Vilken typ av data hanterar produkten i fråga – hur komplex är den?

De första systemen som jag testade utgick ifrån att det fanns ett antal tillstånd som produkten kunde befinna sig i. Kombinatoriken kunde vara komplicerad men ändå på något sätt förutsägbar. Det fanns helt enkelt ett begränsat antal parametrar som kunde skilja sig ifrån fall till fall. Det gick att kalkylera antalet kombinationer som måste testas för att man skulle ha en hyfsad kravtäckning. Ett bra systemtest gick ut på att med en bra filosofi hitta minsta möjliga kombinatorik att testa och sedan skapa alla de testfall som behövdes. Efter ett utfört och godkänt test skulle samtliga kombinationer fungera, dvs systemet skulle kunna hantera allt. Om något saknades så skulle det skrivas bra förklaringar på varför just detta scenario var så ovanligt och otänkbart att det var OK att releasa produkten även om inte just detta scenario fungerade.

Döm om min förvåning när jag började integrera ekonomisystem, med milliontals poster som kunde innehålla kombinationer som jag inte ens kunde drömma om. Tänk att man kunde göra tester med all kombinatorik som man förutsätt och sen köra en riktigt batch med testdata och få tusentals fel dokumenterade i felloggen. Det var nytt. Och tänk att det fanns system där det var helt i sin ordning att vissa data krävde manuell hantering. En lyckad leverans kanske betyder att man har kontroll på hur mycket manuellt felkorrigerande ett system kräver. Bara det att ett system är så stort och komplext att man väljer att inte förutse vilka kombinationer som kan finnas gör testandet väldigt annorlunda. Med behov av att skaffa fram testdata som t.ex. är en avpersonifierad fil ifrån produktion. Att mängdtesta och hoppas på att man täckt det mesta. En test där mycket handlar om att göra riskhantering, att bestämma hur man ska hantera eventuella fel, vilka fel-scenarios som finns, hur man ska hantera dem och hur kritiska de är. Vad får inte gå fel? Vad får gå fel? I den normala produktionen. Vad får absolut inte hända?

För mig är det här en annan gigantisk skillnad mellan olika sorters tänk. Jag vet inte om andra upplever samma avgörande skillnad, men jag ser inte många likheter mellan att jobba med system som fungerar på endera sätt.

Den tredje vattendelaren

Att jobba på testavdelning eller som ensam testare i team.

I mitt första konsultuppdrag så projektledde, utvecklade, testade och godkände jag kommunikationslänkar. D.v.s. det fanns en kund någonstans som beställde en produkt, internt hos min uppdragsgivare så plockades ett system ihop av lite hyllprodukter, special-anpassningar och ett kommunikationsinterface mot övrig utrustning som levererades av någon annan. Kommunikationslänksarbetet överlämnades till mig. Jag fick en specifikation, pratade med de som anpassade hyllprodukterna och fick reda på hur jag skulle prata internt och så pratade jag med de som levererade resten. Sen utvecklade jag min testmiljö, min kommunikationslänk och så slutligen så åkte jag någonstans i världen med min testmiljö och testade mot de som levererade resten. I det stora hela så testade jag enbart för min skull, med den kvalitet som jag själv ansåg som acceptabel. Väldigt praktiskt.

Ensam är stark – eller?

Ofta hamnar man som testare/testledare i ovannämnda situation fast med det lilla tillägget att man bara är testare. Det är andra människor som har rollerna utvecklare och projektledare. I den här sitsen så handlar mycket när det gäller test om att dels få projektledarens tillit så att man har en möjlighet att vara så obekväm som det behövs, dels att själv hitta nivån på hur bra testat behöver det här systemet egentligen vara? Man sitter i en ganska knivig sits mellan en ansvarig som har krav på sig om att få projektet i mål på utsatt tid och till utsatt kostnad och ett behov av att få göra sitt jobb med så hög kvalitet som det behövs vilket ofta betyder att projektet blir både försenat och dyrare än planerat. Inte alltid, men det kan hända. Den här rollen kräver helt enkelt ganska mycket mod, flexibilitet och lyhördhet för vad som krävs i just den här organisationen, med den här projektledaren. Man är grovt uttryckt projektledarens bitch – hur man än jobbar så måste projektledaren ha tilltro till att det man gör är bra både för projektet och för projektledaren.

Ju fler vi är tillsammans…

Den diametralt motsatta testrollen är den som finns i en stor testorganisation där test sitter samlade gemensamt och där testavdelningen levererar resultat ut i organisationen. Projekten som drivs kommer med önskemål in i testorganisationen, testorganisationen bestämmer vilka som ska utföra arbetet – och på vilket sätt arbetet ska utföras. I den här organisationen är det ganska enkelt att vara ny och oerfaren. Det finns färdiga processer, det finns andra att fråga och det finns sist men inte minst ett ramverk att luta sig mot. Det är inte jag personligen som bestämt hur ambitiöst jag testar något – jag följer bara den process som är skapad. I den här formen av arbete så har man den oändliga glädjen att få samarbeta med andra testare och möjligheten att vidareutveckla testandet till nya nivåer. Å andra sidan så blir det viktigare med gemensamma processer och man kanske inte har samma möjligheter att själv styra sitt arbete. En annan nackdel kan vara att test hamnar väldigt långt ifrån verkligheten. I sådana här stora testorganisationer är det inte helt ovanligt att testarna aldrig sett hur produkterna fungerar i sin normala miljö – eller ens vet hur de ska användas.

Det här är de viktigaste vattendelarna som jag har tänkt på. Håller du med? Och får du också känslan av att test är ett område med oändliga möjligheter?

About Anna Odhner

Anna Odhner är en visionär coach och ledare med snart 20 års erfarenhet av test och ledarskap. Efter högskolestudierna jobbade Anna några år som ljuddesigner på Riksteatern. Därmed skolades Anna hårt i det agila tänket eftersom det är det gängse arbetssättet i teatervärlden. Nåja, utan postitlappar. Fast med polaroidkort.