9789144117775 by Smakprov Media AB

PRAKTISK MJUKVARUTESTNING

EVA HOLMQUIST

Kopieringsförbud Detta verk är skyddat av upphovsrättslagen. Kopiering, utöver lärares och studenters begränsade rätt att kopiera för undervisningsändamål enligt Bonus Copyright Access kopieringsavtal, är förbjuden. För information om avtalet hänvisas till utbildningsanordnarens huvudman eller Bonus Copyright Access. Vid utgivning av detta verk som e-bok, är e-boken kopieringsskyddad. Den som bryter mot lagen om upphovsrätt kan åtalas av allmän åklagare och dömas till böter eller fängelse i upp till två år samt bli skyldig att erlägga ersättning till upphovsman eller rättsinnehavare. Studentlitteratur har både digital och traditionell bokutgivning. Studentlitteraturs trycksaker är miljöanpassade, både när det gäller papper och tryckprocess.

Art.nr 39512 ISBN 978-91-44-11777-5 Upplaga 1:1 © Författaren och Studentlitteratur 2018 studentlitteratur.se Studentlitteratur AB, Lund Omslagslayout: Jens Martin Signalera Omslagsbild: Shutterstock.com Printed by GraphyCems, Spain 2018

INNEHÅLL

Förord 9

1 Mjukvarutest i praktiken 11 1.1 1.2 1.3

Vad innebär test? 11 Varför testa? 17 Varför är test av mjukvara svårt? 19

2 Sammanhangets påverkan på test 21 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11

Sammanhanget påverkar 21 Standarder 21 Formella krav 22 Typ av system 23 Utvecklingsmodell 23 Samarbete med verksamheten 27 Antal team 32 Antal system 32 Systemets mognad 32 Organisationskulturen 33 Kunderna 35

3 Organisera testarbetet 37 3.1 3.2 3.3 3.4 3.5

Alla är testare 37 Roller i systemutvecklingen 39 Ansvar för kvalitet 43 Testledarens ansvar och arbete 45 Utvecklarnas tester 46

Innehåll

3.6 3.7 3.8 3.9 3.10 3.11

Testarnas uppgift 51 Verksamhetsexperternas tester 51 Andra rollers tester 52 Oberoende testning 53 Test med flera team 55 Exempel på olika sätt att organisera arbetet 57

4 Principer för test 61 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8

Fullständig testning? 61 Felfria system? 61 Avgör mängden tester kvaliteten? 62 Tidig test 62 Riskbaserad test 63 Mer än utveckling 65 Testa kontinuerligt 66 Behov av kalendertid 68

5 Planera test 69 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8

Planering 69 Faser i testarbetet 69 Plan och verklighet 74 Uppskatta testtiden 74 Resursplanering 79 Tidplan 81 När planen behöver ändras 84 Vanliga misstag vid planering 87

6 Ledning och styrning 91 6.1 6.2 6.3 6.4 6.5 4

Transparens och tydlighet 91 Förstå situationen 92 Kommunikation 93 Strukturera arbetet 96 Tillräckligt bra? 99 © F ö rfattar e n oc h S tud e ntlitt e ratur

Innehåll

7 Analysera och designa tester 103 7.1 7.2 7.3 7.4 7.5 7.6 7.7

Stabila system 103 Kraven säger inte allt 104 När det inte finns krav 108 Identifiera vad som ska testas 109 Prioritera tester 116 Testanalys 118 Testdesign 119

8 Genomföra test 123 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8

Testa utan system 123 Testbarhet 124 Hitta stora fel först 128 Testa en del i taget 130 Testa hela flöden 131 Fastna inte i detaljer 132 Undvik distraktioner 132 Utforska konstigheter 133

9 Testfall och andra hjälpmedel för manuella tester 135 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 9.10

Testfall 135 Testdata i testfallet 138 Syftet styr formuleringen 142 Struktur på testfall 145 Detaljeringsnivån på testfall 148 Testprotokoll 151 Testlogg 153 Utforskande testning respektive skripttestning 154 När man inte hinner skriva testfall 154 Testprotokoll först – testfall sedan 155

Innehåll

