Testmanagement för projektledare

Testmanagement för
projektledare
- vad varje projektledare bör känna till om test och
kvalitetssäkring
Staffan Iverstam
Testmanager QualityMinds
Testmanagement för projektledare
© 2013 Staffan Iverstam
Version 1.0
www.qualityminds.se
Kopiering
Använd gärna Testmanagement för projektledare för egen del. Vill du trycka upp ett större antal
kompendier, kontakta författaren.
Har du synpunkter på texten? Hör gärna av dig till [email protected]
2
© 2013 Staffan Iverstam
Testmanagement för projektledare
Om författaren .....................................................................................................................................................................5
Inledning ................................................................................................................................................................................6
Välj rätt fel ........................................................................................................................................................................6
Testmanagement ................................................................................................................................................................8
Vad är kvalitet?...............................................................................................................................................................8
Kvalitet för olika roller ...........................................................................................................................................9
Testplanen och teststrategi .......................................................................................................................................9
Testrapporten .............................................................................................................................................................. 10
Kravgranskning................................................................................................................................................................ 12
Fler fel upptäcks tidigare ................................................................................................................................... 12
Onödiga krav rensas bort ................................................................................................................................... 13
Missade krav upptäcks ........................................................................................................................................ 13
Informationsglappen minskar ......................................................................................................................... 13
Varför görs inte kravgranskning oftare? .......................................................................................................... 13
Riskbaserad test .............................................................................................................................................................. 15
Hantera risker.............................................................................................................................................................. 15
Riskbedömning ........................................................................................................................................................... 15
Arbetssätt för att göra en riskbedömning för produktrisk .................................................................. 16
Testobjekt ................................................................................................................................................................. 17
Testarbetet......................................................................................................................................................................... 18
Icke-funktionella tester ........................................................................................................................................... 18
Funktionella tester .................................................................................................................................................... 18
Testfall vs erfarenhetsbaserade tekniker ........................................................................................................ 19
Testverktyg ........................................................................................................................................................................ 21
Automatiserad testning ...................................................................................................................................... 21
Testmanagementverktyg ................................................................................................................................... 21
Enhetstest ................................................................................................................................................................. 22
Prestandatest .......................................................................................................................................................... 22
Felhanteringsverktyg........................................................................................................................................... 22
Vanliga orsaker till bristande kvalitet .................................................................................................................... 24
Ingen riskanalys eller indelning i testobjekt .............................................................................................. 24
Kompetensbrist ...................................................................................................................................................... 24
Kravhantering ......................................................................................................................................................... 24
3
© 2013 Staffan Iverstam
Testmanagement för projektledare
Tidsbrist .................................................................................................................................................................... 24
Scope creep .............................................................................................................................................................. 24
Risker faller ut ........................................................................................................................................................ 25
Bristande kommunikation ................................................................................................................................. 25
För stort ..................................................................................................................................................................... 25
4
© 2013 Staffan Iverstam
Testmanagement för projektledare
OM FÖRFATTAREN
Staffan Iverstam är utbildad civilekonom med en ekonomie magisterexamen från
Handelshögskolan i Göteborg. Sedan 1996 arbetar han med IT och har under åren varit verksam
inom flera områden – allt från att starta en av de första internetbaserade matbutikerna, via
reseförsäljning på internet till att numera arbeta som konsult inom test och kvalitetssäkring.
Som konsult har han haft olika funktioner i flera utvecklingsprojekt hos såväl stora som
mellanstora svenska företag. Arbetet har bland annat handlat om testledning, testdesign,
prestandatest, testautomatisering, processutveckling, processkartläggning, kravhantering och
projektledning. Han har också hållit utbildningar inom test och kravhantering.
Under flera år har Staffan Iverstam varit styrelsemedlem inom SAST Väst – en ideell
organisation som varje år arrangerar välbesökta möten för personer verksamma inom test av
IT-system.
5
© 2013 Staffan Iverstam
Testmanagement för projektledare
INLEDNING
I rollen som projektledare ingår att fatta beslut om hur ett projekt ska bedrivas. Det krävs inte
djup kunskap i alla områden inom systemutveckling, men tillräckligt mycket behöver man känna
till för att, tillsammans med andra kompetenser, kunna bedöma vilken väg man bör välja.
Något som varje projektledare bör ha viss kännedom om är test och kvalitetssäkring, eftersom
de har en så pass central del i utvecklingsarbetet. I många projekt tar man för lätt på testarbetet,
ofta på grund av att man saknar kunskap om testmanagement och nya metoder för
kvalitetssäkring. En djupare kunskap om testmanagement hjälper projektledaren att tillsätta
rollen som testledare och skapa bra förutsättningar för att, i samarbete med testledaren och
övriga projektdeltagare, skapa en bra programvara och ett lyckat projekt. Området test och
kvalitetssäkring innefattar med andra ord allt rörande hur man arbetar i projektet för att få bra
kvalitet till rätt kostnad och i rätt tid, och påverkar projektledning, kravhantering, utveckling och
test. Genom bra projektledning och bra testmanagement får du bättre förutsättningar att styra
rätt.
Många har erfarit att det kan bli dyrt, kanske till och med väldigt dyrt, att inte tidigt arbeta med
kvalitet i sin programvara. Att åtgärda fel som upptäcks då programvaran redan är driftsatt är
många gånger dyrare än att upptäcka felet tidigt. Brandkårsutryckningar och panikartade
åtgärder är både kostsamma och dåliga för din produkts anseende hos användarna eller
kunderna. Det kan också innebära att organisationen som sedan ska handha produkten får en
svårplanerad arbetssituation som orsakar missnöjda medarbetare. Den här texten syftar till att
ge en grund i testmanagement samt en inblick i de nya metoder och verktyg som används idag
inom test av IT-programvaror.
VÄLJ RÄTT FEL
Det kan kännas olustigt att veta att hur duktiga era systemutvecklare än är och hur mycket ni än
testar så kommer det ändå att finnas kvar fel i programvaran - fel som dina användare förr eller
senare kommer att upptäcka. Tänk då på att ju fler och bättre tester ni gör, desto fler fel kommer
ni att hitta innan produkten tas i produktion. Och ju erfarnare projektdeltagare, desto större
chans att en bra produkt levereras. Men det räcker inte; utan ett genomtänkt arbetssätt kommer
du ändå bli stående med ett projekt som inte kan leverera produkten på grund av för många fel.
Eller så har du en driftsatt en produkt som inte fungerar korrekt och med rasande, missnöjda
användare (och rasande, missnöjda chefer) som följd.
Hur gör du då för att slippa lägga över halva projektbudgeten på att testa programvaran och
ändå bli stående med otrevliga felrapporter efter att den börjar användas? Det finns ingen enkel
genväg, men genom att arbeta på ett genomtänkt sätt genom hela projektet kan felen minimeras.
Då man utvecklar ett system måste man först och främst välja vilken kvalitetsnivå systemet ska
ha. Ju högre kvalitet, desto mer kommer det att kosta i timmar av utvecklingsarbete som
systemdesign, programmering och test. Med detta sagt bör man dock veta att det är svårt,
kanske till och med omöjligt, att bygga ett program som är utan fel. Ett program kan användas på
6
© 2013 Staffan Iverstam
Testmanagement för projektledare
tusentals sätt. Olika användare gör olika saker, använder olika inmatningar av förväntade och ej
förväntade värden, trycker på rätt och på fel knappar, installerar programmet på datorer som
alla ser olika ut, etc. Ska du försöka att testa alla möjliga varianter får du skaffa dig en rejält stor
budget. Fel i programvaror är alltså något vi måste acceptera. Därför gäller det att upptäcka de
kritiska fel som man inte vill råka ut för då systemet används. Kritiska fel är fel som gör
programmet obrukbart, kanske på grund av alltför långa svarstider, eller till och med att
programmet slutar att fungera.
För att undvika att drabbas av kritiska fel då programvaran är i drift, behöver man arbeta med
testmanagement och väl valda test strategier.
7
© 2013 Staffan Iverstam
Testmanagement för projektledare
TESTMANAGEMENT
Testmanagement är aktiviteten att planera och leda test- och kvalitetssäkringsarbete för att i
slutändan kunna bevisa att de krav man ställt på systemet är uppfyllda. Det ingår också att
upptäcka och peka ut de problem som finns innan programvaran sätts i drift.
Testmanagement drivs av testledaren. Denna roll är viktig eftersom en bra testledare måste ha
fokus på att upptäcka fel och vara ifrågasättande när det gäller programvarans kvalitet. En
projektledare däremot, har fokus på leverans. Det gör att projektledaren kan förbise viktiga
kvalitetsbrister som visar sig först då programvaran används.
Testledaren ska istället fungera som projektledarens förlängda
arm och bör ges uppdraget att slutligen rekommendera, inte
besluta, om man kan driftsätta programvaran eller ej. I sin
Apple maps lanserades
testrapport behöver han eller hon kunna påvisa att kvaliteten
under hösten 2012 – en
är tillräcklig eller om mer arbete krävs. Testledaren behöver
lansering som visade sig inte
ha tillräcklig teknisk kompetens för att kunna förstå tekniska
vara så lyckad. Gatunamn
problem som kan uppstå. Han eller hon behöver också ha
och platser saknades, städer
tillräckligt med kännedom om kvalitetssäkring för att kunna ta
låg helt felplacerade. Bland
fram ett lämpligt arbetssätt i ert projekt.
annat så låg Stockholm i
Vallentuna och Göteborg
I testmanagement görs val av test och
fanns inte med alls. Många
kvalitetssäkringsmetoder som exempelvis
andra orter var helt
riskhantering
malplacerade.
olika former av granskningar
teststrategier
testtekniker
mätetal
testverktyg


