Optimering av testprocesser i

agila projekt

Jesper Högberg

Våren 2009

2

Sammanfattning I dagens samhälle övergår mer och mer av utvecklingen av IT system till att använda agila utvecklingsmetoder. Samtidigt blir kraven på våra IT system striktare. Fler och fler system integreras och kraven på tillförlitlighet är nästan 100 procent. Detta ställer stora krav på en effektiv testprocess. Många arbetsmoment i en optimal testprocess är sådant som lätt faller mellan stolarna eller svårt att få erfarenhet av. Testarbetet är även mycket teoretiskt och akademiskt när det kommer till processoptimering, teststrategier och testledning på avancerad nivå. Denna uppsats förklarar förutsättningar, arbetsmetodik för agila utvecklingsprojekt, det idealiska testarbetet och en steg för steg process för att uppnå en hög mognadsgrad i testarbetet. Målet med hela testarbetet och dess optimering syftar till att leverera tillförlitliga affärskritiska system. Det är precis vad som normalt efterfrågas i dagens samhälle. För att summera innehållet i de tre stegen i processoptimeringsarbetet kan nämnas att steg 1 handlar om att definiera teststrategi, testplan, etablera rutinerna för att testa på alla nivåer i teststrategin, genomgång av statisk test, utbildning av personal i testdesign och arbetsprocesser. Steg 2 i processoptimeringen syftar till att höja nivån jämfört med steg 1 och lägga till strukturerad CM-hantering, testmetrik, IEEE 829 standarddokumentation, releasenotes, ickefunktionell test, change control board för felhantering, strategi för testmiljöer och testdata, versionshantering av testmaterial, driftsättningsrutiner och vad som ska lämnas över till förvaltning. Steg 3 i processoptimeringsarbetet syftar till att ta testprocessen till högsta nivå. Innehållet är information om verktygsstöd för att förbättra testarbetet, strategi för statisk test, exitkriterium för ett testprojekt, automatisering av regressionstester, etablering av kommunikationskanaler, testhandbok och forum för kontinuerligt förbättringsarbete. Med denna uppsats i din hand har du det som krävs för att få dina system och ert arbetsteam att prestera maximalt och för att få systemen att motsvara förväntningarna. Trevlig läsning och lycka till med testarbetet! Jesper Högberg

3

Jesper Högberg Född 1976. Arbetar som konsult, utbildare och rådgivare inom test och kvalitetssäkring av IT system. Sedan 2001 har Jesper Högberg arbetat inom bank, finans, spel, telekommunikation, offentlig förvaltning och kommunal utbildning. De roller som Jesper Högberg arbetat inom är testchef, teststrateg, testledare, auditor, configuration manager, prestandatestare, systemtestare, funktionstestare, integrationstestare, kravspecificerare, utbildare och lärare. Jesper Högbergs utbildning är ISTQB Full Advanced Level Certified, Civilingenjör Farkostteknik med inriktning tillämpad matematik från KTH och Filosofie Kandidat examen i nationalekonomi från Stockholms Universitet. Stora komplexa affärskritiska system har redan från början varit vardagen. Erfarenhet från olika branscher och roller har skapat en förståelse för hur dagens IT samhälle fungerar bakom kulisserna. Nuförtiden skriver Jesper Högberg en del material inom testområdet som är till nytta för många andra. På fritiden umgås Jesper Högberg med familj och vänner, läser böcker inom test och nationalekonomi samt tränar styrketräning. Somrarna tillbringar Jesper Högberg med familjen i det soliga Tunisien där tiden fördrivs med sol, bad, bazarförhandlingar och diverse bröllopsfester.

4

Innehållsförteckning

Inledning ............................................................................................................................5 Avgränsningar ....................................................................................................................5 Förutsättningar ...................................................................................................................5 Projektstyrningsmetod ........................................................................................................5 Implementationsteknik........................................................................................................7 Kontinuerlig integration......................................................................................................7 V-modellen.........................................................................................................................8 Riktlinjer för testpersonal ...................................................................................................8 Generiska arbetssteg för test ...............................................................................................9 Det idealiska testarbetet ......................................................................................................9 Arbetsuppdelning processoptimering ................................................................................10 Inkrement 1 ......................................................................................................................11

Teststrategi ...................................................................................................................11 Statisk test ....................................................................................................................13 Testplanen ....................................................................................................................14 Karaktäristik för inledande arbetsmetod........................................................................15 Enhetstest .....................................................................................................................16 Integrationstest .............................................................................................................16 Systemtest ....................................................................................................................17 Acceptanstest................................................................................................................18

Inkrement 2 ......................................................................................................................18 CM strategi och process................................................................................................18 Definitioner av metrik...................................................................................................19 Standardiserad dokumentation ......................................................................................21 Releasenotes .................................................................................................................22 Riskbaserad testning .....................................................................................................22 Webbsystem .................................................................................................................23 Ickefunktionell test .......................................................................................................23 Change Control Board ..................................................................................................24 Testmiljöerna................................................................................................................25 Testdata ........................................................................................................................25 Versionshantering av testmaterial .................................................................................25 Driftsättning .................................................................................................................26 Överlämning förvaltning...............................................................................................26

Inkrement 3 ......................................................................................................................26 Testverktyg...................................................................................................................26 Kommunikationskanaler ...............................................................................................27 Strategi för statisk test...................................................................................................28 Exitkriterium ................................................................................................................28 Automatisering av regressionstest .................................................................................28 Testhandbok .................................................................................................................29 Etablering av forum för kontinuerliga förbättringar.......................................................29

Referenser ........................................................................................................................29

5

Inledning

I dagens samhälle övergår mer och mer av utvecklingen av IT system till att använda agila utvecklingsmetoder. Samtidigt blir kraven på våra IT system striktare. Fler och fler system integreras och kraven på tillförlitlighet är nästan 100 procent. Detta ställer stora krav på en effektiv testprocess. Denna uppsats behandlar en av de vanligast förekommande typerna av projekt idag där lättrörlig systemutvecklingsmetodik enligt SCRUM tillämpas och implementationen av källkoden sker med Test Driven Development, TDD. Uppsatsen beskriver först förutsättningar, projektstyrningsmetodik, utvecklingsmetodik och riktlinjer för utveckling. Sedan följer tre inkrement med omfattande innehåll för att uppnå en optimal testprocess.

Avgränsningar Uppsatsen förklarar inte alla begrepp, testtekniker, verktyg och processer i detalj. Det förutsätts att ledaren för arbetet eller teamet sammantaget har tillräcklig erfarenhet för att kunna genomföra processoptimeringsarbetet. Litteraturreferenserna innehåller de detaljer som inte förklaras explicit i denna uppsats. Gruppdynamik, motståndskrafter vid förändringsarbete eller vem praktiskt utför de olika arbetsstegen ligger utanför ramarna för uppsatsen. I dagens agila arbetsteam är detta så vanliga företeelser att det inte skulle ge extremt mervärde till uppsatsen.

Förutsättningar Innan implementation av ett system ska påbörjas rekommenderas följande förutsättningar

• Coding guidelines • Versionshanteringssystem med incheckningsregler • Felrapportering med tillhörande verktyg och process • Testmiljö separerad från utvecklingsmiljö

Utan dessa förutsättningar uppstår många onödiga problem som kan kosta både värdefull tid och resultera i skenande kostnader.

Projektstyrningsmetod I SCRUM släpps fokus från omfattande dokumentation, administrativa processer, titlar på personer etc. Fokus ligger på det som är viktigast, körbar programvara. Utvecklingsarbetet är empiriskt och kan inte beskrivas med en formel. För detta krävs prestigelösa, drivna personer som gärna är generalister till sin natur. Sprintöversikten nedan beskriver hur en iteration kan se ut, rollerna i SCRUM beskrivs liksom några vanligt förekommande begrepp och till sist några principer som har sina rötter i Lean Software Development.

6

Definitioner inom Scrum Scrum team – en arbetsgrupp med ca 5 - 9 personer Sprint – en utvecklingsiteration om ca 2 - 6 veckor Roller

