Introduktion TILL TEST

Innehåll

• Allmänt om test

• Definitioner

• Test principer

• Myter om test

• Test process

2

Standards

3

ISTQB

SSTB

ISOIEEE

RUP

Agile

TDD

V

FDD

Varför är test nödvändigt?!

4

Programvarusystem är en integrerad del av livet, från verksamhetstillämpningar (t.ex. bankverksamhet) till konsumentprodukter (t.ex. bilar).

De flesta har upplevt att programvaran inte fungerar som man förväntat sig.

Programvara som inte fungerar korrekt kan leda till mångaproblem, t.ex. förlust av pengar, tid eller affärsmässigt rykte

och kan till och med orsaka skada eller dödsfall.

Tänk om bilar var som applikationer

5

Man beställer…. Release 0.1 Release 0.2

Release 0.3 Release 1.0

Orsak till fel

6

Kod exekveras

Orsakar

(1)Misstag

(2)Defekt/Bug

(3)Felsymptom

• Fel uppstår därför att människor gör misstag på grund av:tidspress, komplex kod, komplexitet i infrastrukturen, förändradteknologi och/eller att många system interagerar.

• Felsymptom kan även orsakas av miljömässiga förhållanden t.ex:strålning, magnetism, elektriska fält eller föroreningar.

• De kan orsaka fel i inbyggda program eller påverka exekveringen avprogram genom att förändra hårdvarans förutsättningar.

Testningens roll

Testning av system och dokumentation kan hjälpa till attreducera risken for att problem uppstar under drift

men ocksa bidra till programvarusystemets kvalitet om fel rättasinnan systemet frisläpps for användning i drift.

Det kan ocksa krävas test av programvarafor att uppna kontraktsmassiga eller

legala krav eller for att uppfylla industrispecifika standarder.

7

Test & Kvalité

• Med hjälp av test är det mojligt att mäta kvaliteten pa programvaran i termer av hittade fel for bade funktionella och icke-funktionella programvarukrav.

• Kvalitetssäkring förebygger fel

• Test visar om kvalitetssäkringen varit effektiv

• Erfarenheter fran tidigare projekt bor tas tillvara. Genom att forsta de grundorsakerna till de hittade felen i andra projekt kan processerna forbättrasvilket i sin tur bor forhindra att dessa fel dyker upp igen och, som en konsekvens, forbättra kvaliteten hos framtida system.

• Test bor vara en del av de kvalitetssäkrande aktiviteterna, tillsammans med utvecklingsstandarder, utbildning och felanalys.

8

‟Software Engineering – Software Product Quality‟ (ISO 9126)

Kvalité – hur?

9

1. Gå igenom det du har, behåll bara det du behöver2. En plats för allt och allt är på sin plats3. Synliggör problem som kan orsaka kvalitetsbrister4. Metoder för att upprätthålla och övervaka steg 1-35. Ordning, en löpande process av ständig förbättring

Referens: ”The Toyota way”

Kostnaden för incidenter i produktion• Studier [1] har visat att det introduceras 60 fel (defekter) per tusen rader kod från och med kravfasen i

projektets start till och med implementationsfasen.

• Enligt beräkningar [2] är kostnaden för att rätta till en defekt i produktion 30 gånger så hög som för att göra motsvarande ändring i krav- eller designfasen

• Studier [3] har visat att en bug som upptäcks i produktion i snitt tar 17 timmar att åtgärda.I denna tid inkluderas: Analys av defekten, Kodrättning, Regressionstest, Uppdatering av dokumentation, Förberedelse för release till produktion, Information till berörda parter om produktionssättningen, Produktionssättningen, där ett antal personer blir berörda

10

[1] IBM

[2] Forrester 2009

[3] Eriksson, U., Test och kvalitetssäkring av IT-system, Studentlitteratur 2008

Vad är test?

11

Q: Är det bara att exekvera testfall, exekvera programvaran?. A: En del av testningen, men fler aktiviteter ingår också.

Test innefattar aktiviteter, såsom:

planering och styrning

val av testvillkor

design och exekvering av testfall

kontroll av resultat

utvärdering av avslutskriterier

rapportering om testprocessen och systemet som testas

avslutning eller stängning

granskning av dokument (även källkod)

Myter om Test

• Vi gor val lite tester i slutet….eller

• Test ar det man gor sist av allt….

• Test handlar bara om att hitta fel.

• Test är dyrt!

12

Tänk test tidigt!

Test kan innebära möjligheter

Att testa kostar – att inte testa kostar MER.

Grundläggande testprinciper