10 Testmiljöer 157 10.1 10.2 10.3 10.4 10.5 10.6 10.7 10.8

Vad är en testmiljö? 157 Olika syften med testmiljöer 158 Vad styr behovet av testmiljöer? 159 Utmaningar 161 Kontroll av testmiljön 162 Systemberoende 162 Samordnade testmiljöer 164 Inkompletta testmiljöer 165

11 Testdata 167 11.1 11.2 11.3 11.4 11.5 11.6 11.7

Grunddata 167 Vad är testdata? 168 Typer av testdata 168 Syften med testdata 171 Skapa testdata 172 Utmaningar 175 Samordnad testdata 179

12 Felhantering 183 12.1 12.2 12.3 12.4 12.5 12.6 12.7 12.8 12.9

Fel är värdefulla 183 Fels allvarlighetsgrad 183 Felanalys 185 Felsökning 186 Felrapporter 192 Ärendehantering 195 Rätta fel och information 200 Hantera fel 200 Förebygga fel 202

Innehåll

13 Automatiserade tester 203 13.1 13.2 13.3 13.4

Varför automatisera? 203 Vad är värt att automatisera? 204 Värt att tänka på vid automatisering 205 Olika typer av automatisering 206

14 Yrket testare 213 14.1 14.2 14.3 14.4

Varför testare? 213 Vad behöver en testare kunna? 215 Behövs testare? 216 Framtiden inom test 217

Litteraturförteckning 221 Ordlista 225 Register 227

FÖRORD

För en tid sedan var jag inbjuden till Jönköpings Tekniska Högskola för att hålla en gästföreläsning om test i praktiken. I samband med det funderade jag på vilken litteratur inom området jag skulle rekommendera. Jag insåg att en bok med det innehåll jag ville förmedla inte fanns. Tanken väcktes då på att skriva en bok med fokus på de frågeställningar man möter när man arbetar med mjukvarutestning i praktiken. Jag är civilingenjör i datateknik och har alltsedan min examen 1991 från Chalmers Tekniska Högskola arbetat med systemutveckling och test av olika typer av produkter, som exempelvis styrsystem för ubåtar, träningssimulatorer för militären, operatörspaneler till autoklaver, e-handelssajter och system för att handlägga EU:s jordbrukarstöd. Sedan 1994 har jag undervisat yrkesverksamma i bland annat test och granskning. När jag arbetade på konsultbolaget Combitech tog vi fram den första svenska certifieringsutbildningen för testare, ISTQB grundnivå. Jag har dessutom arbetat med metodutveckling och verksamhetsutveckling inom systemutveckling och test. Tidigare har jag varit teststrateg på Jordbruksverket och jag arbetar numera som konsult inom test och kvalitetssäkring på Sogeti i Jönköping. Den här boken har sin bas i den praktiska erfarenhet jag byggt upp under åren. Där så krävs för att öka förståelsen har teori inkluderats, men fokus ligger på hur man arbetar med test i praktiken. Boken fokuserar på hur man bör tänka och agera för att genomföra effektiva tester. Behovet av kompetenta testare ökar och det är därför viktigt att det finns en bok som ger en rättvisande bild av vad yrket innebär. Boken innehåller exempel på olika typer av system, men fokus ligger på IT-system. Vidare tar boken upp hur man arbetar med test i stora, komplexa IT-system med många beroenden. © F ö rfattar e n oc h S tud e ntlitt e ratur

Förord

Boken vänder sig framför allt till studenter. Syftet är att förmedla en bild av vad mjukvarutest innebär samt förbereda dem för frågeställningar de kommer att möta i yrkeslivet. Boken vänder sig dessutom till yrkesverksamma som vill förkovra sig inom testområdet. Det kan vara testare, men även andra som arbetar med systemutveckling, exempelvis projektledare, kravanalytiker och utvecklare. En viss förståelse för systemutveckling krävs för att tillgodogöra sig innehållet. Systemen som används i exemplen är förenklade för att underlätta förståelsen. De är inte identiska med verkliga system, även om deras funktion är lika. Det jag vill förmedla är tankesätt för effektiv testning, samt de verktyg som krävs. Det finns aldrig ett enda sätt att göra något och det praktiska arbetet måste därför anpassas till rådande förutsättningar. Det går inte att erbjuda en universallösning som alltid fungerar. Det krävs i stället att man i varje enskild situation beaktar de förutsättningar som gäller och baserat på dessa arbetar fram ett bästa sätt att testa. Eftersom testområdet är stort är det omöjligt att täcka in allt. Fokus är därför på det som har en generell tillämpning.