• Scrum Master – ansvarar för att uppfylla sprintmål • Product Owner – äger Product Backlog • Team Member – medlem i teamet som arbetar för att uppnå sprintmålet

Product Backlog • Ägs av Product Owner • Prioriterad lista • Innehåller funktionella och ickefunktionella krav, ändringsarbeten, felrapporter,

önskemål om teknikskiften eller prestandaförbättringar Sprint Backlog

• Det som implementeras under Sprint • Prioriterad lista • Tas fram under Sprint Planning • Innehåller funktionella och ickefunktionella krav, ändringsarbeten, felrapporter,

önskemål om teknikskiften eller prestandaförbättringar • Aktiviteter som kan utföras på 2-16 timmar per aktivitet

Figur 1. Sprint backlog

Figur 2. Iteration inom SCRUM.

7

Principer som gäller för SCRUM och ursprungligen kommer från Lean Software Development, lättrörlig, iterativ utvecklingsmetodik:

• Amplify Learning - sprid din kunskap • Decide as late as possible - bättre beslutsunderlag • Deliver as fast as possible - leverera fungerande system i korta iterationer • Build integrity in - användaren ska uppleva det bästa • Eliminate waste - gör inget som inte tillför värde för slutkunden • Empower the team - delegera ansvar till individerna • See the whole - undvik suboptimering

Implementationsteknik Test Driven Development, TDD, är kort beskrivet en teknik för att implementera kod där man skriver testfallen före källkoden. Testfallen representerar kraven för systemet. Detta tvingar utvecklaren att fokusera på att förstå kraven på rätt sätt. Kraven kan vara formulerade som use-cases eller user stories. Testfallen implementeras så att de kan köras automatiskt. Man får omedelbar feedback om något fel finns då källkoden skrivits. Man arbetar i korta iterationer och anpassar källkod till att passera testfallen genom refaktorering. Man skriver endast kod som ska passera testfallen, dvs. uppfylla kraven. Annat ryms inte in i metodiken. Tekniken handlar mer om hur man designar kod än om hur man testar koden. Det är utvecklaren själv som implementerar testfallen. TDD har visat att det ökar produktiviteten och fokuseringen på test. Med en extremt förenklad sammanfattning kan man beskriva metoden med följande arbetsmoment:

• Lägg till ett nytt testfall • Kör testfallen för att se om något fallerar • Skriv ny kod • Kör testfallen för att se att de passerar utan fel • Refaktorera kod, kör testfallen igen • Repetera arbetsmomenten från början

Kontinuerlig integration Det naturliga är att röra sig mot kontinuerlig integration, d v s hela systemet skall vara byggbart och testbart hela tiden. Viktiga delar i kontinuerlig integration för att fungera praktiskt är:

• En väl fungerade CM-miljö med versionshantering • Automatiskt bygge av hela systemet • Automatisk testning så långt det finns implementerade testfall • Automatisk publicering av bygg- och testresultat på intranätet

Alla dessa steg är inte en förutsättning för att komma igång. I beskrivningen av de olika inkrementen beskrivs när de olika stegen är aktuella. När kontinuerlig integration fungerar behövs aldrig något tvivel över produktens status.

8

V-modellen V-modellen förklarar konceptuellt hur system byggs uppifrån och ner och testas nerifrån och upp. Modellen förklarar vilka nivåer som används och vad som är utgångspunkten för tester på en viss nivå.

Figur 3. V-modellen. Den vänstra halvan av V-modellen är det dokument och artefakter som bygger upp systemet. Statisk testning utförs i de olika stegen längs den vänstra halvan. Den högra halvan av V-modellen symboliserar testnivåerna för dynamisk testning, dvs. exekvering av programvaran. Kopplingen förklarar vad som utgör grunden för respektive testnivå. Det bör vara spårbarhet horisontellt för varje testnivå och vertikalt längs den vänstra halvan. Med detta menas att testfallet ska förklara på ett enkelt sätt vilket krav det är som testas. Den vertikala spårbarheten är att Kravdefinitionen utgör grunden för Funktionell systemdesign som i sin tur utgör grunden för Teknisk systemdesign. Det är lämpligt att namnge dokument och artefakter på så sätt att det framgår vad som var grunden för varje nivå.

Riktlinjer för testpersonal Dessa riktlinjer gäller tests roll i projektet och grundläggande egenskaper för det som produceras genom systemets livscykel:

• Testledning och testare ska vara delaktiga så tidigt som möjligt i utvecklingsprojektet • Krav-, design- och funktionsspecifikationer ska vara mätbara, testbara och spårbara • Testare ska granska allt material som är nödvändigt att granska och skapa testfall av

detta • Detta gäller allt som produceras i projektet: Enkelhet, tydlighet, robusthet, inga

onödiga extradetaljer, keep it simple!

Kravdefinition

Funktionell systemdesign

Teknisk systemdesign

Komponent specifikation

Programmering

Enhetstest

Integrationstest

Systemtest

Acceptanstest

9

• Utbildning i testdesigntekniker är av yttersta vikt

Generiska arbetssteg för test De arbetssteg som beskrivs här genomsyrar allt testarbete oavsett utvecklingsmetodik och mognad i testprocessen som helhet. De genomförs inte alltid exakt i denna ordningsföljd men stegen görs metodisk av alla testare eller testledare:

• Planera tid, omfattning av tester och personalbehov • Granskning och analys av dokumentationen

– Kravspecifikationer, designmodeller och funktionsspecifikationer • Designa och specificera testfall

– Skriv rubrik som innehåller syftet med testet samt bestäm vilken testdesignteknik som ska användas, bestäm input, teststeg och output

• Skaffa testmiljö – Det kan behövas flera separata testmiljöer med det viktigaste är att testarna inte

arbetar i samma miljö som utvecklare, inte heller i produktionsmiljön • Säkerställ testdata

– Det är av vikt att kunna återställa testdata till ett utgångsläge i testmiljön, dessutom ska testdata inte innehålla känslig personlig information

• Exekvera testfall, logga resultat och rapportera avvikelser • Utvärdera utfall och skriv testrapport • Leverera testfall till förvaltning och genomför kontinuerligt utvärdering för

förbättringar – Detta görs i slutet av ett projekt då en produkt anses färdigutvecklad och kan

levereras vidare till användare och förvaltningsorganisation. Detta sker inte efter varje sprint

Det idealiska testarbetet I agila projekt är utmaningen att hålla dokumentationen på en sådan nivå att det är hållbart att underhålla den. En lösning på detta är att göra på följande sätt:

• Skriv en testplan för flera sprintar • Arbeta med testdriven utveckling enligt TDD, Test Driven Development • Tillämpa statisk testning, dvs. granskningar på alla nivåer • Skriv testfall på rubriknivå och bestäm vilken testdesignteknik som ska användas för

integrationstest och systemtest • Gör riskanalys och uppdatera risklistan veckovis med teamet • Träna och utbilda mycket inom testdesign • Tillämpa exploratory testing och error guessing och använd testfallsrubrikerna som

stomme • Automatisera så mycket tester som möjligt • Använd så många olika verktyg som möjligt för att stödja den definierade

testprocessen • Se till att kommunikation och ansvar i projektet fungerar på alla plan

Detta är lättare sagt än gjort och därför behövs en genomtänkt strategi för att komma fram till detta och det är precis det som fortsättningen av denna avhandling går ut på.

10

Observera att det är av yttersta vikt att utbilda sig inom test ordentligt och specifikt på olika testdesigntekniker. Den bästa testaren är den bäst utbildade testaren.

Arbetsuppdelning processoptimering Processoptimeringsarbetet delas upp i tre huvuddelar där de olika delarna har olika mål.

• Inkrement 1 - har syftet att definiera ett strukturerat arbetssätt och utbilda personalen i grundläggande testkunskap. Teststrategi tas fram

• Inkrement 2 - syftar till att förbättra det som byggdes upp i inkrement 1 och tillägga CM strategi, metrik, releasenotes, riskbaserad teststrategi, change control board, icke-funktionell testning och driftsättning