13

1 – Test visar att det finns fel

2 – Uttömmande testning är omöjlig

4 – Ansamlingar av fel

6 – Test beror på sammanhang

7 – Frånvaro-av-fel-fallgropen

3 – Tidig testning

5 – Immunitets- paradoxen

Testprocess

14

Testplanering Testanalys Testdesign TestexekveringUtvärdera/Rapportera

Testavslut

Utvecklingsmetoder

15

V-modellen (sekventiell utvecklingsmodell)

• Komponent- (enhets-) testning

• Integrationstestning

• Systemtestning

• Acceptanstestning

Iterativ-inkrementell utvecklingsmodell

Process, med upprättande av krav, konstruktion, byggande och testning av ett system, som sker imånga små utvecklingssteg. Ex:

• Prototyp

• Rapid application development, RAD)

• Rationals utvecklingsprocess (RUP)

Agila utvecklingsmodellGrundtankarna bakom agile bygger på att göra kunden/användaren nöjd med det som utvecklas genom ett mycket nära samarbete under hela utvecklingstiden med täta och regelbundna möten mellan utvecklare ochbeställare/mottagare.E x:

• Scrum

• XP (eXtreme Programming)

• FDD(Feature Driven Development)

MEN....

Oavsett metod så skall ALLA nivåer av test planeras, följas, exekveras, utvärderas

16

Testnivå 1: Komponenttest /Unit test • Testobjekt: Komponenter, program, datakonverterings-/migreringsprogram, databasmoduler.

• Testbas: Komponentkrav, detaljerad design, kod.

• Utvecklarens ansvar

• Automatiserade tester

• Test på minsta möjliga komponent

• Testa sa oberoende av ”omvarlden som mojligt”

• Test driven utveckling

• Kod granskning

• Statiska och dynamiska tester

• Test sker i utvecklingsmiljön

17

Testnivå 2: Integrationstest

• Testobjekt: Delsystem, databasimplementation, infrastruktur, systemkonfiguration, gränssnittoch konfigurationsdata.Testbas: Programvaru- och systemdesign, arkitektur, arbetsfloden, anva ndningsfall.

• Integrationstestning testar granssnitt mellan komponenter, samspelet mellan olika delar i ettsystem, t.ex. operativsystem, filsystem, maskinvaraeller gränssnittet mellan system.

• Test av icke-funktionella egenskaper (t.ex. prestanda) kan inkluderas Iintegrationstestningen.

• Vid varje integrationssteg skall testarna koncentrera sig enbart pa sjalva integrationen dvs. granssnitten. Vid till exempel integration av modul A med modul B skall de fokusera pa kommunika- tionen mellan modulerna och inte funktionaliteten i de individuella modulerna, somgjordes i komponenttest.

18

Testnivå 3: Systemtest

• Testobjekt: Systemet, manualer, systemkonfiguration och konfigurationsdata.

• Testbas: Kravspecifikation for system och programvara, funktionsspecifikation, riskanalys.

• Systemtestning täcker hela systemets/produktens beteende. Testningens omfattning skall varatydligt beskriven i den overgripande testplanen (master test plan) eller i testplanen for aktuellniva .

• Testmiljon skall, for systemtest, efterlikna den slutliga mal- eller produktionsmiljon sa mycketsom mojligt for att minimera risken for att fel kopplade till miljon inte hittas under testningen.

• Systemtest kan omfatta testning baserat pa risker och/eller kravspecifikationer, verksamhetsprocesser eller användningsfall.

• Systemtest kan undersoka funktionella och icke-funktionella krav pa systemet samtdatakvalitetsegenskaper.

• Systemtestning av funktionella krav startar med att använda mest lämpligaspecifikationsbaserade (black-box) tekniker for att testa den funktionella aspekten pa systemet. En beslutstabell kan till exempel skapas, innehallande kombinationer av effekter som beskrivs iverksamhetsreglerna.

• Strukturbaserade tekniker (white-box) kan sedan användas for att utvärdera grundligheten itestningen med avseende pa ett strukturellt element som t.ex. strukturen hos en meny ellernavigeringen av en websida

19

Testnivå 4: Acceptanstest

• Testobjekt: Affärsprocesser for helt integrerade system, drift- ochunderhallsprocesser, användarforfaranden, formulär, rapporter, konfigurationer och konfigurationsdata.

• Testbas: Användarkrav, systemkrav, användningsfall, affärsprocesser, riskanalys.

• Oftast är det kunderna eller andvändarna som har ansvar foracceptanstestning, men även andra intressenter kan vara inblandade.

