Jag har alltid varit väldigt nyfiken på hur saker fungerar och samtidigt haft ett starkt driv att hjälpa andra. Länge trodde jag att jag skulle arbeta inom vården, kanske som läkare. Under en praktik hos en sjukgymnast fick jag dock upp ögonen för hur mycket utrustning och teknik som används inom vården och där väcktes mitt intresse för medicinteknik.

Min ingång till IT blev därför via medicinteknik, där jag arbetade i 17 år med forskning och utveckling av produkter för intensivvård, operationsutrustning och senare även pacemakers. Här lärde jag mig att kvalitet inte går att lägga på i slutet, utan måste finnas med från början. Det är ett tänkesätt som jag har haft med mig genom hela min karriär.

 

Jag började som utvecklare och programmerade i flera år. Inom medicinteknik är kraven extremt höga, både när det gäller regelverk, spårbarhet och kvalitet. Det innebar att man jobbar tätt med kravställning, utveckling och tester. Ganska tidigt insåg jag hur avgörande kraven är och hur mycket jag trivdes med arbetet kring testhantering, som ju är helt beroende av tydliga och välformulerade krav. Där någonstans hittade jag mitt fokus.

 

För mig handlar krav om mer än att analysera. Kravhantering – requirement management – innebär hela kedjan: att fånga behov, förstå alla intressenter, formulera kraven korrekt, kvalitetssäkra dem och se till att de förankras. Ett krav ska vara entydigt, mätbart och testbart.

Många känner till SMART-principen och inom kravhantering betonar man även att kraven måste vara testbara. Ett vanligt misstag är att man tror att en lista i Excel automatiskt är en kravspecifikation, men det är innehållet och formuleringen som avgör. Jag är certifierad enligt IREB – International Requirements Engineering Board – vilket ger en strukturerad förståelse för hur man arbetar med krav genom hela kedjan.

 

Det största problemet är otydlighet. Om kraven kan tolkas på olika sätt kommer utvecklare, testare och verksamhet att dra åt olika håll. Då fastnar projekten i långa diskussioner och ineffektivitet. 

Jag ser kravspecifikationen som ett styrande dokument. Ju bättre kvalitet man har där, desto mer tid och pengar sparar man längre fram. Granskningar av krav är en form av statisk testning och en av de viktigaste kvalitetssäkringarna. Kan man hitta fel redan i hur kraven är formulerade sparar man otroligt mycket resurser.

 

Det är ett väldigt socialt arbete. Jag jobbar mycket med workshops, intervjuer, processkartläggning och personas. En viktig del är att identifiera alla berörda intressenter, det är sällan en enig verksamhet. Ibland använder jag även enskilda intervjuer för att få en mer nyanserad bild av behovet.

En vanlig fallgrop är att man går direkt på lösningar. Verksamheten beskriver hur de vill att systemet ska fungera – ”jag skulle behöva en grön knapp och två rutor här” – men mitt jobb är att förstå varför. När behovet är tydligt begränsar man inte IT:s möjligheter att ta fram rätt lösning. 

 

Det fungerar väldigt bra. Kravarbetet är intensivt i början av ett projekt, oavsett om man jobbar agilt eller enligt vattenfall. När kraven väl är på plats axlar jag rollen som testledare. Då handlar det om att planera teststrategi, ta fram testfall, säkra testmiljöer och stötta verksamheten i acceptanstester.

Att ha båda perspektiven gör att man tidigt kan kvalitetssäkra både krav och tester, vilket minskar risken för överraskningar senare i projektet. De senaste 15 åren har jag nästan alltid varit testande testledare, så jag testar också själv och tar fram testdesign. Testrapporten är ofta underlaget för beslut om man ska gå i produktion med systemförändringar eller inte.

 

Jag började på Regent i slutet av augusti och kom snabbt ut på uppdrag i september. Jag arbetar i energibranschen i två projekt som löper över cirka ett år. Mycket fokus ligger på samordning av tester med externa leverantörer, så kallade onboarding-tester. Det är komplext, men också väldigt roligt. Leverantörerna ska kunna koppla upp sig mot våra system och testmiljöer och vi behöver säkerställa att information flödar korrekt till leverantören och tillbaka. Den typen av samarbeten och flödestester är något jag verkligen trivs med och det är en intensiv period med mycket testarbete framför oss.

 

Vi är ett tjugotal med olika roller och kompetenser. En del arbetar mer med testautomation, vilket nästan blir en programmerarroll där man utvecklar tester. Andra är specialiserade på prestanda- och säkerhetstester.

Jag har arbetat en del med testautomation och kan skriva testskript i olika verktyg, men när det kommer till att sätta upp riktigt bra ramverk behövs ofta arkitekter. Jag ser mig mer som generalist än specialist där, men jag har lett implementationer och tagit fram business cases för att påbörja automation. Det stora värdet ligger i att vi kan stötta varandra och lära av varandras erfarenheter.

 

Ja, faktiskt! Jag och min man har nyligen köpt en sommarstuga. För att komma till skott och faktiskt hitta rätt, tog vi fram en kravlista. Vi rangordnade kraven, prioriterade vad som var viktigast, synkade oss och plötsligt gick allt väldigt snabbt!

Ett av de viktigaste kraven var att stugan skulle ligga nära vår son, som snart blir pappa. Vi hade satt en gräns på en halvtimmes bilresa. Stugan vi hittade ligger mellan Gävle och Ockelbo och bara 20 minuter från sonen, så det kravet uppfylldes perfekt! Växthus var ett annat viktigt krav. Jag har ett stort odlingsintresse och vid stugan fanns redan ett tunnelväxthus på plats. Vi får tillträde i maj och jag ser verkligen fram emot att lära känna platsen under det första året.