• Inkrement 3 - har som syfte att lägga in så mycket verktygsstöd som möjligt för att stödja testprocessen, strategi för statisk test, testhandbok och definierat exitkriterium. Detta inkrement syftar även till att skapa rutiner för kontinuerlig processförbättring

Ett inkrement behöver 2 - 4 sprints för att genomföras. Allt förs in stegvis och ytterligare en sprint används vid behov för att slutföra innehållet i ett inkrement. Om endast 2 sprintar behövs går det bra att fortsätta med nästa inkrement. Arbetet är influerat av TDD, SCRUM, Test Process Improvement och Best Practices utvunnen från många års erfarenhet i olika branscher såsom telekommunikation, spel, bank, finans och offentlig förvaltning.

Figur 4. Iterativ modell för optimering av testprocesser.

Bestäm inkrement

Fastställ vad som ska göras

Formulera tidsplan för förändringen

Genomför och implementera förändringen

Utvärdera utgångsläget

Utvärdera resultat av förändringen

11

Förklaring till bilden är att arbetet påbörjas med ett av inkrementen. Vi antar att vi börjar med inkrement 1. Arbetet påbörjas med att utvärdera utgångsläget, sedan bestäms vad som behövs göras för att inkrement 1 ska anses vara genomarbetat. Tidsplan formuleras och inkrementet förväntas ta 2-4 sprintar att införa. Förändringen genomförs sedan. Resultatet utvärderas. Är inkrementet färdigimlementerat eller är det arbetsmoment som motiverar ytterligare en iterativ process i förändringsarbetet för att slutföra innehållet i inkrementet? Om innehållet anses vara färdigimplementerat fortsätter förändringsarbetet med att påbörja ett nytt inkrement. På detta sätt fortsätter processoptimeringsarbetet ända tills målet är uppnått.

Figur 5. Tidsaxel för sprint och inkrement. Tänkbart är att det går åt ca 8-12 eller eventuellt ytterligare 2-4 sprintar för att genomföra alla inkrementen för att optimera testprocesserna. Testautomatisering och verktygsinförande i större utsträckning som sker i det sista inkrementet kan kräva mycket tid.

Inkrement 1 Första inkrementet syftar till att definiera ett strukturerat arbetssätt med en uttalad strategi. Träning av medarbetare med fokus på testnivåer, testdesigntekniker, testtyper, testverktyg och en sammanhängande process där utvecklare och testare interagerar. I detta fall handlar det om SCRUM och TDD som ska tränas och mogna hos medarbetarna. Fokus ligger i högre utsträckning på funktionella tester än icke funktionella tester inledningsvis.

Teststrategi En teststrategi tas fram av en testledare eller teststrateg och är ett viktigt fundament för test av ett system. Det är den bakomliggande arkitekturen i testprocessen skulle man kunna säga. Det är av yttersta vikt att den som formulerar teststrategin har djup insikt i systemarkitektur, teknikval, beroenden och samband mellan delsystem och vilka tekniska kvalitetskrav som finns. En grafisk översiktsbild bör upprättas där systemet beskrivs med dess modulära uppbyggnad och de olika skikt som sammantaget bygger upp systemet. Denna bild bör vara tydligt kommunicerad till all personal i utvecklingsteamet inklusive alla som arbetar med test. Olika arbetsflöden genom systemet förklaras så att det framgår vilka vägar genom systemet viktiga arbetsflöden har. Detta är av stor vikt för att förstå hur systemet ska integreras, testas, byggas ut och för dess releaseplanering av olika komponenter och delsystem.

Sprints

Inkrement 1 2 3

12

En effektiv teststrategi bör innehålla: • Testnivåer

o Enhetstest, integrationstest, systemtest, acceptanstest • Testtyper

o Funktionalitet, säkerhet, prestanda, användbarhet, kompatibilitet, tillförlitlighet, skalbarhet, underhållbarhet, fail-over, testbarhet och installerbarhet

• Testdesignteknikerna som tas upp i grundläggande testkurser som kommer från BS7925-2 Standard for Software Component Testing

o Strukturell test där kodtäckningsgrad mäts – statement, decision, condition coverage

o Statisk analys där kodstandard, komplexitet eller minnesläckage analyseras o Funktionell testdesign med

� Ekvivalensklasspartitionering � Gränsvärdestest � Tillståndstester � Logiska kombinationer (Decision tables) � Pairwise testing � Use-case testing

o Statisk test i form av granskningar � Walktrough – författaren demonstrerar och förklarar det som ska

granskas � Inspection – formell granskningsprocess styrd av moderator och med

mätbara mål � Technical review – tekniska specialister djupgranskar komplexa

detaljer o Erfarenhetsbaserad testdesign som ökar effektiviteten

� Exploratory testing – testdesign, exekvering och loggning sker löpande � Error guessing – checklistor med kända typer av fel skräddarsys och

uppdateras löpande för det system som testas, kan göras med riskanalys som utgångspunkt

• Testverktyg o Testledningsverktyg o Felrapporteringsverktyg o Versionshanteringsverktyg o Modelleringsverktyg o Testdesignverktyg o Testexekveringsverktyg

• Testmiljöer och testdata o Testdata genereras, avkodas, versionshanteras och laddas om löpande o Utvecklingsmiljö, funktionstestmiljö, prestandatestmiljö, acceptanstestmiljö

och produktionsmiljö rekommenderas • Testprocess och utvecklingsprocess

o En uttalad idé om hur arbetet ska bedrivas är viktigt för kommunikationen och resultatet. Projektdeltagarna behöver tydlig information om vad som gäller i projektet

• Utbildning o För att kunna använda en effektiv teststrategi krävs rätt förutsättningar i form

av utbildning i testnivåer enligt v-modellen, testdesign, testverktyg, testprocesser, utvecklingsprocesser och om infrastrukturen. Projekt är

13

lagarbeten där varje individ behöver få ut bästa baserat på den erfarenhet som individen har. Rekommendation är att alla läser boken A Practitioners Guide to Software Test Design av Lee Copeland. Observera att det aldrig går att bli helt fullärd när det gäller testdesign, det krävs ständig utbildning och praktisering.

Det är mycket viktigt att känna till att en teststrategi som innehåller både strukturerad enhetstestning och dessutom integrationstest, systemtest och acceptanstest som genomförs med etablerade testtekniker är mycket mer effektiv är om strategin endast innehåller antingen enhetstest eller integrationstest och systemtest. Det är helhetsstrategin som är överlägsen. De fel som hittas på enhetstestnivå går ej nödvändigtvis att upptäcka med integrationstest eller systemtest. Gränssnitten för de olika testnivåerna är olika och de ska inte ses som överlappande. Alla nivåer behövs testas. Systemtest är inte ett skyddsnät för att hoppa över enhetstest.

Statisk test Statisk test görs i förebyggande syfte och detta introduceras i det första inkrementet. Statisk test är ett av de mest kostnadseffektiva sätten att få bra kvalitet för ett system. Granskningar kräver inte ett exekverbart system, det går snabbt att läsa dokument, det kräver inte alltid teknisk kompetens, kunskap sprids i gruppen och koncensus uppnås. Det kan upplevas som en tröskel att ta sig över för att komma igång med formella granskningsprocesser med strukturerad process och definierade steg. En mindre formell metod som med fördel används då något är halvfärdigt är Walkthrough där författaren förklarar för kollegor vad ett dokument eller en modell handlar om och tar emot feedback. En typ av mer strikt och formell granskning kallas inspection och dess process kan delas in i

• Entry – roller definieras, dokument eller källkod görs tillgängliga • Planning – personer allokeras, roller tilldelas och dokument beskrivs • Kick-off – presentation och distribution av material, beskrivning av ansvar, roller och

strategi • Preparation – individuell förberedelse där avvikelser och problem loggas • Review – genomgång av dokument där alla kommentarer från loggar gås igenom och

leds av moderator. Författaren är lämpligtvis med och antecknar kommentarerna som kommer upp

• Rework – omarbetning av de avvikelser som uppkommit • Follow-up – slutavstämning och leverans till nästa steg i utvecklingsprocessen • Exit – mätbart kriterium som måste vara uppnått