Det är upp till testledaren att använda och kombinera olika tekniker, metoder och verktyg som
kan bidra med att programvaran levereras i tid, fungerar väl och enligt kravställd funktionalitet.
Hur man uppnår detta skiljer sig från projekt till projekt, beroende på programvarans
komplexitet och projektets valda arbetssätt.
Valen testledaren gör dokumenteras i testplan och/eller teststrategi. Detta kan vara två skilda
dokument och ibland innehåller testplanen avsnittet teststrategi.
VAD ÄR KVALITET?
Innan vi går djupare in på området testmanagement behöver ordet kvalitet definieras. Kvalitet
är ju kärnan i det som hanteras i testmanagement. Det en person tycker är bra kan en annan
tycka är mindre bra. För att kunna bedöma något så subjektivt som kvalitet kan man använda sig
av olika metoder som har det gemensamt att de objektivt försöker bedöma kvaliteten i en
produkt. Exempelvis kan man använda sig av olika kvalitetskriterier.
8
© 2013 Staffan Iverstam
Testmanagement för projektledare
Då man bedömer ett IT-system använder man sig ofta av ett antal kvalitetskriterier för att
beskriva vilka förväntningar, krav och vilken användning som ett system eller en programvara
ska klara av. Följande kvalitetskriterier är vanliga:
funktionalitet
tillförlitlighet
underhållbarhet
prestanda
användbarhet
portabilitet
Vad som bedöms vara av bra kvalitet beror på vem
användaren är och programvarans användningsområde. För
vissa är exempelvis användbarhet och funktionalitet
avgörande medan andra kriterier inte är lika viktiga. Bygger
du en mjukvara för att rapportera in fakturor för en
ekonomifunktion ska gränssnittet vara enkelt och gå snabbt
att använda utan stora krav på att vara snyggt. Bygger du en
programvara som du ska sälja till designintresserade personer
är kravet högre på att gränssnittet ska vara snyggt. Bygger du
en programvara som ska vara en del i miljontals
banktransaktioner har du kanske extremt höga krav på att den
aldrig ska göra fel, men mindre krav på design. Bygger du å
andra sidan en mjukvara för ett flygplan kanske den inte tillåts
göra minsta fel för att undvika allvarliga olyckor.
KVALITET FÖR OLIKA ROLLER