KAPITEL 1

Mjukvarutest i praktiken

1.1

Vad innebär test?

Testning innebär alla de aktiviteter som genomförs för att ta reda på hur väl ett system uppfyller användares och andra intressenters behov. Testning kan betraktas som ett detektivarbete. Det ger information om hur systemet fungerar och minskar riskerna för att systemet inte gör det som förväntas, vilket i sin tur minskar affärs- och personsäkerhetsrisker. System

Ett system är ett IT-stöd som tjänar ett visst syfte för en viss verksamhet inom en organisation. Verksamheten är med andra ord de som behöver systemet. Verksamheten kan vara intern, dvs. tillhöra samma organisation som de som utvecklar systemet, eller extern, dvs. tillhöra en annan organisation. De som använder systemet kallas för användare. Intressenterna är berörda parter, t.ex. kunder, användare, organisationen som förvaltar systemet och de som bestämmer reglerna för verksamheten. Systemet kan använda tjänster från andra system och erbjuda tjänster som andra system kan använda. Det består av infrastruktur och mjukvara. För IT-system, dvs. ett informationssystem, består infrastrukturen av exempelvis servrar, nätverk och databas. För inbyggda system består den däremot av specialbyggd hårdvara. Exempel på system är mobiltelefon, e-tjänst för att deklarera skatt, bokföringssystem och handläggningssystem.

1 Mjukvarutest i praktiken

Testning består av två delar som båda har samma mål, men vars syfte är att hitta olika typer av fel:

–– Dynamisk testning. Vid ett dynamiskt test exekveras systemet, dvs. systemet körs. Testaren använder systemet och hittar fel.

–– Statisk testning. Vid ett statiskt test exekveras inte systemet. Det finns två typer av statisk testning; granskning och statisk analys.

––Granskning innebär att manuellt leta efter fel. Det kan inkludera

analys och beräkningar för att kontrollera att något är rätt. Granskningar kan genomföras på olika sätt. ––Statisk analys. Verktyg analyserar kod, modeller eller dokument för att hitta fel eller troliga fel. I en kompilator ingår en enkel form av statisk analys för kod, men det finns många verktyg som erbjuder mer omfattande statisk analys.

Kod

Instruktioner till dator, skrivna i ett programspråk. Kod (eller källkod) skrivs i programspråk för att den ska vara begriplig för människor, förutsatt att de har de förkunskaper som behövs. Kod brukar också innehålla kommentarer från utvecklaren, avsedd för andra utvecklare som senare ska ändra eller utöka koden. Men eftersom datorns processor inte kan bearbeta kod som den är måste den innan den exekveras omvandlas till en form som processorn kan bearbeta, dvs. den måste kompileras. (Computer Sweden)

Drifta

Sköta driften av något. När det gäller IT-system skiljer man vanligtvis mellan att använda systemet och att drifta systemet. Att använda systemet är att mata in, bearbeta, söka efter och publicera data. Att drifta systemet är att se till att maskinvara, nätverk och program fungerar så att de kan användas. (Computer Sweden)

1 Mjukvarutest i praktiken

Torbjörn Ryber erbjuder i (Ryber 2006) ett alternativt sätt att beskriva vad test är, nämligen att test innebär att ställa frågor till det som testas. Svaren jämförs därefter med vad som förväntas hända, dvs. ett facit. Det innebär att man måste kunna: • • • •

ställa frågor veta vilka frågor som ska ställas tolka svaren jämföra svaren med facit.

Krav

Formulerade krav

Ej formulerade krav

Okända krav

Underförstådda krav

Figur 1.1 Vad är test?