Detta kan förklaras konceptuellt i det första inkrementet av processförbättringen och genomföras mer disciplinerat i ett senare skede. Viktigt att tänka på för den som granskar är att söka efter information som inte är mätbar, testbar och spårbar från t.ex. krav till design. Det som eftersökt är även logiska konflikter, motsägelser, slarvfel, logiska fel, brått mot regler för design, icke kompletta beskrivningar, otydlig tolkningsbar information men framförallt sådant som strider mot sunt förnuft. Granskas kod, se då upp för inkonsistent namnkonvention, avvikelser från coding guidelines, spretig osammanhängande logik, alltför långa sammanhängande kodavsnitt som kan delas upp, fixa tal i koden eller en ofullständig felhantering.

14

Statisk test kan delvis göras av verktyg som fokuserar på att hitta

• Cyklomatisk komplexitet som mäter mängden testfall som krävs för att testa funktionen och dessutom ger det indikation om funktionen är svår att underhålla eller förstå

• Minnesläckage då minne allokeras men aldrig frigörs • Potentiella fall för systemkrash vid felanvändning av variabler • Kontrollflödesdiagram som visar olika sätt för hur koden kan exekveras • Dataflödesanalys där initiering, användande och borttagande av objekt i koden

analyseras

Testplanen Testplan formuleras med betoning på att det inte dokumenteras i stor utsträckning. Testplanen skrivs enligt IEEE 829 som mall. För varje kapitel kan viss information återanvändas från en sprint till en annan. Testplanen skrivs idealiskt för ett antal sprintar. Det är främst testing tasks som kommer att uppdateras. Detta kan göras i ett testverktyg, projektplaneringsverktyg eller sprint backlog. Här är nedan finns ett exempel på hur testplanen är organiserad enligt IEEE 829. Test plan identifier – Unik benämning av testplanen. Introduction – Summering av vad som ska testas, vilka system och funktioner som avses. Här kan det finnas referenser till tex Projektplan, kvalitetssäkringsplan, konfigurationshanteringsplan, policies och standards. Test items – Vilka testobjekt, dvs. delsystem, system, dokument etc. och dess versioner som ska testas. Features to be tested – Beskrivning av vilka egenskaper som ska testas. Funktionalitet, prestanda, användbarhet, tillförlitlighet, säkerhet, kompatibilitet, portabilitet etc. Beskrivning av design specifikation för varje ”feature”. Features not to be tested – Beskrivning av vad som ej behöver testas. Approach – Beskrivning av strategi eller tillvägagångssättet att testa systemet. För varje grupp av ”features” bör det framgå tillvägagångssättet med aktiviteter, teknikerna och verktygen som krävs för att testa. Det bör vara tillräckligt detaljerat för att man ska kunna bedöma tidsåtgång för de huvudsakliga testuppgifterna. Item pass/fail criteria – Kriterium för att avgöra ifall testobjekten har passerat kvalitetskraven eller ej. Suspension criteria and resumptions requirements – Kriterium för att avbryta påbörjat test och vad som ska vara uppfyllt för att man ska återuppta testerna igen på den nivå som avses.

15

Test deliverables – Vilken testdokumentation som ska levereras. Testplan, testdesignspecifikationer, testfallsspecifikationer, testprocedurspecifikationer, leveransdokumentation, testloggar, felrapporter och testrapporter.

Testing tasks – Aktiviteter för att förbereda och exekvera testerna. Environmental needs – Förteckning av nödvändiga och önskvärda egenskaper för testmiljön. Detta bör beskriva såväl hårdvara och mjukvara och dess versioner. Responsibilities – Förteckning av ansvariga för ledning, design, förberedelser, exekvering, kontroll och lösning i samband med testerna. Staffing and training needs - Specificering av kompetenser och utbildningsbehov för testteamet. Schedule – Tidsplan som inkluderar både ”milestones” från projektplanen och tidpunkter för leveranser. Risks and contingencies – Identifiering av högriskområden som kräver extra uppmärksamhet vid testexekveringen. Testerna ska bedrivas så att identifierade konsekvenser av riskerna minimeras. Approvals – Namn och titel på personer som ska godkänna testplanen.

Karaktäristik för inledande arbetsmetod Under all form av utvecklingsarbete krävs återkoppling på det material som skapas, i detta fall dokument, designmodeller och källkod. Det är viktigt att återkopplingen sker så frekvent som möjligt och för att gå igenom de olika sätt som feedback fås listas det så här

• Parprogrammering (testdriven) är den snabbaste återkopplingen av kamraten • Statisk test i form av granskning i någon form • Enhetstest exekveras med jämna mellanrum och specifikt varje gång systemet

kompilerats • Kontinuerlig integration där team medlemmarnas kod checkas in och byggs frekvent

och kompileringsfel blir kända • Daily scrum, det dagliga statusmötet där det meddelas vad som gjorts, vad som ska

göras och vilka hinder som finns • Integrationstest funktionskedjor och interface kontrolleras, automatiskt eller manuellt

så ofta det behövs • Systemtest sker under sprint • Prestandatest genomförs minst en gång i månaden • Demo, i slutet av varje sprint sker en demonstration av körbar programvara och

återkoppling sker av Product Owner

Implementationen av systemet bör ske testdrivet med tekniken TDD – Test Driven Development. Detta kräver eller ger

• Genomtänkt implementation • Ständigt uppdaterad regressionstestsvit för enhetstester

16

Enhetstest

Fokus för enhetstesterna som tas fram vid implementationen är att uppnå så hög nivå som möjligt för

• Statement coverage – där andelen exekverade kodrader mäts • Decision coverage – där andelen möjliga utfall från villkor som exekveras mäts • Condition coverage – där andelen exekverade utfall av möjliga utfall från

beståndsdelar i villkor där villkoren kan vara sammansatta av flera villkor Teknikerna för att uppnå kodtäckningsgrad är kontrollflödestester. Dessa beskrivs bland annat i BS7925-2 Standard for Software Component Testing och ingår i alla grundläggande certifieringar inom test. Målet är ständigt att minska komplexiteten i implementationen, att undvika minnesläckage, följa kodstandard och uppnå en hög nivå av enkelhet och underhållbarhet för källkoden. Stöd för detta är statisk analys och är en integrerad del i ett modernt utvecklingsverktyg. Cyklomatisk komplexitet är minsta antalet testfall som krävs för att exekvera alla unika icke loopande vägar genom koden. Detta betyder att det är ett implicit mått på kostnad för underhåll. Kod med högre komplexitet ger i regel fler fel, kräver mer test, är mer personberoende och därmed dyrare att underhålla. Rekommendationen för den cyklomatiska komplexiteten är att

• Minska komplexitet på koden så mycket det går • Cyklomatisk komplexitet högre är 10 bör granskas och delas upp

För att öka kodtäckningsgraden bör följande tas i beaktning

• Om det finns kod som inte har några krav bör krav läggas till eller kod tas bort. • Om det finns kod som inte används rekommenderas att ta bort den • Om tester saknas för ett krav bör testfall läggas till

Integrationstest Integrationstest är viktigt för att säkerställa interaktionen mellan enheter och komponenter och utvärdera systemets olika interface. Sätt ihop funktionskedjor och exekvera testfall. Rekommenderat är att använda standardtesttekniker såsom

– Ekvivalensklasser – Gränsvärdestester – Logiska kombinationer – Tillståndstester – Use case test – Pairwise testing

Systemintegration kan betyda olika saker, dels kan det betyda att man integrerar delsystem med varandra t.ex. klient, server, databas. Det kan även betyda att man integrerar olika system med varandra som var för sig kan bestå av ett antal delsystem med klient, server, databas. Viss litteratur benämner de 2 varianterna som "integration in the small" och "integration in the enterprise". Här ska vi fokusera på integration in the small. Man talar ofta om 3 strategier inom systemintegration: top-down, botton-up eller big-bang.

17

• Top down: man börjar med användargränssnitt och jobbar sig nedåt, stubbar behövs • Bottom up: man börjar med databas och jobbar sig uppåt, inga stubbar behövs • Big bang: man försöker få ihop alla delsystem tillsammans direkt, fungerar i princip