I maj 2010 skulle Volvo
demonstrera sitt nya system
med en bil som själv
bromsar. Man hade visning
inför massvis med
journalister. Men istället för
att stanna körde bilen rakt
in i släpet. Teorin var att en
snabbladdning av batteriet
hade förstört mjukvaran
som skulle bromsa bilen.
Det hade varit bra om de
hittat detta problem i någon
tidigare test än under
demonstration av systemet.
Du måste alltså först bestämma dig för vad hög kvalitet är i
varje programvara och vilka roller som du utvecklar för.
Användaren av programvaror kan vara en eller flera roller. Om
du utvecklar en mobilapplikation så har du en slutanvändare
som ska ha appen i sin mobil och som ska använda de
funktioner du tagit fram. Om du istället bygger en webbplats som ska leverera spel eller mobila
tjänster så har du flera olika roller som ska hantera programvaran; dels har du slutkonsumenten
som använder sig av webben, dels har du dem som ska lägga in spel och annat innehåll på
webbplatsen som kunden ska kunna köpa. Ytterligare roller har dem som ska installera och
sköta webbplatsen när den är i drift. Det går snabbt att hitta flera olika användare som ska trivas
med att arbeta med programmet och/eller webbplatsen. Funktionerna ska fungera, det ska vara
ett lättanvänt och snyggt användargränssnitt.

TESTPLANEN OCH TESTSTRATEGI
Testplanen ska beskriva hur tester ska göras för att verifiera att ni tagit fram programvara av
den kvalitet som är beställd. Testplanen beskriver vilka delar som ska testas och vilka delar som
inte ska testas, till exempel om det finns delar av programvaran som ligger utanför projektets
9
© 2013 Staffan Iverstam
Testmanagement för projektledare
åtagande och som ska testas av andra. Planen ska också beskriva hur testledaren har delat in
programvaran i testobjekt, vilka som ska arbeta med testerna, vilka risker som finns, etc. Viktigt
är att testplanen är ett levande dokument som fylls på vartefter testledaren lär sig mer om
programvaran och hur den ska användas. Ofta är det kopplat en tidplan till testplanen, ibland är
tidplanen en del av testplanen.
Teststrategin beskriver angreppssättet för testerna och bestäms bland annat utifrån hur kritisk
programvaran är, vilken tid man har på sig, vilka testresurser (både personer och verktyg) som
finns tillgängliga och hur ny teknik som används. Vanliga strategier är riskbaserad testning och
en blandning av tekniker såsom black-box-tekniker, utforskande test, kravgranskning och
granskning av programvara med hjälp av checklistor. Dessutom förekommer ofta en stor del
automatiserad testning.

TESTRAPPORTEN
Innan driftsättning av programvaran ska testledaren leverera
en testrapport som bevisar eller avvisar att programvaran
utför det den ska och är av den kvalitet som är beställd.
Rapporten ska alltså påvisa de fall där kvaliteten inte är enligt
beställarens krav eller där det finns problem som behöver
belysas. En sådan rapport kan innehålla följande punkter:
Vid införandet av ett nytt
affärssystem visade det sig
att leverantören av systemet
nyligen bytt teknisk
plattform. Enligt säljaren
skulle det inte vara några
problem, men vid
acceptanstest upptäcktes
massvis buggar, både stora
och små, och driftsättningen
fick skjutas fram till dess att
systemet blivit användbart.
En sammanfattning av testledarens bedömning av
mjukvarans kvalitet.
Levererade krav samt eventuella ej levererade krav.
Genomförda tester samt eventuella ej genomförda
tester för varje del av mjukvaran (varje testobjekt)
o funktionella tester
o icke funktionella tester, såsom prestanda,
uthållighet och säkerhetstest.
Antal inrapporterade fel och andra mätetal.
Rekommendation till projektledare eller annan beslutsfattare hur man bör fortsätta, om
vissa områden är problematiska och behöver extra fokus, etc.

Testrapporten fyller en viktig funktion under hela utvecklingen av programvaran och ska
skrivas efter varje avslutad fas och efter avslutat projekt. (Faser kan vara sprintar, iterationer,
testnivåer såsom systemtest, acceptanstest, etc.).
Målgrupperna för testrapporten är projektledaren, styrgruppen och andra som behöver veta hur
programvaran fungerar. Det är viktigt att påpeka att projektledaren är ansvarig för att
säkerställa att rapporten skrivs, även om ansvaret är delegerat till testledaren. Testledaren är
inte sällan fullt inbegripen i dagligt arbete under tidspress och det är då lätt att skjuta på
10
© 2013 Staffan Iverstam
Testmanagement för projektledare
rapporteringen. Kom ihåg att rapporten är en alltför viktig del i projektet för att inte skrivas eller
läsas, så kräv in den!
När testledaren skriver sin testrapport och då sammanfattar status på testarbetet och
programvarans kvalitet, tvingas denne att fundera över sina beslut och sina framsteg. I det här
skedet upptäcks inte sällan sådant som behöver åtgärdas, till exempel att ett område inte är
tillräckligt testat eller att oroväckande många fel visar sig i kritiska delar av programvaran. Detta
kan då åtgärdas av projektet och i testas i senare tester.
11
© 2013 Staffan Iverstam
Testmanagement för projektledare
KRAVGRANSKNING
Till grund för utvecklingen av en programvara ligger kraven från beställaren. För att nå en bra
beskrivning av kraven krävs att man:
inhämtar kunskap från många inblandade
har en bra kommunikation för att få fram allas kunskap och önskemål
tydliggör vilket behov systemet ska fylla
rensar bort det som programvaran inte ska göra.
Det finns undersökningar som visar att så mycket som ca 50 %
av felen i en programvara härrör från kraven. Om vi kan hitta
felen redan vid kravarbetet kan vi alltså arbeta mer effektivt.
Ett fel som hittas och korrigeras innan utvecklingen påbörjats
tar betydligt mindre resurser i anspråk, kanske endast en
minut, än ett fel som hittas i drift som kan ta flera dagar att
åtgärda. Istället för att kunna finputsa på mjukvaran för att få
den perfekt behöver ni arbeta in i det sista för att den ska gå att
använda.
Hur gör man då för att undvika detta? Ett bra sätt är att
granska kraven innan de godkänns.
Genom att göra en kravgranskning kan man
upptäcka fler fel i ett tidigare skede
rensa bort onödiga krav
upptäcka missade krav