• Malet for acceptanstestning är att skapa en tilltro till systemet, till delar av det, eller till specifika icke- funktionella egenskaper av systemet.

• Att hitta fel är inte det viktigaste malet i acceptanstestning. Acceptanstestning kan utvärdera systemets status infor driftsättningoch användning.

20

Testtyper

1. Test av en funktion hos programvaran

2. Test av en icke-funktionell kvalitetsegenskap som prestandaeller användbarhet

3. Struktur eller arkitektur hos komponent, programvara eller system.

4. Test kopplad till andringar, dvs. bekräfta att ett fel har atgärdats(omtestning) och visar om oavsiktliga forändringar har uppstatt(regressionstestning).

21

Funktionell testning

• De funktioner som ett system, delsystem eller komponent skall utfora kanbeskrivas i arbetsprodukter sasom kravspecifikation, användningsfall, enfunktionsspecifikation, eller de kan vara odokumenterade. Funktioner visar”vad” systemet gor.

• Funktionella tester är baserade pa funktioner och finesser (beskrivna idokument eller forstadda av testarna) och kan utforas pa alla testnivaer (t.ex. kan testning av komponenter vara baserade pa en komponentspecifikation)

• Specifikationsbaserade tekniker kan användas for att ta fram testvillkor ochtestfall for programvarans eller systemets funktionalitet. Testning avfunktionalitet behandlar det externa beteendet hos programvaran(black-box testing).

22

Icke-funktionell testning• Icke-funktionell testning inkluderar, men är inte begränsat till testning av

prestanda, last, användbarhet, underhallbarhet, tillforlitlighet ochportabilitet. Det kan ses som testning av ”hur” systemet fungerar.

• Icke-funktionell testning kan forekomma pa alla testnivaer. Termen icke-funktionell testning beskriver de tester som krävs for att mäta egenskapernahos ett system eller en programvara och som kan kvantifieras pa en varierande skala, t.ex. svarstider vid prestandatestning.

23

Software Engineering – Software Product Quality‟ (ISO 9126)

FURPS+

24

Omtest och regressionstestning

Vad är skillnaden mellan regressionstest och omtest?

• Regressionstestinnebär att man testar orörd kod som kan ha påverkats av ändrad kod. Koden är testad tidigare.

• Omtestinnebär att man testar ändring av kod. Kan ha ändrats p g a bugg i systemet..

25

Del 3 : Statisk testning

Till skillnad mot dynamisk testning, som kräver att programvaran exekveras, sa forlitarsig statiska testtekniker pa manuell kontroll (granskning) och automatiserad analys(statisk analys) av källkoden eller andra producerade dokument utan att programvaranexekveras.

• Granskningar är ett sätt att testa arbetsprodukter (inklusive koden) och kan med fordelutforas fore dynamisk testning. Defekter som upptäcks genom granskningar i ett tidigtskede (t ex granskningar av krav) är oftast mycket billigare att rätta än de defekter somhittas när man utfor dynamisk testning av redan utvecklad kod.

• Granskningar, statisk analys och dynamisk testning har samma overgripande mal –pavisa fel.

• Typiska defekter som är lättare att hitta med granskningar än med dynamisk testninginnefattar: avvikelser fran standard, kravdefekter, designdefekter, otillräckligunderhallbarhet och felaktigt specificerade gränssnitt.

26

Granskningstyper

27

Informell granskning -ingen formell process; -kan ske genom parprogrammering eller att en teknisk ledare leder design- och kod-granskningen-frivilligt dokumenterad--nyttan av granskningen kan variera beroende på granskaren

Genomgång - mötet leds av författaren-kan ske med hjälp av scenarion, grupp med kolleger-ej tidsbegränsade sammanträden-granskarna är förberedda, granskningsrapport skrivs, avvikelselista tas fram och sekreterare utses-kan variera i utförande från ganska informellt till mycket formellt;

Inspektion -leds av en utbildad moderator-vanligtvis genomförd av jämlika kolleger-definierade roller-inkluderar mätetal-formell process som är baserad på regler och checklistor-definierade start- och avslutskriterier för att acceptera programvaran Förberedelser innan mötet:-inspektionsrapport, lista över iakttagelser; -formell uppföljningsprocess(valfritt med processförbättringsprocess)

Teknisk granskning

-dokumenterad, definierad defektutpekningsprocess som inkluderar kolleger och tekniska experter, ledningens deltagande är valfritt; -kan utföras som en granskning med kolleger utan ledarens/chefens deltagande; -önskvärt att granskningen leds av en utbildad moderator

