Optimering av testprocesser i agila projekt Jesper

Optimering av testprocesser i agila projekt Jesper

Optimering av testprocesser i
agila projekt
Jesper Högberg
Våren 2009
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
2
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.
3
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
4
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.
5
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.
6
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.
7
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å.
Kravdefinition
Acceptanstest
Funktionell
systemdesign
Systemtest
Integrationstest
Teknisk
systemdesign
Enhetstest
Komponent
specifikation
Programmering
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!
8
•
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å.
9
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, ickefunktionell 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.
Bestäm inkrement
Utvärdera utgångsläget
Utvärdera resultat
av förändringen
Fastställ vad som
ska göras
Genomför och
implementera
förändringen
Formulera tidsplan för
förändringen
Figur 4. Iterativ modell för optimering av testprocesser.
10
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.
Sprints
1
2
3
Inkrement
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.
11
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
12
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.
13
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.
14
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
15
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.
16
•
•
•
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
17
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
18
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.
Patch releasetag
Maintenance branch
Main branch
Prerelease synchronization
Releasetag
Development branch
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.
19
•
•
•
•
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.
20
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:
Test plan
Test Item
Test Design Spec
Test Item Transmittal Report
Test Case Spec
Test Procedure Spec
Test Execution
Test Incident Report
Test Log
Test Summary Report
Figur 7. Beskrivning av de dokument som ingår i IEEE 829.
21
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.
22
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
23
•
•
•
•
•
•
•
•
•
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.
24
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.
Komponenter
Databas
Server
API
GUI
Komponent 1
Komponent 2
Komponent N
MS SQL
Windows Server
…
…
Integrationstest
1.2.0
1.2.1
1.3.0
2.0.1
1.0.4
2.0.2
2.0.0
2005
2003
…
…
Funktionstest
1.0.0
1.0.1
1.0.2
1.2.1
1.0.0
1.0.2
1.0.0
2005
2003
…
…
Miljöer
Prestandatest
1.0.0
1.0.1
1.0.2
1.2.1
1.0.0
1.0.2
1.0.0
2005
2003
…
…
Acceptanstest
1.0.0
1.0.1
1.0.2
1.2.1
1.0.0
1.0.2
1.0.0
2005
2003
…
…
Produktion
1.0.0
1.0.1
1.0.2
1.2.1
1.0.0
1.0.2
1.0.0
2005
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.
25
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
26
•
•
•
•
•
•
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
27
•
•
•
•
•
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.
28
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
29