inte alls, tekniken kan förväntas fungera för icke tekniskt utbildad personal

Som en liten bonus brukar lagervis integration nämnas, med detta menar man att t.ex. alla server delar integreras, sedan alla databas delar etc. Man skulle kunna säga att det är ett första "integration in the small" steg. I exemplet med top-down, bottom-up och big-bang så har dessa steg föregåtts av lagervis integration. Var vaksam på att läsa loggfiler då man skapar databaser då kompileringsfel kan upptäckas. Kolla alltid loggar vid installation av alla system. Det gäller att fånga felen så tidigt som möjligt. När man jobbar som integrationstestare är det mycket bra att utveckla en integrationsstrategi för det system som ska testas. Om det är mycket logik i databas delen, börja då med att sätta upp databasen, koppla sedan på ett delsystem på databasen, t.ex. server, fortsätt sedan med ytterligare ett delsystem. För varje steg måste en kedja av funktioner testas så att det framgår om allt hänger ihop. Om det är ett system med mycket logik i användargränssnittet, inled då med att sätta upp de delar som inkluderar användargränssnittet, lägg på stubbar, testa funktioner, lägg på ett delsystem underifrån, stubba under, testa funktionalitet. Fortsätt tills hela systemet är integrerat.

Idealiskt sett kan integrationstester automatiseras kontinuerligt och exekveras som en del av ett dagligt systembygge. Det kräver då att systemet kan installeras automatiskt i en testmiljö. Om det inte går att installera automatiskt kan installationen ske steg för steg enligt ovan nämnd integrationsstrategi och efter det testas med automatiska integrationstester.

Systemtest Det fullt integrerade system testas här med fokus på att utvärdera

• Kravspecifikation • Användningsfall • Icke-funktionella krav

Använd standardtekniker beskrivna i teststrategin och integrationstest för funktionstest och komplettera alltid med exploratory testing och error guessing med checklista. Logga testresultaten. De icke-funktionella testerna förklaras i inkrement 2. Inled systemtesterna med ett ”smoketest” där positiva huvudflöden testas på systemets olika funktioner, delsystem och användningsfall. Fortsätt sedan med ny funktionalitet och felrättningar och till sist fokuseras testerna på regressionstestning av mest affärskritisk funktionalitet, mest feltät funktionalitet och den mest komplexa funktionaliteten. Detta är riskbaserad testning som införs mer systemetiskt i inkrement 2. Riskbaserad regressionstest är typiska testfall som är lämpliga att automatisera som en naturlig del av arbetet i varje iteration. Det som planeras in i en ny iteration bör inkludera implementation av automatiska testfall som alltid behövs exekveras för varje bygge. Dessa

18

bör ingå som en testsvit som exekveras en gång per dygn. I denna optimeringsprocess läggs extra fokus på detta i inkrement 3.

Acceptanstest I detta fall handlar det om innehållet från Product Backlog och Sprint Backlog. Kan Product Owner acceptera det som levererats i Sprint? Detta genomförs av systemtestare och beställare. Fokus ligger på arbetsflöden, användbarhet och prestanda. Prestandatester görs med fördel utanför sprintplaneringen eftersom det är en aktivitet som oftast tar mer än 2 arbetsdagar. Lämpligen används verktyg för att testa systemets prestanda. I detta inkrement av processoptimering görs prestandatest med positiva huvudflöden på en grundläggande nivå. Användningsfall, user stories, arbetsflöden eller hur de ska kallas utvärderas och testas så att systemet garanterar sin lämplighet vilket är en förutsättning för att systemet ska kunna användas i verksamheten. Användbarhet kontrolleras med checklistor och slutanvändare kommer in med kommentarer om systemet. Följande frågor måste kunna besvaras positivt

• Fungerar affärsprocesserna i systemet? • Är kunden nöjd? • Kan affärsnyttan börja räknas hem?

Inkrement 2 Syftar till att förbättra det som tidigare byggts upp och målet med inkrement 2 är att tillägga

• CM strategi • Definiera relevant metrik för att mäta testarbetet • Statusrapportering • Standardiserad dokumentation enligt IEEE 829 • Riskbaserad teststrategi • Change control board

Teststrategin finns dokumenterad och inkluderar statisk och dynamisk test på alla nivåer och målet är att alla moment i strategin ska tillämpas i detta inkrement. Verktygsstödet ökar marginellt för att stödja testprocessen. Fokus flyttas mer mot icke funktionella tester men fortfarande görs funktionella tester i samma utsträckning. Testmiljöerna utökas och kontrolleras strukturerat.

CM strategi och process Versionshanteringen är tydligt definierad. Olika utvecklingsgrenar finns definierade. Ett huvudspår för produktutveckling, ett underhållsspår för akuta rättningar av driftsatt system, olika utvecklingsgrenar för olika projekt och delsystem. Då utveckling sker i separata grenar är det valfritt ifall funktionaliteten ska in i en viss release vilket kan vara bra om arbetet

19

försenats av någon anledning. Funktionaliteten mergas sedan in då den är färdigutvecklad. Branch och merge regler för källkodshanteringen i versionshanteringssystemet och namngivning rekommenderas liksom incheckningsregler. Namngivning av baselines och releaser sker strukturerat enligt fastställda namnkonventioner.

Figur 6. Bild över kodspår i versionshanteringssystemet. Detta är en viktig del av arbetet inom området configuration management att hålla reda på de olika utvecklingsspåren i versionshanteringssystemet. I detta fall räknar vi med en ny release efter varje sprint. Poängen med agila utvecklingsmetoder är just att framstegen mäts i form av körbar programvara. En annan mycket viktig del är att veta vilka komponenter som tillsammans är kompatibla och bildar fungerande system. Idealiskt vet configuration managern dessutom vilka systemkonfigurationer och dess komponenter med versionsnummer som finns installerade i alla olika miljöer för test och produktion. Enhetstester kan genomföras på utvecklingsgrenarna. Integrationstest, systemtest och acceptanstest bör genomföras då utvecklingsgrenens nya funktionalitet mergats in i huvudspåret. Byggsystemet bör kompilera system i sin helhet från huvudspåret. Observera att det är av vikt för hela produktens existens att ha en fullständig förtäckning av hårdvara, operativsystem och installerad programvara med versioner inklusive kompilatorn själv på maskinen där systemet kompileras och byggs ihop. Detta är en högrisk aktivitet och den måste fungera.

Definitioner av metrik Detta avsnitt syftar till att definiera olika mått på framsteg i testarbetet och dessa mått kan kommuniceras till olika intressenter. Statusrapportering, uppföljning, kontroll och styrning av testprocessen kräver metrik. En metod att optimera nyttan av metrik är att tydligt ställa frågan vad målet är med testerna. Sedan väljs vilka frågor som ska besvaras för att avgöra om målet är uppnått. Till sist bestäms vilken metrik som behövs för att besvara dessa frågor. Metrik kan grupperas och klassificeras och nedan följer några konkreta exempel.

Maintenance branch

Main branch

Development branch

Releasetag

Patch releasetag

Prerelease synchronization

20

• Kravhanteringen ger behovet av följande metrik

o Hur många krav finns? o Hur stor del av kraven är implementerade? o Hur stor del av kraven är testade?

• Testfallen ger behovet av följande metrik o Antal planerade testfall o Antal specificerade testfall o Antal testfall med högsta prioritet / totala antalet testfall o Antalet specificerade testfall / antal planerade testfall o Antalet exekverade testfall o Antalet passerade testfall o Antalet fallerade testfall o Antalet blockade testfall

• Felhanteringen ger behovet av följande metrik o Antalet funna fel o Antalet öppna fel o Antalet fel per allvarlighetsgrad o Antalet fel per delsystem o Antalet fel per status o Feldensitet: Antalet fel i förhållande till storleken på systemet (antalet

kodrader) o Antalet funna fel per tidsenhet o Antalet kritiska fel relaterat till totala antalet funna fel o Procent funna fel