Förberedelse innan mötet:-valfritt användande av checklistor-granskningsrapport som inkluderar defektlista, beslut om programvaran lever upp till kraven -där det är möjligt, rekommenderade åtgärder för defekterna

Testdesign

28

Testdesign 1(3)

29

Parameter= månadGiltiga värden=1-12Ogiltiga värden=0, -1 & 13-n

Nummer mellan 1 - 10001) Testfall med test data exakt mellan 1-10002) Test data med värden under gränser: 0 och 999.3) Test data med värden just över gränser: 2 och 1001.

Gränsvärdeanalys används som en del av stress och negativ testing

(1) Ekvivalensklassindelning (2) Gränsvärdesanalys

(3) Beslutstabeller

”Uttag är mojligt om kunden onskar ta ut ett belopp som inte overskrider kontots saldo. Om kunden önskar göra ett uttag som överskrider saldot är uttag endast mojligt om kunden har en beviljad kredit.”.

Tabellens övre halva innehåller olika villkor som ska testas. Den nedre halvan beskriver de olika händelser som sker baserat på valen i den övre halvan.

Av tabellen framgår att det finns fyra möjliga scenarion som behöver testas. Genom att göra ett test per kolumn, kommer alla kombinationer av utlösande villkor att testas.

(4)Tillståndsbaserad testningEtt system kan visa olika svar eller resultat beroende på vilka villkor och vilket tidigare händelseförlopp (dess olika tillstånd) som skett.I dessa fall kan systemet visas som ett tillståndsdiagram. Det tillåter testare att

se programmet eller systemet i termer av tillstånd, övergångar mellan tillstånden, invärden eller händelser som gör att tillstånden ändras, dvs. en tillståndsövergång sker och de händelser som sker som resultat av dessa tillståndsövergångar.

Tillstånden i systemet eller objektet som testas är separerade, identifierade och är av ändligt antal. En tillståndstabell visar förhållandet mellan tillstånd, indata och kan synliggöra övergångar som är ogiltiga.

Testdesign 2(3)

(5) Användningsfallsbaserad testning

Tester kan härledas från användningsfall. Ett användningsfall beskriver interaktionen mellan aktörer, användare eller system, vilket producerar ett resultat av värde för en systemanvändare eller en kund.

Användningsfall kan beskrivas på en abstrakt nivå (teknikoberoende affärsflöden på affärsprocessnivå), eller på systemnivå (systemanvändningsfall på funktionalitetsnivå).

• Varje användningsfall har förvillkor som måste vara uppfyllda för att användningsfallet skall fungera.

• Varje användningsfall avslutas med ett antal slutvillkor, vilka utgörs av observerbara resultat och systemets sluttillstånd när användningsfallet genomförts.

• Det krävs också att systemet har ett avsett sluttillstånd när användarscenariot är avslutat.

• Ett användningsfall har ett huvudflöde, dvs. det mest troliga scenariot, men kan även ha alternativascenarion.

30

Testdesign 3(3)

31

(6)Erfarenhetsbaserad testning•Tester skapas baserat på testarens skicklighet och intuition och hans/hennes erfarenhet av liknande applikationer och teknologier. Som komplement till mer systematiska testtekniker, kan dessa tekniker vara mycket värdefulla genom att testfall identifieras, vilka annars inte skulle hittas via de mer formella teknikerna. Dock varierar effektiviteten hos denna typ av testning med erfarenheten hos testaren.

•En vanligt förekommande erfarenhetsbaserad teknik är felgissning, i vilken testare förutspår potentiella defekter utifrån sin tidigare erfarenhet.

•Ett strukturerat sätt att arbeta med felgissning är att göra en lista av möjliga defekter och därefter skriva tester som blottar dessa defekter. Detta systematiska angreppssätt kallas för felattack. MEN det räcker inte att ”tänka kreativt” eller att ”försöka knäcka programmet” Erfarenhetsbaserad testning är vad det heter!

(James Bach) http://www.satisfice.com/articles/what_is_et.shtml

Testroller

32

Roll Utför Ansvarar för(dokument)

Testare •Exekverar tester •Defekt rapport

Testanalytiker •Utvecklar testfall•Planerar test exekvering•Verifierar ändringar

•Testfall•Testprotokoll

Testledare •Skapar testplan•Skapar Iterationtestplan•Skapar teststrategi•Administrerar test

•Defekt rapport•Testrapport•Testplan•Teststrategi•Status rapport

Mätetal & Mätning

33