En bit in i 2000 talet
infördes ett nytt system för
spårinformation för
pendeltåg. Skyltarna på
perrongerna skulle ange på
vilket spår som tåget skulle
inkomma. Tyvärr fanns en
bugg som visade sig att då
ett tåg av någon anledning
fick byta spår mot det i
förhand planerade så
visades det inte på
perrongskyltarna förrän
precis då tåget anlände till
stationen.
minska informationsglappen.
FLER FEL UPPTÄCKS TIDIGARE
Genom att granska kraven kan man redan på skrivbordsstadiet upptäcka många fel. Exempel:
Om ett krav säger att man ska kunna ange förnamn, efternamn och telefonnummer då man
registrerar sig så kanske det senare finns krav som säger att man ska kunna nå kunderna via
mail. Då behöver kravet uppdateras med att man också ska ha ett fält där kunden skriver in sin
e-mailadress.
Se till att personer från olika områden är med i granskningen, inte minst testare/testledare som
förmodligen tillhör de bästa granskarna. De är kritiska, vana att granska krav och har ofta stor
kunskap om systemet. En erfaren testare funderar instinktivt på hur kravet ska testas i testfall
och testdata, och på så sätt kan du upptäcka luckor eller tvetydigheter i kraven.
12
© 2013 Staffan Iverstam
Testmanagement för projektledare
ONÖDIGA KRAV RENSAS BORT
Genom att göra granskning av kraven upptäcker man inte bara fel tidigt, utan också oviktiga
krav. Det projektgruppen hoppades på att kunna lösa med hjälp av kravet kanske går att lösa
med en befintlig funktion i systemet, eller så har man ändrat sitt planerade arbetssätt så den
funktion man kravställt inte längre kommer att användas.
MISSADE KRAV UPPTÄCKS
Kravarbete är svårt och hur väl man än försöker fånga alla krav är det lätt att missa mycket. Med
hjälp av en kravgransknig tar man en ny vända med kraven som får synas av många och på så
sätt upptäcks eventuella luckor.
INFORMATIONSGLAPPEN MINSKAR
När flera delprojekt ska leverera en lösning är det stor risk för
informationsglapp. Det är svårt att se till att information hela
tiden delges alla och det är lätt hänt, när trycket ökar, att de olika
projekten fokuserar mer och mer på sin egen leverans och inte
har tid att prata med övriga projekt. Då är risken stor att man mot
slutet ser att leveranserna, som är beroende av varandra, inte
överensstämmer.
Exempel:
En projektgrupp utvecklar ett webbgränssnitt i en applikation och
en annan grupp utvecklar webbtjänster som ska förse
webbgränssnittet med data. Det visar sig att webbtjänstprojektets
kravspecifikation saknar krav på vissa parametrar som
webbgränssnittet behöver. Detta upptäcks först mot slutet av
utvecklingsperioden och projekten behöver lägga mer tid på att
utveckla, eller kanske till och med göra om vissa funktioner.

Vid ett universitet infördes
en ny studentportal, bland
annat skulle studenterna
kunna anmäla sig till tentor
och se sina studieresultat.
När portalen började
användas visade det sig att
studenterna ibland blev
inloggade på andras konton
och fick se andras uppgifter.

Det visar sig att det saknas hela funktioner eftersom kraven i det ena projektet fortsatt att
utvecklas utan att de motsvarande kraven i det andra projektet uppdaterats.
För att undvika informationsglapp är det förstås viktigt att de som arbetar med kravställningen
hela tiden ser till att alla projekt hålls uppdaterade. Det är enkelt att säga men svårare att
genomföra. Ofta är ju IT-projekt under stark tidspress och måste hantera förändrade och
utökade krav som gärna ska hinnas med inom samma tid.
Läs mer om kravgranskning och kravgranskningstekniker …. Länk
VARFÖR GÖRS INTE KRAVGRANSKNING OFTARE?
Med tanke på alla buggar som hittas sent och som kostar mycket att åtgärda - med missnöjda
kunder som följd är det konstigt att inte mer tid läggs på granskning. Varför görs det då inte
mer? Några tänkbara förklaringar kan vara:
13
© 2013 Staffan Iverstam
Testmanagement för projektledare
Kostnaden för att genomföra granskningsarbetet är lätt att räkna ut, men vinsterna är
mycket svårare att se.
Projektledningen, och den som beställt utvecklingen, är inte säker på granskningens
förträfflighet.
Det är svårare att göra bra granskning än att sätta sig med ett program och klicka och
leta fel.
Tidsbrist som slår mot testgruppen. När trycket ökar måste även den mest nitiske
granskare fokusera på att testa leveransen som nyss kommit, istället för att granska
kraven för en framtida version av systemet.
14
© 2013 Staffan Iverstam
Testmanagement för projektledare
RISKBASERAD TEST
HANTERA RISKER
En viktig faktor i prioriteringen av vad som ska utvecklas och testas först är risk. Hur stor är
risken att det finns allvarliga problem inom ett område och vilken effekt skulle dessa eventuella
problem få om de blir verklighet? Man talar om riskbaserad test. I korthet innebär detta att man
analyserar vilka risker som finns som hindrar programvaran och projektet att bli klart i tid med
en bra produkt. Sedan planeras arbetet och omfattningen av testarbetet utifrån denna
riskanalys. Innan vi går vidare in på detta så behöver risker
beskrivas.
Det finns två sorters risker: projektrisker och produktrisker.
Projektrisker tas vanligtvis omhand av projektledare och är
något som en erfaren projektledare alltid hanterar. Exempel
på projektrisker är brist på kompetens och personal,
leverantörsfaktorer där det kan bli kontraktsproblem. Detta
har mindre påverkan på hur programvaran ska utvecklas eller
testas. Produktrisker däremot, är lättare att förbise.
Produktrisker behöver aktivt hanteras av projektet som
utvecklar programvaran. Dessa risker behöver hanteras i
planer och arbetssätt under hela utvecklingen, från design av
programmet till test och leverans.
Exempel på produktrisker:

Det har visat sig finnas
säkerhetsbrister i många
webbplatser, och många
säkerhetsbrister har
säkerligen tystats ner. Det
som man kunnat läsa om är
exempelvis då hackers har
kommit över
användaruppgifter till olika
webbplatser och
kortnummer till betalkort
har stulits.
många fel i den levererade programvaran
möjligheten att programvaran/hårdvaran kan skada
individer eller företag
dåliga programvaruegenskaper (såsom funktionalitet,
tillförlitlighet, användbarhet och prestanda)
programvara som inte utför det den är avsedd för
programvaran kommer hantera känslig information eller vara åtkomlig från internet och
ha högre krav på säkerhet.

RISKBEDÖMNING
Riskbedömningen används för att alla i projektet ska bli medvetna om de utmaningar
programvaran, eller olika delar av programvaran, har. Om det framkommer att en del i ett
program kommer att ställa höga krav på säkerhet så är det viktigt att alla projektdeltagare är
medvetna om det. Den som arbetar med krav kan behöva komplettera med fler krav kring hur
säkerheten ska hanteras. På samma sätt blir de som arbetar med systemarkitektur,
systemdesign och utveckling medvetna om kraven på säkerhet och har det i åtanke vid design
och programmering. Och de som arbetar med test kan se till att fler tester kring säkerhet
planeras och utförs.
15
© 2013 Staffan Iverstam
Testmanagement för projektledare
Inte bara kritiska risker, såsom säkerhet, kan upptäckas. Andra exempel på risker är att en del
funktioner av en webbplats kommer att utnyttjas väldigt frekvent av viktiga kunder.
Utvecklingsprojektet behöver då vara medvetet om detta och säkerställa att dessa funktioner
fungerar bra.
ARBETSSÄTT FÖR ATT GÖRA EN RISKBEDÖMNING FÖR PRODUKTRISK
Följande är viktiga delar i riskbedömning och riskhantering:
Analysera er programvara och dela in den i mindre delar, så kallade testobjekt, för att
kunna se vilka tester som krävs för varje del och för att ni inte ska missa att testa något
vitalt område. Se avsnitt om Testobjekt
Gör en riskanalys och analysera varje testobjekt för sig, så att både ni och de som ska
sköta utvecklingen/testarbetet förstår vilka delar i er programvara som är viktigast. Se
avsnitt om Test/Riskhantering
Planera och utför tester som hanterar den risk som ni kommit fram till. Se till att ni får en
testrapport som belyser vilka tester som gjorts för varje testobjekt, och resultatet av
dessa tester. Se avsnitt om Test/Testrapporten
De i projektet som har inblick i programvaran, bör uttala sig om hur de ser på produktrisken.
Dessa kan vara:
kravställare och användare – kravställaren vet vilka av kraven som är viktiga att de
realiseras och vilka funktioner som är viktigast
projektledare
kunder
systemarkitekter
systemdesigner
utvecklare.
Sammankalla till ett riskmöte med målet att gå igenom alla funktioner i produkten/ testobjekt.
Varje testobjekt behöver tilldelas ett värde för sannolikhet och ett värde för effekt, förslagsvis i
en skala från 1 till 5.
Sannolikheten värderar hur sannolikt det är att det blir problem i funktionen. Sannolikhet är
beroende av hur komplex funktionen är, hur ofta den ska användas mm. Effekt är ett mått på
allvarlighetsgraden om det uppstår ett fel. Ju allvarligare skada, desto högre effektpoäng. Väger
man samman detta, exempelvis genom att multiplicera dessa värden med varandra, så får man
ett värde som kan hjälpa till att bedöma hur viktigt det är att funktionen testas ordentligt innan
driftsättning. Vid utveckling kan det också vara lämpligt att utveckla de funktioner med höga
värden först. Ett vanligt fel är att man inte märker att vissa områden är mer komplicerade än
andra, eller till och med att man väljer att skjuta på komplicerade områden till senare. Det kan
ofta istället vara bra att tidigt adressera dessa områden för att undvika att i slutet av projektet
upptäcka att problemet var större än vad man först trodde. Det innebär ofta att projektet inte
kan avslutas enligt tidplan.
16
© 2013 Staffan Iverstam
Testmanagement för projektledare
TESTOBJEKT
Dela in systemet i testobjekt. Exempel:
Kundgränssnitt
Företagskundgränssnitt
inloggning
inloggning
sökfunktion
sökfunktion
utloggning
utloggning
kundvagn
kundvagn
browsa till artiklar
browsa till artiklar
betalning kort, faktura mm
ansöka om konto
anmälan till kundbrev
betala genom faktura
avbeställning av kundbrev
anmälan till kundbrev
nyregistrering av kund
avbeställning av kundbrev
glömt lösenord
nyregistrering av kund
Administrationsfunktioner
Utskick och rapport
låsa upp spärrat konto
kundregister
lägga upp ny kund
mailutskick till kunder
webbstatistik
månadsrapport
larm vid driftproblem
betalningsrapport
sammanställning av dagens order
Integrationer externa system
Integrationer interna system
bank
affärssystem
kortinlösare
CRM
återförsäljare
Kundtjänst
17
© 2013 Staffan Iverstam
Testmanagement för projektledare
TESTARBETET
När programvaran blir klar börjar den fas i testarbetet då man aktivt arbetar med
programvaran, istället för att, som tidigare, endast ha planerat. Man behöver ha bestämt vilka
funktionella tester och vilka icke-funktionella tester som ska göras. Exempel på funktionella
tester är vanliga testfall och görs för att säkerställa att funktionerna gör det de är tänkta att göra,
till exempel att det går att logga in. Icke-funktionella tester är exempelvis prestandatester och
säkerhetstester.
ICKE-FUNKTIONELLA TESTER
Icke-funktionella tester kräver ofta specialkompetens, såsom kunskap om hur man genomför
prestandatester och hur verktyg för dessa tester ska användas,
eller hur man gör säkerhetsgenomgångar av en programvara.
Grundläggande tester inom dessa områden kan dock erfarna
testare utföra. Ska man utföra egna säkerhetstester för en
Innan release av en ny stor
webbplats rekommenderas att man inhämtar kunskap på
portal gjordes en
exempelvis owasp.org
prestandatest. Det var tur