• Antalet funna fel för en testnivå / totala antalet fel i denna och efterföljande testnivåer och i produktion

• (systemtest) / (systemtest + acceptanstest + produktion) • (integrationstest) / (integrationstest + systemtest +

acceptanstest + produktion) • Resursutnyttjande ger behovet av följande metrik

o Antalet mandagar för planering och specificering o Antalet mandagar per hittat fel o Antalet mantimmar för att rätta fel o Antalet mandagar för exekvering av testfall

Vad som är normalt är att modellera totala antalet fel eller antalet fel per tidsenhet i en graf över tiden. På så sätt är det möjligt att approximera framtida iterationer och på så sätt komma fram till tidpunkten då systemet är tillräckligt stabilt för att kunna driftsätta. Vanligt är att totala antalet fel uppträder som en s-kurva vid nyutveckling. En trend med antalet funna fel per tidsenhet förväntas vara en avtagande kurva som konvergerar mot noll antal fel per tidsenhet. Det totala antalet öppna fel förväntas minska över tiden och ett konstant antal öppna fel över tider är ett tecken på att fel upptäcks och korrigeras i samma takt. Metriken är viktig att använda i kommunikationen med utvecklare för att kunna fokusera arbetet på att förbättra de delar som uppvisar flest svagheter och fel. Om antalet öppna fel är oförändrat eller ökar kan även detta ge en indikation om att utvecklare är upptagna med något som gör att antalet öppna fel inte minskar.

21

Projektledning eller Scrum Master behöver ständigt information om status för antalet fel, antalet fel per allvarlighetsgrad och delsystem, antalet planerade testfall, hur stor del av kraven som är testade osv. Den metrik som används i kommunikationen mellan projektledning och test är enligt överenskommelse. Det viktiga är att den metrik som används är begriplig och tillför nytta för mottagaren. Viss metrik är till främst för testare och testledare och behöver inte kommuniceras till andra.

Standardiserad dokumentation Nu börjar uppryckningen mot ett mer standardiserat arbetssätt inom test

• IEEE 829 guidar dig till testdokumentation, ha detta som utgångspunkt • BS 7925-2 Standard for Software Component Testing

o Beskriver alla grundläggande testtekniker som används i teststrategin • ISO 9126 tar upp icke-funktionella kvalitetsattribut • IEEE 1028 Standard for Software Reviews and Audits • ISTQB Glossary of Testing Terms

Det ställs högre krav på kvalitet i leveranserna, testresultat måste vara spårbara och en del testmaterial förväntas vara leverabler till kund. Detta kräver en något mer formaliserat sätt att dokumentera. Här rekommenderas en lagom och tillräcklig mängd dokumentation i linje med kundens förväntningar och om dessa saknas krävs tillräcklig dokumentation för att kommunikationen i projektet ska kunna fungera så friktionsfritt som möjligt. Som utgångspunkt för dokumentationen används IEEE 829 som innehåller följande dokument:

Figur 7. Beskrivning av de dokument som ingår i IEEE 829.

Test plan

Test Design Spec

Test Case Spec

Test Procedure Spec

Test Execution

Test Log Test Incident Report

Test Summary Report

Test Item Transmittal Report

Test Item

22

Kortfattad beskrivning av varje dokument görs här. För alla detaljer hänvisas till källdokument för IEEE 829. Test Plan – beskriven tidigare i dokumentet. Test Design Specification - beskrivning av testfall på rubriknivå och beskrivning av den testteknik som ska användas i testet Test Case Specification – Detaljerad beskrivning av testfall med förutsättningar, indata, teststeg och förväntat resultat. Test Procedure Specification – En testdriver för automatiska testfall inklusive setup, start, exekvering, loggning och återställning. Test Execution är inte ett dokument utan det ska bara symbolisera att tester ska genomföras. Test Incident Report – felrapport som administreras i lämpligt verktyg Testlog – beskrivning av utfallet för exekverade testfall. Status och eventuellt falrapport loggas för varje testfall som exekverats. Test Summary Report – en beskrivning av testerna i en iteration eller helt projekt, beskriver vad som testats och dess resultat som ska jämföras med ett kriterium för att mottagaren ska acceptera leveransen. Test Item – en beskrivning av ett testbart delsystem eller system. Test Item Transmittal Report – releasenote som beskriver status för ett delsystem, system eller en komponent. Rekommendation är att använda de olika dokument som ingår i IEEE 829. Notera att det måste gå att underhålla testfallen inom tidsramarna, detta betyder att de inte kan vara alltför detaljerade. Om de ska vara mycket detaljerade behövs fler resurser vilket kan vara motiverat för säkerhetskritiska system där liv står på spel, t.ex. inom medicinteknik, flygindustrin eller då mycket stora ekonomiska belopp hanteras.

Releasenotes Releasenotes förbättrar kommunikationen i överlämningen till nästa steg i arbetsflödet. En testare som får en releasenote av en utvecklare där det står vad som förändrats kan avsevärt öka sin effektivitet i testarbetet. Vad som ska ingå i en releasenote är t.ex.

• Övergripande beskrivning av innehållet • Beskrivning av ny funktionalitet • Rättade fel • Versionsnummer på allt som levererats • Lagringsplats för det som levererats, testresultat etc.

Riskbaserad testning Systemet som är under utveckling växer för varje iteration som går och detta gör att testerna måste prioriteras. Alla testfall som inte är automatiserade kan inte exekveras manuellt vid varje enskild iteration, tiden räcker inte till för det. En grundregel är när en ny testnivå ska testas, t.ex. vid påbörjade systemtester, körs ett sanitetstest ”smoke test” där den mest affärskritiska funktionaliteten testas först, följt av ny funktionalitet, rättningar och riskbaserad regressionstestning av tidigare utvecklad funktionalitet och egenskaper. Konceptuellt handlar riskbaserad testning om att fokusera på det mest affärskritiska, mest komplexa och det mest feltäta områdena.

23

Grunden till riskbaserad testning är en riskanalys som syftar till att

– Klargöra projekt och produktrisker – Prioritera affärskritisk, komplex och feltät funktionalitet

Riskbaserad testning har som syfte att – Fokusera alltid på att reducera riskerna för haveri! – Välj rätt områden, testnivåer och testtyper samt prioritera hur mycket tid som

ska läggas på vardera testtyp – Uppdatera riskerna kontinuerligt

Riskerna bör justeras veckovis och hela teamet hjälper till att kommunicera riskerna. Ju mer man vet och ju fler som hjälper till med riskarbetet desto bättre. Sträva efter att skriva nya testfall och utveckla testfallen kontinuerligt och anpassa dessa till de risker som finns. Då ett fel upptäcks skrivs ett nytt testfall för detta om det inte redan fanns. Detta gäller såväl enhetstester som tester på andra nivåer. Det är alltid bra att ha ett test som säkerställer att felen inte uppkommer igen vilket är en möjlighet om versionshanteringen inte fungerar. Viktigt att variera indata i testfallen över tiden, annars upptäcks nästan inga nya fel.

Webbsystem Detta avsnitt förklarar inte några testtekniker ingående utan ska bara ytligt beskriva vad som har högst prioritet för webbsystem eftersom så många system som utvecklas idag görs för webben. Allt förklaras i detalj i andra kapitel. I dagens samhälle används i större och större utsträckning webbaserade system och det ställer krav på en viss typ av egenskaper där följande testfokus rekommenderas

• Funktionalitet o Detta testas med standardtekniker för testdesign beskrivna enligt BS7925-2

• Användbarhet o Testas med checklistor som uppdateras kontinuerligt

• Säkerhet o Tester som säkerställer skydd mot SQL-injection, XSS, buffer overflow. o Behörighetstester är också en viktig del

• Prestanda o Antalet användare är svårt att förutsäga o Analysera framtida användning och designa lastmodeller o Vid exekvering: övervaka minnesutnyttjande, svarstider, CPU utnyttjande samt

loggfiler o Är systemet skalbart? o Är det robust?

• Kompatibilitet o Webbläsare, operativsystem och kombinationer av dessa