Det finns en skillnad i tankesätt mellan att testa och att utveckla ett system. När man utvecklar mjukvaran måste man kunna tolka kraven för att sedan ge svar i form av den kod som utvecklas. Vid testning måste man ifrågasätta och ställa frågor för att ta reda på hur systemet fungerar i praktiken. Verifiering och validering är två aspekter av testning. Båda är lika viktiga, men syftar till att identifiera olika problem. När ett nytt system ska tas fram eller ett befintligt ändras så görs det för att verksamheten har vissa behov. Dessa behov formuleras som krav. När systemet jämförs mot ställda krav är det fråga om en verifiering. Verifieringen upptäcker om systemet inte fungerar som avsett, dvs. om kraven inte uppfylls. När systemet däremot jämförs mot verksamhetens behov handlar det om validering. Valideringen upptäcker således om systemet inte uppfyller verksamhetens behov, om det inte fungerar i praktiken eller om man har tänkt fel då kraven formulerats. En validering genomförs lämpligen av den verksamhet i vilken systemet ska användas. Representanter för verksam© F ö rfattar e n oc h S tud e ntlitt e ratur

1 Mjukvarutest i praktiken

Kvalitet

Kvalitet kan bland annat definieras på följande sätt: Kvalitet är till vilken grad en komponent, ett system eller en process uppfyller ställda krav och/eller användares/kunds behov och förväntningar. (ISTQB Ordlista s 26) Notera att definitionen inte begränsas till att enbart uppfylla ställda krav. Det viktiga är att uppfylla kundernas behov och förväntningar, oavsett om de uttryckligen formulerats som krav eller inte. Begreppet krav behandlas i nästa faktaruta. Det går inte att mäta kvalitet på samma sätt som man exempelvis mäter temperatur. Skälet är att det inte finns några enskilda mått på kvalitet som i sig inte beror på flera faktorer. Man kan därför bara att få en indikation på systemets kvalitet. Ett mått som ofta används är antalet fel. Hur många fel som hittas i samband med testningen beror även i hög grad på vad som har testats samt hur omfattande och bra testerna varit. Man bör därför vara försiktig med att dra några slutsatser kring kvaliteten baserat på antalet fel. Om man exempelvis identifierar få fel i samband med test ligger det nära till hands att tro att kvaliteten på såväl tester som systemet är hög, se figur 1.2.

Kvalitet system

Kvalitet test

Figur 1.2 Koppling mellan antal fel och kvalitet

1 Mjukvarutest i praktiken

Kvalitet system

Kvalitet test

Figur 1.3 Koppling mellan antal fel och kvalitet

Det är däremot fullt möjligt att det förhåller sig som i figur 1.3. Systemets kvalitet är låg, men eftersom testerna är för få och för dåliga upptäcks få fel. När antalet fel diskuteras i relation till systemets kvalitet bör man därför beakta antalet tester, kvaliteten på dessa och vad som testats respektive inte testats. Om detta inte görs finns en risk att man drar fel slutsatser baserat på det antal fel man hittar. Testernas kvalitet kan naturligtvis inte heller mätas, men man kan göra en subjektiv bedömning baserad på tidigare erfarenheter. Frågor som rör kvalitet har en tendens att prioriteras ner om och när det blir ont om tid. Det finns dock en gräns för hur mycket man kan pruta på kvaliteten. Det är illa nog om användarna upplever att det är krångligt att använda systemet, men än värre om systemet inte kan användas över huvud taget. Man måste också beakta risken att systemets information förstörs på grund av allvarliga fel. För vissa typer av fel kan det vara svårt att återställa informationen. Det spelar därför ingen roll hur många funktioner som finns i systemet – om det inte kan startas eller om det kraschar med jämna mellanrum saknar det likväl ett värde för användarna. Följaktligen är det viktigt att kontinuerligt föra en diskussion där man väger fördelarna av att kunna leverera i tid mot eventuella nackdelar som kan bli resultatet av att genomföra färre tester. Diskussionerna bör vidare inkludera vilka tester som inte genomförts, vilka fel som inte hittats samt eventuella risker kopplade till driftsättningen.

1 Mjukvarutest i praktiken

Krav