En mängd mätetal (typ av mätning, sort, enhet) med associerade mätvärden(faktiska värden) bör användas under hela livscykeln för programvaruutvecklingför att hålla koll på olika aspekter av utvecklingen.

Exempel på mätetal är planerade aktiviteter, täckningsgrad,arbetsbelastning, osv. För många mätetal är det fördelaktigt att fastsälla en uppskattad utveckling

och sen jämföra den aktiska utvecklingen hos det aktuella mätetalet mot uppskattningen.

Förankra mätetalen innan testerna startar. Sätt upp en enkel dashboard

Utvärdera test/defekter med KPI

KPI (Key Performance Indicator)

• Mått för effektivitet hos en verksamhet. På svenska kallar man detta ofta nyckeltal för verksamheten. Vilka faktorer som mäts varierar från fall till fall, exempelvis:

• Kostnadsreduktion

• Maximal väntetid för en kund

• För att kunna identifiera nyckeltal måste man ha:

• en fördefinierad affärsprocess.

• tydliga mål / krav på affärsprocesser.

• kvantitativ / kvalitativ mätning av resultat och jämförelse med uppsatta mål.

• Undersöka skillnader och processer eller resurser för att uppnå kortsiktiga mål.

När man identifierar nyckeltal tillämpas ofta förkortningen S.M.A.R.T.

Nyckeltalen skall vara:

(Specific, Measurable, Achievable, Result-oriented or Relevant,

Time-bound)

34

Exempel

35

KPI Namn Beskrivning Mättal

Test: Pass/Fail/Block Uppgift om programvarans kvalitet (efter enhetstestning).

Antal genomförda tester som godkänts dividerat med totalt antal tester som har

genomförts.

Antal kända defekter i produktion

Mätning av den övergripande kvaliteten på systemet i produktion, i termer av antalet utestående defekter som accepteras med tillräckligt låg risk.

Totalt antal defekter (klassificeras efter svårighetsgrad) dividerat med antalet defekter

(klassificeras efter svårighetsgrad) i exit kriterier.

Verktyg

• Testmanagement: Quality Center, Test Manager (TFS), Rational TestManager, QuickTestPro, SilkCentral Test Manager, Fitnesse

• Prestanda: Load Runner

• Configuration Management: Rational ClearQuest, JIRA

• Krav: Rational Requirements Composer, DOORS, Enterprise Architect, ReQtest

• Process: ARIS

36

Men, de bästa testverktyg är….

37

Exempel på vanliga misstag vid test

38

39

(1) Test = KvalitéInte bara testarens uppgift!

(2) Teststatus• Testing går “bra" ,“ja vi har testat detta" “testing skall vara ‘klar' tills på tisdag" utan

givet sammanhang.

• Att rapportera teststatus kräver att man tar upp risker, täckning, arbetsinsats, och hur det relaterar till nuvarande version och potentialen för den framtida utveckling.

• Vi borde rapportera utifrån affärsnyttan.

Det är som när en man frågade stenhuggaren vad arbetar du med?

”Hugger sten” svarade en medan nasta svarade ”Jag hjalper till att bygga en katedral”!

40

(3) Testning är en färdighet

41

(4)Symptom/grundorsak

42

Behandla inte symptomen! Sök och hitta grundorsaken!

#1: Brist på systemtänkande#2: Översättnings/tolknings problem#3: Bristfällig process kunskap#4: Bristfällig teknologi kunskap

Standarder/Länkar/Litteratur

• [IEEE 829-1998] IEEE Std 829TM (1998) IEEE Standard for Software Test Documentation

• [IEEE 1028] IEEE Std 1028TM (2008) IEEE Standard for Software Reviews and Audits

• [IEEE 12207] IEEE 12207/ISO/IEC 12207-2008, Software life cycle processes

• [ISO 9126] ISO/IEC 9126-1:2001, Software Engineering – Software Product Quality

• ISTQB (www.istqb.com)

• SSTB (www.sstb.se)

• CMMI (http://www.sei.cmu.edu/cmmi/)

• TMMi (http://www.tmmifoundation.org/)

• Six Sigma (http://www.isixsigma.com/)

• [Hetzel, 1988] Hetzel, W. (1988) Complete Guide to Software Testing

• [Beizer, 1990] Beizer, B. (1990) Software Testing Techniques

• [Black, 2001] Black, R. (2001) Managing the Testing Process

• [Copeland, 2004] Copeland, L. (2004) A Practitioner‟s Guide to Software Test Design

• [Craig, 2002] Craig, Rick D. and Jaskiel, Stefan P. (2002) Systematic Software Testing

43

44