Testning i produkt- och applikationsutveckling

Detta är nr #1 av en serie artiklar om testning!

​

Många organisationer har väl fungerande processer för att analysera, designa och realisera sina system. Ändå är testning ofta den fas som pressas ihop när leveransdatum närmar sig. Det är ett vanligt misstag – och ett dyrt sådant oavsett bransch och oavsett vilket regelverk ni förhåller er till.

​

Kraven på strukturerad och dokumenterad testning kommer från flera håll samtidigt. DORA (Digital Operational Resilience Act) ställer dem på finansiella aktörer. ISO 27001 kräver att säkerhetskontroller verifieras och att organisationen kan visa att de fungerar i praktiken. NIS2 och den svenska cybersäkerhetslagen ställer krav på systematisk riskhantering och säkerhet i leveranskedjan – vilket testning är en direkt förutsättning för. Gemensamt för alla är att det inte räcker att ha processer på papper. Ni måste kunna visa att de fungerar.

​

Varför är testning viktig?

Testning handlar om att bekräfta att det man bygger faktiskt gör vad det ska – och inte orsakar oönskade effecter eller introducerar onödig risk. I praktiken är det lätt att förkorta testfaserna när tid och budget är begränsade.

​

Konsekvenserna kan bli allvarliga: systemfel i produktion, säkerhetsluckor och incidenter som drabbar kunder. Oavsett om ni styrs av DORA, ISO 27001 eller NIS2 är kravet detsamma – ni ska kunna visa att ni testar systematiskt, dokumenterat och med definierade kriterier för vad som godkänns.

 

En välstrukturerad testning ger er:

• Kontroll över att systemet uppfyller ställda krav

• Spårbarhet och dokumentation inför revisioner och tillsyn

• Underlag för riskbaserade beslut

• Förtroende – hos er själva, era kunder och tillsynsmyndigheter

​

Testning och kravställning måste hänga ihop

En av de vanligaste felkällorna i utvecklingsprojekt är att testning och kravställning behandlas som separata spår. Man skriver krav tidigt och funderar på hur man ska testa dem sent. Det borde vara tvärtom.

Bra krav är testbara krav. Varje krav ska formuleras så att det går att avgöra objektivt om det är uppfyllt eller inte. Vaga formuleringar som "systemet ska vara stabilt" eller "prestanda ska vara god" är svåra att testa och ännu svårare att godkänna formellt – och ger er inget att visa upp vid en revision.

​

Formulera istället krav med mätbara villkor – svarstider, felfrekvenser, tillgänglighetsgrad eller beteende i specifika scenarion.

​

Testfall ska designas och godkännas redan i analysfasen. Inte efteråt. Då vet alla parter vad som ska verifieras, och det finns inget utrymme för tolkningstvister sent i projektet. Testfallen blir också ett naturligt kvitto på att kraven är tillräckligt konkreta.

​

En enkel tumregel: om ni inte kan beskriva hur ni ska verifiera ett krav är kravet förmodligen inte tillräckligt konkret.

​

En teststrategi sätter ramen

Utan en teststrategi riskerar testningen att bli ad hoc – beroende av vem som råkar ha tid. En teststrategi behöver inte vara ett digert dokument, men den ska svara på:

• Vilka testnivåer används (enhet, integration, system, acceptans)?

• Vem ansvarar för vad?

• Vilka verktyg och miljöer används?

• Hur hanteras testdata – och hur säkerställer ni att produktionsdata aldrig används i testmiljöer?

• Hur dokumenteras och spåras testresultat?

• Vad krävs för att godkänna en leverans?

​

En dokumenterad teststrategi är också ett konkret svar på tillsynsfrågor från DORA, ISO 27001-revisorer och NIS2-myndigheter – den visar att testningen är planerad och strukturerad, inte slumpmässig. Vi går igenom vad en teststrategi bör innehålla i detalj i artikel 2 i den här serien.

​

Olika typer av tester – ett smakprov

Beroende på system och risknivå finns flera typer av tester som bör ingå i en strukturerad testprocess. I artikel 3 i serien går vi igenom dem i detalj, men kortfattat:

​

Kodgranskning (code review) är en ofta underskattad kontroll. För att den ska räknas som en verifierad åtgärd – exempelvis under ISO 27001 bilaga A – måste den vara dokumenterad: vem granskade, mot vilka kriterier och vad konstaterades.

​

SAST (Static Application Security Testing) analyserar källkoden utan att köra den och letar efter kända säkerhetssvagheter – ett effektivt sätt att fånga problem tidigt i utvecklingen. Kopplar direkt till krav på säker systemutveckling i ISO 27001 (A.8.28) och NIS2.

​

DAST (Dynamic Application Security Testing) testar systemet medan det körs och simulerar hur en angripare kan interagera med det utifrån.

​

SCA (Software Composition Analysis) granskar tredjepartsbibliotek och beroenden för kända sårbarheter – särskilt viktigt i moderna system där mycket kod är öppen källkod, och direkt relevant för NIS2:s krav på säkerhet i leveranskedjan.

​

Prestandatestning verifierar att systemet håller under förväntad och extrem belastning – en central del av kraven på operationell motståndskraft i både DORA och NIS2.

​

Nästa steg

En välstrukturerad testprocess är inte en engångsinsats – det är ett arbetssätt som måste förvaltas och förbättras löpande. Den här artikeln är den första i en serie om test. I efterföljande artiklar kommer vi in på teststrategi, testtyper och en sammanhängande ledningsstruktur för testning.

​

Hör av er till oss om ni vill diskutera hur ni kan stärka er testprocess i linje med DORA, ISO 27001 eller NIS2.