FUNKTIONELLA TESTER
Funktionella tester är oftast den större delen av testarbetet
och det som de flesta testare och testledare arbetar mest med.
Traditionellt sett har man alltid arbetat med testfall. Hur
detaljerat man beskrivit teststegen och det förväntade resultat
skiljer sig dock åt mellan olika testledare och organisationer.
Hur testfall tas fram beskrivs i olika testdesigntekniker:
att testen gjordes eftersom
portalen visade sig ha ett
stort minnesläckage vilket
gjorde att den slutade att
fungera efter 2 timmars
användning.

blackbox, specifikationsbaserade tekniker
white-box
erfarenhetsbaserade
I black-box-teknikerna arbetar man som om man inte känner till hur programvaran är
programmerad. Man utgår alltså inte från koden utan skriver testfall i form av
användarscenarier och använder specifikationen eller kunskapen hur en funktion ska användas
som underlag för att skriva testfallet. Testdesigntekniker som används är till exempel
ekvivalensuppdelning, gränsvärdesanalys eller användande av beslutstabeller.
I white-box-teknikerna använder man kunskap om koden och planerar och utför test baserat på
olika varianter som finns i koden. Man kan till exempel analysera hur många if … else som finns
och se till att man testar de olika varianterna. Man kan då också försöka mäta hur stor del av
koden man testat.
Erfarenhetsbaserade tekniker har vuxit sig starkare på senare år. I dessa tester utnyttjas
testarens erfarenhet av fel som funnits i andra program man arbetat med, samt testarens
18
© 2013 Staffan Iverstam
Testmanagement för projektledare
generella kunskap om test. Dessa tekniker är mer fria och använder sig inte av testfall i gammal
mening, istället utforskar man oftare programvaran för att aktivt leta fel i själva arbetet med
programvaran. Exempel på testtekniker är utforskande test och sessionsbaserad test. Gemensamt
för dessa typer av test är att man, genom att inte lägga ner lika mycket tid på att skriva testfall,
får mer tid över till test av applikationen. Det är också svårt att komma på alla olika typer av
testfall då man ska skriva ner och planera dem. En duktig testare kommer på många bra tester
under tiden denne arbetar med test av programvaran.
Viktigt att poängtera är att testaren under testen använder sig av sina kunskaper i
testdesigntekniker, det vill säga under testen, så att man till exempel kan testa att mata in
värden i ett inmatningsfält och då använda värden som är framtagna genom gränsvärdesanalys.
Detta är inget som en oerfaren testare kan göra lika bra som en erfaren.
Dessa tekniker har ändå ett regelverk som behöver följas, det är inte tillräckligt att bara sätta sig
och klicka planlöst. Genom regelverket får man fokus på testarbetet, möjlighet att se vilka
områden man testat, ett sätt att kontinuerligt följa upp vad man gjort och välja nästa område att
testa. Man använder ofta testuppdrag så kallade test charters i utforskande test där testaren får
ett avgränsat uppdrag att testa en del av programvaran:
Leta reda på alla fält där användaren kan mata in data och testa dem utifrån fältlängd,
olika varianter av tecken.
Jämför applikationens GUI utifrån den framtagna beskrivningen över våra GUI.
Testa om sökfunktionen ger rätt resultat på sökningar om våra produkter.
Testledaren bestämmer i vilken mån testerna ska dokumenteras, om resultatet av testerna gör
att man känner sig nöjd eller om testerna ska fortsätta inom detta område. Läs mer om dessa
former av test på Wikipedia: exploratory testing, session based testing.
TESTFALL VS ERFARENHETSBASERADE TEKNIKER
Av de tre testdesignteknikerna ovan har black-box teknikerna i många fall inte varit ifrågasatta
alls. Tidigare var det självklart att man skrev detaljerade testfall för hela applikationen. På de
senare åren har det svängt över mer åt man vill använda mer utforskande tekniker. Och detta är
inte enbart i agila projekt utan även då man använt sig av utvecklingsmetod mer lik V-modellen.
De traditionella testfallen är ofta som i exemplet nedan::
Teststeg
Förväntat resultat
Starta en webbrowser och gå till www.xyz.se
Startsida visas.
Logga in genom att klicka på knappen Log in i
övre högra hörnet
Inloggningssida visas där du kan fylla i
användarnamn och lösenord. Knapp med text
Log in.
19
© 2013 Staffan Iverstam
Testmanagement för projektledare
Logga in med användare Jenny Kund genom
att i fältet User skriva JennyKund och i fältet
Password skriva xyz123.
Klicka på knappen Log in.
Startsida för Jenny Kund visas. Sidan ska
innehålla de tjänster som är aktiva för henne.
Längst upp till vänster står Logged in user:
Jenny Kund
Välj tjänst saldo genom att klicka på länk saldo
som är listad i högra menyn.
Sida för saldo visas.
Klicka på Log out
Sida för utloggning visas med text You are now
logging out. Proceed? Med grön knapp Yes till
vänster och röd knapp No till höger under
texten
Klicka på Yes
Du blir utloggad. Startsida visas. Längst upp
till vänster står You are not logged in
Kritiken mot dessa testfall är bland annat att de tar lång tid att skriva - tid som istället kan
användas till faktiska tester. När man sedan testar, utförs exakt dessa steg vid varje testomgång
och risken är stor att man missar viktiga buggar som inte blivit täckta i testfallet. Det finns ju
nästan oändligt många vägar en användare kan ta i en programvara med olika typer av testdata
såsom användare och olika typer av inmatning. Att skriva ner alla dessa varianter i testfallen
skulle ta oproportionerligt lång tid. När sedan funktionaliteten ändras har man hundratals
testfall som behöver skrivas om. Det är också så att en viktig del i testarens uppdrag är att
upptäcka specialfall där det blir fel. Huvudflöden brukar ofta fungera men användarna arbetar
på sina egna sätt och gör långtifrån alltid som manualen säger. Det är svårt att komma på testfall
som tar dessa vägar i programvaran på förhand, och det blir väldigt många testfall som ska
skrivas.
I många projekt väljer man fortfarande att arbeta med detaljerade testfall men en allt större del
av testerna görs med hjälp av utforskande tekniker..
20
© 2013 Staffan Iverstam
Testmanagement för projektledare
TESTVERKTYG
För att assistera i testarbetet finns verktyg för testmanagement, testautomatisering,
felrapportering och ärendehantering.
AUTOMATISERAD TESTNING
Att testa en programvara tar mycket tid och kostar med andra ord mycket pengar. Därför har
Det länge varit en dröm, inte minst för de som betalar för utveckling och underhåll av
programvaror, att kunna automatisera testerna. På senare år
har det blivit allt viktigare, men nu också av andra skäl som att
man arbetar i kortare iterationer och behöver installera och
testa programvaran oftare. Det är dyrt att sköta detta
I december 2012 fick många
manuellt, i den mån man alls hinner. Testautomatiseringen
användare problem med
görs dock inte så som man ofta tänker – att man spelar in
Gmail
och Chrome när en
tester mot det grafiska gränssnittet som sedan spelas upp vid
bugg i en uppdatering av
behov och fel upptäcks och loggas. Trots att det finns bra
Googles mjukvara för
verktyg som används för att automatisera tester mot
lastbalansering, påverkade
webbgränssnitt, exempelvis Selenium, har tyvärr detta sätt att
tillgängligheten av främst
automatisera tester inte lyckats så ofta, mycket på grund av att
Gmail och Chrome. På
det stora under underhåll/arbete som krävs för att ta hand om
Google var de snabba med
dessa testfall så att de fortsätter att fungera. Då ett system
att rulla tillbaka till den
förändras, som det ofta gör då man bestämmer sig för att
tidigare versionen av
vidareutveckla en programvara, så behöver också de
programvaran och
automatiserade testerna uppdateras. I det arbetet försvinner
problemet
kunde stoppas
mycket av vinsten med testautomatiseringen. Dessutom har
efter 18 minuter.
testfallen tagit ganska lång tid att ta fram i det första skedet.