Begreppet krav kan definieras på flera sätt, till exempel: Ett krav är en önskvärd egenskap eller funktion hos ett IT-system (Karlsson 1998 s. 11). Notera att krav här ses som något mer än det som specificeras i kravställningen. Definitionen täcker även andra intressenters krav, samt de underförstådda krav som inte har formulerats explicit. Det är viktigt att föra en dialog kring såväl formulerade som icke-formulerade krav för att identifiera dolda behov. Att vissa krav inte formuleras explicit beror ofta på att de endera är underförstådda eller okända. De underförstådda kraven är så självklara att ingen tänker på att ge uttryck för dem. Dessutom är det framför allt verksamhetskraven, dvs. kraven som verksamheten ställer, som formuleras. För att systemet ska fungera för verksamheten måste också IT-krav vara uppfyllda, exempelvis krav som gör det möjligt att underhålla, felsöka, drifta och testa systemet.

Krav

Formulerade krav

Ej formulerade krav

Okända krav

Underförstådda krav

Figur 1.4 Olika typer av krav

Krav är antingen funktionella, dvs. avser någonting som systemet ska utföra, eller icke-funktionella, dvs. avser någon egenskap som systemet ska ha. Ett krav kan ses som en beställning, ett kontrakt, mellan beställare, dvs. den som i verksamheten ansvarar för att beställa systemet, och leverantör, dvs. den som ansvarar för att leverera systemet. När det förekommer ett nära samarbete mellan leverantör och verksamhet betraktas kraven ofta mindre strikt.

1 Mjukvarutest i praktiken

heten bör därför vara involverade i testerna för att få en så tidig validering som möjligt. Såväl verifiering som validering bör genomföras kontinuerligt under systemets utveckling. 1.2

Varför testa?

De flesta människor är beroende av IT-system för att kunna utföra sitt arbete. Systemen är integrerade och innehåller mycket funktionalitet. Information som tidigare fördes manuellt från ett system till ett annat, skickas nu automatiskt. Om något inte fungerar innebär det ofta stora kostnader och i värsta fall risk för personskador. Betydelsen av testning ökar därför. Ett system är ofta mycket komplext. Alltför många individer är involverade i utvecklingsarbetet för att det ska vara möjligt att, i alla led, ”göra rätt från början”. Man måste därför beakta och genomföra tester under hela processen. Dessutom måste man säkerställa att testerna genomförs på ett effektivt sätt, dvs. att man testar rätt sak vid rätt tillfälle för att uppnå rätt kvalitet. Även om det finns stor erfarenhet av att genomföra effektiva tester inom branschen, så är varje situation är unik. Därför måste erfarenheterna användas på bästa sätt, och man måste kunna anpassa sig till den aktuella situationen. Det innebär att testning är en kreativ aktivitet som påverkar alla som arbetar med systemutveckling. Olika test kan ha olika syften. Nedan följer några exempel:

–– Mäta kvaliteten. Det finns inget sätt att direkt mäta kvaliteten, men genom bra tester kan man få en indikation på systemets kvalitet.

–– Förbättra kvaliteten. Tester i sig kan inte förbättra kvaliteten, men

––

resultatet av testerna kan stödja kvalitetshöjande åtgärder av systemet genom att identifiera fel och förbättringsmöjligheter. Kvaliteten förbättras dock inte förrän felen har åtgärdats. Hitta fel. Ibland kan det vara viktigare att ha kännedom om vilka fel som finns än att faktiskt åtgärda dem. När en driftsättning närmar sig förändras ofta arbetets fokus, från att förbättra kvaliteten till att identifiera så många av de återstående felen som möjligt. Hitta förbättringsmöjligheter. Med utgångspunkt i de fel som hittas i test, kan man få idéer om hur arbetssättet kan förbättras.

1 Mjukvarutest i praktiken

–– Förebygga fel. I samband med att man identifierar fel, får man

––