Ickefunktionell test När fokus flyttas mot mer icke funktionella tester är det följande typer som bör ingå och dessa kräver specialtekniker

24

• Säkerhet – systemet analyseras på alla nivåer och en attackplan utvecklas för att hitta eventuella säkerhetshål. Dessa tester kräver specialutbildning av den som testar. Funna fel måsta hanteras med största möjliga diskretion och dessa fel får ej hanteras i ordinarie felrapporteringsverktyg.

• Prestanda –systemets förväntade användning analyseras i detalj och testas med produktionslik last. Vilka användare finns det, vad gör dessa och hur ofta? Testfall och verklighetstrogna lastmodeller designas, implementeras och exekveras med verktyg. Normalfallet är att designade testfall och scenarion spelas in med ett verktyg. Genererade skript parametriseras för att de ska bli portabla mellan miljöer och för att testdata ska kunna separeras från testfallet. Prestandatestverktyget kan sedan simulera ett antal användare genom att exekvera skripten.

• Användbarhet testas med checklistor. Referensanvändare från den verksamhet som ska mottaga systemet kan vara med och genomföra användbarhetstest.

• Installerbarhet – systemet ska ha en dokumenterad procedur för att installeras i en ny miljö. Ett system som ej går att installera har inget värde alls för slutkunden.

• Kompatibilitet – olika webbläsare och operativsystem ska kunna användas. Det kan uppstå ett stort antal kombinationer av operativsystem, servrar, databaser och webbläsare. Detta hanteras med fördel med pairwise testing och allpairs algorithm som kan skapa testfall med tillräcklig testtäckning med endast en bråkdel av det totala antalet möjliga kombinationer.

• Tillförlitlighet – ett system har ofta krav på sig att vara tillgängligt 99.5% av tiden eller liknande. För att garantera detta bör tester göras där en större mängd transaktioner exekveras och sedan räknas antalet fel och på så sätt kan andelen transaktioner utan fel av det totala antalet transaktioner svara för om tillförlitligheten är acceptabel.

• Skalbarhet – systemet ska vara modulärt uppbyggt. Skalbarhet är mycket viktigt om det inte går att fastställa utvecklingen av antalet användare över tiden. Ett exempel kan vara webbsystem som till en början kan ha hundratal användare för att efter några år ha miljontals användare.

• Underhållbarhet – kod som är skriven enligt guidelines, har cyklomatisk komplexitet under 10 och är logiskt uppdelad i moduler har goda möjligheter att vara enkla att underhålla för nytillkomna framtida utvecklare. Detta är viktigt eftersom systemen förväntas ha lång livstid med föränderliga krav och omvärld. Guidelines för koden bör beskriva nödvändig koddokumentation för att det ska vara rimligt enkelt att sätta sig in i koden.

• Fail-over – här testas när olika kopplingar mellan delsystem eller delsystemen i sig själva slutar fungera. Vanligt är att ha ett krav på att databaser ska vara redundanta, dvs. om en slutar fungera av någon anledning kan den andra användas som ersättare. Denna princip kan användas på alla systemets delsystem och länkar.

Change Control Board De fel som uppkommer i test har olika karaktär. Systemets olika intressenter upplever att felrapporterna har olika prioritet att bli lösta. Product owner, scrum master, testledare, supportpersonal eller arkitekt kan ha vitt skilda prioriteringar kring vilka felrapporter som ska lösas först eftersom de har olika intressen. Av denna anledning införs ett felklassningsråd som leds av configuration manager och hålls 1-2 gånger i veckan för att gemensamt prioritera felrapporterna och vid konfliker så avgörs configuration manager vad som ska ske med felrapporten.

25

Testmiljöerna För att få ut maximalt av testerna gäller det att ha olika separata miljöer för olika testtyper. Funktionell test, prestandatest och acceptanstest bör ha separerade miljöer så att dess tester inte ska störa varandra eller påverkas av omladdning av data. De olika miljöerna kan ställa olika krav på mängd hårdvara. Test av prestanda, skalbarhet, fail-over etc ställer mycket högre krav på relevant infrastruktur i förhållande till produktionsmiljön jämfört med den miljö där de funktionella testerna genomförs. Versionshantering vid uppsättning av test och driftmiljö måste fungera. Det är viktigt att alltid veta vilka versioner av systemen som finns installerade i respektive miljö, annars går det ej att återskapa och korrigera fel som upptäcks. Det bör alltid finnas förtäckning över de systemkonfigurationer som innehåller kompatibla delsystem och komponenter. Maskinerna bör även ha en förtäckning över vilka operativsystem och programvara med versioner som ska finnas för att systemet ska kunna installeras.

Miljöer Komponenter Integrationstest Funktionstest Prestandatest Acceptanstest Produktion

Databas 1.2.0 1.0.0 1.0.0 1.0.0 1.0.0

Server 1.2.1 1.0.1 1.0.1 1.0.1 1.0.1

API 1.3.0 1.0.2 1.0.2 1.0.2 1.0.2

GUI 2.0.1 1.2.1 1.2.1 1.2.1 1.2.1

Komponent 1 1.0.4 1.0.0 1.0.0 1.0.0 1.0.0

Komponent 2 2.0.2 1.0.2 1.0.2 1.0.2 1.0.2

Komponent N 2.0.0 1.0.0 1.0.0 1.0.0 1.0.0

MS SQL 2005 2005 2005 2005 2005

Windows Server 2003 2003 2003 2003 2003

… … … … … …

… … … … … …

Figur 8. Förtäckning över installerade systemkonfigurationer i olika miljöer.

Testdata Testdata bör vara avidentifierad från känslig personinformation eller annan icke offentlig information. Testdata bör kunna laddas i en miljö regelbundet så att ett idealt utgångsläge för tester kan skapas. Testdata kan versionshanteras och eventuellt skapas med verktyg. Ett alternativ är att en databas administratör justerar befintlig produktionsdata så att den avidentifieras.

Versionshantering av testmaterial På samma sätt som versionshantering sker med källkod bör detta ske även för testdokumentationen. Drivers som används för automatiska tester bör behandlas på samma sätt som källkoden för systemet självt. De testfall som skapas bör ses som återanvändbara enheter och följa med produkten. Testfallen underhålls och lever med under hela livscykeln för systemet. Då ett system levereras kan testfallen användas i förvaltning.

26

Driftsättning Innan driftsättning ska göras så måste detta förberedas med en detaljplan och det finns många viktiga saker att tänka på. Här följer en lista på aktiviteter:

• Gör en säkerhetskopiering av databasen • Installera de program som behövs i driftsmiljön, det ska finnas en lista på alla program

som behövs inklusive den egenutvecklade programvaran. • Skriv en plan vad som ska hända minut för minut den dag som systemet ska

driftsättas, observera att planen ska testas i en testmiljö innan den genomförs i en driftsmiljö.

• Skicka ut information till alla på företaget när driftsättningen ska göras. • Se till att ha rätt personal på plats under driftsättningen ifall något oväntat sker

Överlämning förvaltning Överlämning till förvaltning av testfall, drivers och teststrategi är ett viktigt steg. Det idealiska är att förvaltningen kan återanvända det som skapats. Rutiner för riskbaserad regressionstest skapas. En systemägare i förvaltningen utses. Supportansvarig i utvecklingsorganisationen utses.

Inkrement 3 Målet för inkrement 3 är att följande ska finnas och fungera

• Test management verktyg som hanterar releaser, krav, testfall, sprintplanering, felhantering, spårbarhet mellan krav, testfall, felrapporter och releaser

• Verktyg för testexekvering såsom prestandatest, testautomatisering av datadriven funktionell regressionstest med fokus baserad på formell riskanalys

• Ansvarsfördelning är klar, alla kommunikationsvägar är definierade, information om byggen, testexekvering, risker, nya releaser finns på intranätet

• Formell statisk testprocess med beskriven strategi inkluderat walkthrough och inspection

• Testhandbok • Mätbart exitkriterium

Testverktyg Nu gäller det att införa verktygsstöd i så stor utsträckning som möjligt för den testprocess som utvecklats. Verktygen ska öka effektiviteten och noggrannheten i arbetet och på så sätt frigöra tid och resurser. Då kan förbättringar och ytterligare automatisering göras. Här förklaras olika typer av verktyg som stödjer testprocessen:

• Testledningsverktyg – när testledningsverktyg ska användas rekommenderas att ha ett eller flera verktyg som tillsammans kopplar ihop releasehantering, krav, testfall, testplanering med testlogg och felrapporter. Ännu bättre är det om versionshanteringsverktyget kan integreras i detta. Viktigast är att ha spårbarhet

27

mellan krav (design eller komponentspecifikation) och testfall för att kunna göra påverkansanalys vid kravförändring eller mäta kravuppfyllnad.

• Felrapporteringsverktyg – detta är ett absolut måste och var i princip en förutsättning från början. Kan användas för avvikelser i dokumentation såsom kravspecifikation eller designmodell vilket ökar fokus på att få ärendet korrigerat.

• Versionshanteringsverktyg var från början en förutsättning för att ett team ska kunna samarbeta med implementationen av ett system.

• Statiska testverktyg – Statisk analys är i regel integrerat i ett modernt utvecklingsverktyg. Det finns även verktyg för att stödja formella granskningsprocesser där statistik och annan information kan loggas för att optimera granskningsprocessen.

• Modelleringsverktyg kan användas för att verifiera design • Testdesignverktyg för att modellera indata och utdata. • Testexekveringsverktyg kan vara otroligt mycket och mängden verktyg växer ständigt.

Detta kan handla om länktestverktyg, prestandatestverktyg, monitoreringsverktyg, säkerhetstestverktyg, kodtäckningsanalys, simulatorer för inbyggda system, drivers och stubbar för enhets och integrationstestning. Verktyg för datadriven funktionell regressionstest. Dessa verktyg kan vara kommersiella eller egenutvecklade.

Ett tecken på en hög mognadsgrad i testprocessen är att verktygsstöd används i hög utsträckning. Viktigt att tänka på är dock att verktyget inte kan ersätta kompetens. Testprocessen måste definieras innan verktyget ska kunna stödja testprocessen.

Kommunikationskanaler Kommunikationen mellan roller på olika nivåer i organisationen måste fungera och detta är en lista av olika processer som måste fungera för att testprocessen ska anses vara optimerad. Använd alla tänkbara hjälpmedel såsom instant messaging, intranät, telefonkonferens, videokonferens, automatiska mail, men framför allt verkliga möten med människor.

• Felrapporteringen fungerar, fel blir rättade i prioritetsordning och antalet öppna fel minskar över tiden

• Leverans av delsystem till test fungerar med intern releasenote och historik på intranät eller motsvarande

• Release av nya delsystem till driftmiljön fungerar enligt beskrivning, releasenote skriven och historik finns skriven på intranät

• Kravhanteringsprocessen fungerar och det finns inte utspridda, omätbara, icke testbara och splittrade krav

• Kommunikationen mellan beställare och leverantörer, dvs. Product Owner och Scrum Master fungerar tillfredställande

• Problemlösning vid tekniska problem eller driftsproblem fungerar enkelt och tillräckligt snabbt med så få mellanhänder som möjligt eftersom mellanhänder innebär extra ledtid

• Organisationen förstår varför man måste jobba med test och kvalitetssäkring eftersom det är lägre kostnad att förebygga och korrigera felen innan driftsättningen jämfört med att låta katastrofen vara framme och sedan rätta fel akut med dålig kvalitet och bristande förtroende som följd

• Automatiska regressionstester på enhetsnivå körs alltid innan leverans till testmiljö • Det finns testdata i verklighetstrogen omfattning • Det finns dokumenterat vad som ska levereras och vad som levererats

28

• Gränssnitten mellan alla delsystem finns dokumenterade • Varje problem och leverabel har en ansvarig ägare • Fel rapporteras då de upptäcks och i så få felhanteringssystem som möjligt. Idealiskt

är kund och leverantör inne och administrerar i samma system. • Andelen specialfall hålls alltid minimalt både avseende kod, processer,

problemlösning etc. Grupper av problem löses alltid på ett så enhetligt sätt som möjligt

• Utvecklingen är personoberoende, dvs. utvecklare eller testare kan ersättas om de försvinner från organisationen

Strategi för statisk test Här beskrivs en strategi för hur granskning av dokument sker. Det handlar om att använda checklistor, standards, guidelines, planer, procedurer eller andra relevanta riktlinjer vid granskning. Deltagarna har olika kompetenser och fokuserar på olika saker. Ett dokument som granskas av t.ex. 5 olika personer får tillbaka olika återkoppling av varje enskild person. Det är av yttersta vikt för kvaliten att så många olika aspekter och synvinklar blir belysta under granskning. Det är effektivt att ha en uttalad plan att de olika personerna ska titta extra på olika saker och bidra med sin specialistkompetens. En extra krydda är att kunskapen sprids på ett mycket bra sätt vid granskningar.

Exitkriterium Mätbara avslutskriterier för test är av yttersta vikt för att beslut om driftsättning ska fattas på godtyckliga grunder. Avslutskriterier kan vara

• Alla kraven har testfall • Alla kraven är testade • Kodtäckningsgraden är 80% decision coverage • Alla planerade testfall på systemtestnivån är exekverade • Alla högriskområden är testade • Det finns maximalt 3 fel av allvarlighetsgrad Major Fault

Automatisering av regressionstest För att på ett kostnadseffektivt sätt återtesta ett system många gånger är det värdefullt att automatisera regressionstester. Det återbetalas om testerna måste exekveras minst 10 gånger vilket görs under en period på några månader som längst. Rekommendationen är att basera urvalet av testfall för regressionstester på en formell riskanalys. Vid själva implementationen sedan är det av vikt att tänka på att testfallen måste vara möjliga att underhålla. Det kan vara användbart att separera testdata från testfallen och på så sätt skapa datadriven funktionell regressionstest. En god förutsättning för att det ska lämna sig för automatiska regressionstester på systemtestnivå är att den funktionalitet som ska testas anses vara stabil och inte förändras ofta eftersom det är orimligt att uppdatera testfallen inför varje exekveringstillfälle.

29

Testhandbok När arbetet utvecklats mot en högre mognadsgrad är det lämpligt att skapa en testhandbok. Det som bör beskrivas i testhandboken är s.k best practices, alltså sådant som bevisats fungera bra i de olika utvecklingsiterationerna och är sådant som bör återanvändas framöver. Exempel på innehåll i en testhandbok är testnivåer, testtyper, testdesigntekniker, verktygsbeskrivningar, miljöbeskrivningar, regler för kvalitet såsom antal tillåtna defekter vid leveranser, metrik och allmänna tips.

Etablering av forum för kontinuerliga förbättringar För at testprocessen ska fortleva på ett optimalt sätt krävs att återkoppling på vad som fungerar bra och mindre bra görs i varje sprint. Inställningen hos medarbetarna ska vara att försöka förbättra testprocessen i varje sprint. Detta görs naturligt inom Scrum. Det viktiga är att testprocessen får det fokus den förtjänar. De aktiviteter som krävs för att optimera testarbetet kan bli aktiviteter i varje sprint. Testledning och teststrateg kan lista en ”test backlog” med de aktiviteter som krävs för att höja testmognaden vilket på sikt resulterar i mer kostnadseffektiv systemutveckling.

Referenser

• Test Process Improvement, Koomen, Pol • A practitioners guide to software test design, Copeland Lee • Software testing Practice: Test Management, Spillner Andreas • The Software Test Engineer’s Handbook, Bath, McKay • Agile development with Scrum, Schwaber Ken • Agile testing, Lisa Crispin • Real World Software Configuration Management, Kenefick Sean • Foundations of Software Testing: ISTQB Certification, Graham Dorothy • Software Testing – A Guide to the TMap Approach, Pol, Teunissen, Veenendaal • Test och kvalitetssäkring av IT system, Eriksson Ulf • Software Testing Fundamentals, Hutcheson Marnie • BS7925-2 Standard for Software Component Testing • IEEE 829 Standard for Software Test Documentation