Istället automatiseras testerna av koden under gränssnittet.
Exempelvis kan en webbapplikation bestå av ett
webbgränssnitt som är programmerat i html. Under det finns
annan kod som är programmerad i java, som kanske har kontakt med databas och andra system.
Javakoden är lättare att programmera tester emot, i det att den inte ändras lika mycket som
webbgränssnittet. Populära verktyg är exempelvis Fitnesse, JMeter, Cucumber som kan
användas för dessa tester. Om ni istället utvecklar webbtjänster som andra system ska kunna
anropa så finns exempelvis SoapUI, men också JMeter används ofta i dessa tester. I dessa fall är
det dock inte frågan om man ska automatisera testerna utan hur mycket. Gränssnitten är mycket
lämpliga att skapa automatiserade tester mot och verktygen används också för att göra
prestandatester för att verifiera att programvaran klarar att hantera den förväntade storleken
på användandet. Verktygen som nämnts ovan finns som gratisverktyg, men det finns också
liknande verktyg från leverantörer som Microsoft, HP och IBM. Alternativet finns också att
utveckla egna verktyg.
TESTMANAGEMENTVERKTYG
21
© 2013 Staffan Iverstam
Testmanagement för projektledare
De vanligaste verktygen för att stödja testarbetet är sådana för att hantera testfallen och för att
ta fram statistik över antal testfall, antal tester som gjorts, hur många tester som genomförts
med lyckat resultat etc. Att använda liknande verktyg i någon form är stort stöd i de flesta fall av
testarbete. Övrigt stöd för testmanagement är ganska skralt, det som används mest är kalkylark,
ordbehandlingsprogram och tidplaneringsverktyg liknande Microsoft Project.
ENHETSTEST
Programmerarna har en mycket viktig del i test- och kvalitetssäkringsarbetet. Dels innebär det
att ju duktigare de är, desto mindre fel finns och desto mindre tid krävs i testarbetet. Men det är
dessutom så att programmerarna är ansvariga för enhetstester, det vill säga testerna av sin egen
kod. Till hjälp har de testverktyg som JUnit och NUnit som hjälper dem att automatisera tester av
deras programkod. Bra användning av detta gör en hel del för programvarans kvalitet. Bland
annat eftersom de tidigt testar om koden fungerar eller om den blivit påverkad av ny
funktionalitet man byggt.
Ett problem man behöver hantera är att programmerare för det mesta inte har den största
kunskapen inom test, och de lägger inte heller ner så mycket tid på sina enhetstester som de
borde. Kvaliteten på programvaran som de lämnar ifrån sig till de som ska sköta testarbetet kan
för det mesta bli bättre. Som projektledare kan du, tillsammans med testledaren, fundera på hur
ni ska kunna förbättra enhetstesterna. Ett exempel är att se till att ni håller en utbildning inom
enhetstest och testteori för utvecklarna. Ni kan också ta fram checklistor och annat som
kontrollerar att koden blivit bra testad innan den lämnas över till nästa testnivå (till exempel
systemtest eller integrationstest).
Inom agil utveckling försöker man hantera problemen ovan på olika sätt, bland annat genom att
se till att testare och utvecklare samarbetar i utvecklingsarbetet Läs mer om agil utveckling.
PRESTANDATEST
Oftast behövs någon form av prestandatest av programvaran, både under utvecklingsarbetet och
efter att (man tror att) utvecklingen är klar. Olika verktyg är gjorda för olika typer av
programvaror. JMeter är ett open source-verktyg som med fördel kan användas både i tester av
webbapplikationer, databaser och webbtjänster, mm.. Det finns också en uppsjö av verktyg där
man behöver köpa licenser. Dessa licenser kan vara väldigt dyra, men är det viktigt att verifiera
prestandan kan det vara värt att lägga ner dessa pengar. Verktygen är ofta också enklare, och går
snabbare att skapa script och analysera resultatet för dessa tester, och du sparar in
arbetskostnaden genom att använda dessa verktyg istället för gratisverktyg.
Exempel på verktyg där du behöver köpa licens är Loadrunner och Neoload. För prestandatest
av webbtjänster finns som tidigare nämnts JMeter men också SoapUI.
FELHANTERINGSVERKTYG
En absolut hörnsten i testmanagement är verktyg för att hantera felrapporter. Ofta upptäcks så
mycket fel i en applikation då man testar att utvecklarna inte hinner åtgärda allt på en gång. För
att inte glömma bort att rätta till defekter, används felhanteringsverktyg. Exempel på vanliga
22
© 2013 Staffan Iverstam
Testmanagement för projektledare
verktyg är Bugzilla, JIRA. Men många testmanagementverktyg har också denna funktionalitet
inbyggd.
23
© 2013 Staffan Iverstam
Testmanagement för projektledare
VANLIGA ORSAKER TILL BRISTANDE KVALITET
Det mest effektiva sättet att lyckas med kvalitet är att inte skapa felen överhuvudtaget. Det finns
en mängd olika metoder och teorier som försöker hantera detta. Följande kapitel försöker inte
ge en heltäckande bild utan lyfter fram vanliga problem som jag sett och som är allmänt kända
som vanliga orsaker till bristande kvalitet i programvaror.
INGEN RISKANALYS ELLER INDELNING I TESTOBJEKT
Ingen analys av systemet är gjord och man vet alltså inte vilka delar som är viktigast att de
fungerar perfekt på det sättet de kommer att användas. Det kan till och med vara så illa att man
inte vet vilka funktioner programvaran består av. Risken är då att man helt glömt att testa olika
viktiga funktioner av programvaran, eller att man testat för lite.
KOMPETENSBRIST
Ett vanligt problem är kompetensbrist, hos såväl beställare som utförare.
Beställare kan ofta ha får dålig kunskap om system och vilka krav man ska ställa. De beställer
också inte helt sällan det de tror de vill ha, men som sedan visar sig inte stämma. Att vara en
duktig beställare kräver en hel del erfarenhet av både IT och den egna verksamheten.
KRAVHANTERING
Kravhantering är ett annat vanligt problem. Det är svårt att sköta detta, speciellt i de fall då man
ofta ska kravställa ett system inom ett område som man inte har tidigare kunskap om och
dessutom saknar kunskap om beställarens verksamhet. En erfaren kravställare kan ofta behöva
börja med att ifrågasätta om beställaren verkligen vet vad de vill ha och vad de behöver!
TIDSBRIST
I början har alla projekt gott om tid. Mot slutet ser man att det är knappt om tid om man börjar
att slarva. Ett stort problem är ofta att man valt att skjuta på svåra saker till slutet, som sedan
kan visa sig väldigt svåra och tidskrävande att lösa.
SCOPE CREEP
Ett vanligt problem är scope-creep. Det innebär att det läggs till mer och mer funktionalitet i
projektet som ska levereras inom samma tidsram, eller med endast en liten förlängning. Då
försämras självklart kvaliteten på programvaran som utvecklas. En väl fungerande programvara
brukar växa fram efter hand. I början kanske man fått fram alla funktioner, men det är mycket
som inte fungerar. Undan för undan börjar felen avhjälpas och färre nya fel tillkommer. När
produkten sedan stabiliserats på en nivå där man känner sig ganska nöjd så kan man slutligen
göra den slutliga putsningen för att för den riktigt väl fungerande och användbar. Det är
programvarans utveckling från att krypa till att lära sig gå. Frågan är om det är värt pengarna?
Många väljer hellre att skapa ett snyggt yttre, vissa välsmorda centrala funktioner medan en stor
del av programmet fortfarande är av ganska dålig klass. Det är ändå ofta till syvende och sist
24
© 2013 Staffan Iverstam
Testmanagement för projektledare
kunden som avgör – kan programmet säljas eller ha tillräckligt nöjda användare så kan det räcka
gott.
RISKER FALLER UT
Prestandaproblem, säkerhetsproblem eller annat som man inte förstått eller lyckats hantera.
BRISTANDE KOMMUNIKATION
Kommunikation och samarbete är en central del i att uppnå bra kvalitet i leveranser; en
deltagare vad som krävs, en annan känner till vilka krav som ställs, en tredje vet hur en
användare kan komma att använda systemet, en fjärde vet hur systemet ska designas och hur
arkitekturen ska vara. Problemet är att denna information sällan når ut till alla som behöver den.
I kapitlet om kravhantering beskrivs vikten av att kommunicera ut kraven så att alla har hela
bilden klar för sig och att de som behöver även ska ha bra kontroll på detaljer. I rollen som
utvecklare är det en framgångsfaktor att kunna fokusera på ett problem och hitta en bra lösning.
Ofta blir utvecklaren tilldelad något arbetspaket som ska utvecklas. Det är också ett ganska
ensamt arbete där många gillar att själva sitta och klura ihop snygga lösningar. Men för att
kommunikation och samarbete ska blomstra krävs en mer social inställning än vad som är
vanligt bland programmerare.
Hur ska då bra kommunikation nås? I de agila utvecklingsmetoderna, exempelvis SCRUM, byggs
möten in som en av grundpelarna i arbetsmetoden. Dagliga, korta möten där varje person får
delge sin status på de arbetspaket man blivit tilldelad. Eftersom arbetssättet också innebär att
man arbetar i små team som är ansvariga för att lösa en uppgift, byggs det in möjligheter för tät
kommunikation och samarbete mellan utvecklare och utvecklare, mellan kund och utvecklare,
mellan kravställare och testare etc. Alla inblandade har korta vägar till att kommunicera med
varandra. Även om ett projekt inte valt att arbeta enligt SCRUM så är det viktigt att planera så att
tät kommunikation mellan alla delar i projektet är möjligt. Det ska vara lätt att ställa en fråga om
det är något man inte förstår, eller att ge ett tips på problemlösning. Det underlättar
kommunikationen om man sitter i samma rum som det övriga projektet, då får man fördelar av
överhörning (man hör några prata om något problem och det är lätt att man själv lär sig av vad
de pratar om eller har något att tillägga bidrar till samtalet).
FÖR STORT
Stora IT-projekt misslyckas ofta. Håll dig ifrån att försöka få till allt från början, genomför hellre
flera små projekt.
25
© 2013 Staffan Iverstam
Testmanagement för projektledare