kunskap om vad som är rätt respektive fel. Dessutom ökar förståelsen för verksamheten och dess behov. Det medför – i bästa fall – att färre fel görs fortsättningsvis. När man får kännedom om vilken typ av fel som görs, kan åtgärder som exempelvis utbildning sättas in. På det sättet bidrar testerna till att förebygga fel. Skapa förtroende hos användare och andra intressenter. Ett lågt förtroende från användare och övriga intressenter kan innebära att man måste göra extra kontroller och arbeta mer med support. Detta är förstås förenat med extra kostnader. Genom att synliggöra hur man arbetar för att öka systemets kvalitet kan förtroende skapas. Uppfylla krav. Standarder, lagar och kunder ställer krav på systemets funktion och utformning. Dessutom ställs ofta krav på hur testerna ska bedrivas. I vissa fall måste standard- och lagkrav uppfyllas innan systemet får användas eller säljas. Det är således viktigt att inte bara genomföra testerna på ett korrekt sätt, man måste också kunna visa att kraven uppfylls.

Ofta vill man uppnå flera syften med testerna, vilket syfte som är viktigast kan variera över tid. I teorin genomförs tester i syfte att öka kvaliteten. Detta abstrakta koncept är dock inte skäl nog för att företag och myndigheter ska avsätta pengar för tester. Det måste därför finnas något att vinna på att genomföra testerna, något som motiverar den extra kostnaden. Om man inte i förlängningen hade tjänat pengar på att genomföra tester skulle inga organisationer ha prioriterat detta arbete. Kostnaden för test kan därför betraktas som en investering. Den investering som görs för test återbetalar sig i form av uteblivna kostnader, t.ex. minskad hantering av fel och extra driftsättningar. Investeringen kan också bidra till vinster som annars hade uteblivit, t.ex. om kunden returnerat systemet och vägrat betala, om systemet inte tillåtits att användas eller säljas, alternativt om nya kunder valt konkurrentens system i stället. Organisationer investerar i tester eftersom det bidrar till att de sparar såväl tid som pengar, samt att de kan fortsätta att sälja sina system.

1 Mjukvarutest i praktiken

1.3

Varför är test av mjukvara svårt?

Att testa mjukvara är svårt, eftersom mjukvaran inte är en fysisk produkt utan en abstrakt tankekonstruktion. I takt med att systemens komplexitet ökar blir även testningen av mjukvara mer komplex. Eftersom man inte kan ”ta på” mjukvaran är den svår att både utveckla och testa. Att mjukvaran är abstrakt gör också att den kan uppfattas som lätt att ändra, vilket kan leda till slarv och brister i planering. Det kan också vara svårt att bedöma när mjukvaran är färdigutvecklad och -testad.

FR ÅGOR TILL L ÄSAREN

–– Vad är testning? –– Testning består av två delar som båda har samma mål. Vilka? Vad innebär de? –– Vad är skillnaden mellan verifiering och validering? –– Varför väljer organisationer att testa sina system? –– Vilka olika syften kan ett specifikt test ha?

Eva Holmquist är civilingenjör och specialist inom mjukvarutest. Hon har arbetat med alla faser från planering till genomförande av tester, samt verksamhetsutveckling och utbildning inom testområdet. Under hennes tid på konsultbolaget Combitech tog hon och hennes kollegor fram den första svenska certifieringsutbildningen för testare, ISTQB grundnivå. Hon har varit teststrateg på Jordbruksverket och numera arbetar hon som testspecialist på Sogeti.

PRAKTISK MJUKVARUTESTNING Med ökande komplexitet och funktionsinnehåll i mjukvarusystem växer behovet av kunniga testare samtidigt som övriga roller behöver en större förståelse för test och hur det påverkar utvecklingen. Praktisk mjukvarutestning fokuserar på de frågeställningar man möter vid mjukvarutestning i praktiken och innehåller många exempel från olika typer av system. Fokus ligger på IT-system, bland annat behandlas arbete med test i stora, komplexa IT-system med många beroenden. I Praktisk mjukvarutestning behandlas ämnen som sammanhangets påverkan på test, testledning, att genomföra tester, testmiljöer, testdata, automatiserade tester. I boken ges också många tips och konkreta exempel på vad det innebär att vara testare. Boken vänder sig till studenter på universitet och högskola men också till redan yrkesverksamma som vill förkovra sig inom testområdet. Det kan vara testare, men även andra som arbetar med systemutveckling, exempelvis projektledare, kravanalytiker och utvecklare.

Art.nr 39512

studentlitteratur.se