Agil Testprocess

Jag beskriver här en idé till en Agil Testprocess utifrån V-modellen.

Vad är en testprocess?

Enligt SSTB: [...] testprocess[en] innehåller planering, specificering, exekvering, loggning och avslut.

Vad är V-modellen

Enligt SSTB: V-modellen är ett ramverk som beskriver aktiviteterna inom programvaruutveckling. V-modellen beskriver ur ett testperspektiv hur testaktiviteter kan integreras i varje fas av livscykeln [...].

En översikt av V-modellen innehåller fyra nivåer:

• Kravspecifikationer (A) utgör basen för acceptanstester (H), till exempel FAT och SAT.
• Funktionsspecifikationer (B) utgör basen för systemtester (G).
• Designspecifikation (C) utgör basen för integrationstester (F).
• Komponentspecifikation/Utveckling (D) utgör basen för komponenttester (E).

Utöver fördelen att arbete med kravspecifikationer (A-D) och testspecifikationer (E-H) kan utföras samtidigt gör V-modellen ett par antaganden som typiskt kritiseras av förespråkare för agila metoder:

1. När kravspecifikationen (A) är klar kommer inga nya krav.
2. Utvecklingen sker efter kravspecifikationen.
3. Testning sker efter utveckling (eller i alla fall efter kravspecifikation).

Om man i in utveckling använder sig av Riskbaserad Testning kan det vara lämpligt att parallellt med specifikationerna (kanske A-C) samtidigt gör en risk-analys.

Agil Testprocess utifrån V-modellen

Testprocessen som presenteras här bygger på V-modellen med inslag av agil utveckling och agil testning. Speciellt används element från Boken Agile Testing av Crispin & Gregory som är ett referensverk inom den agila testsfären.

• Basen i modellen (A-H) följer V-modellen.
• Man kan betrakta A-C som en uppstartsfas, F-H som en avslutningsfas och i mitten D-E samt I-M som en agil utvecklingsfas (eller ibland iterativ/inkrementell utvecklingsfas).
• Utöver V-modellen används en agil metod för testning (I) under utvecklingsfasen. Denna testmetod baseras på begreppet Agila Testkvadranter och presenteras i detalj nedan. I kort går det ut på att sprida testningen och säkerställa att testning av olika typer utförs i varje iteration – inte bara komponenttester som annars är ett vanligt fel i agila projekt.
• Utifrån tester som utvecklas i varje iteration (I) byggs en serie tester upp i en svit för regressionstester (J). Regressionstestsviten körs minst en gång i varje iteration. I möjligaste mån automatiseras hela eller stora delar av den. Dessa körs med fördel ”ofta” (nattligen).
• Nya krav (K) kan komma att föreslås från kund, slutkund eller internt. Typiskt kan nya krav kräva stora förändringar i prioriteringar, programvaran eller till och med resurser. Det är därför viktigt att projektledning eller liknande, ofta kallad CCB - Change Control Board, (L) begränsar nya krav, eller i alla fall fattar strategiska beslut innan nya krav släpps in.
• De nya krav (M) som accepteras genom (L) kommer påverka alla testaktiviteter (E, F, G, H, I och J). Beroende på hur krav hanteras kan även krav- och designdokument komma att kräva ändringar. Detta måste tas i åtanke innan nya krav släpps in.

Den agila utvecklingsfasen

I varje iteration är det viktigt att få till testaktiviteter enligt principen om Agila Testkvadranter. De agila testkvadranterna delar upp testaktiviteter med hjälp av två axlar:

• Y-axeln beskriver om testaktiviteten är business-nära eller teknologi-nära.
• X-axeln beskriver om testaktiviteten stödjer teamet eller kritiserar produkten.

Med detta tänk får vi fyra olika klasser av testaktiviteter. I varje iteration är det viktigt att kontrollera att testningen täcker dessa efter behov. En vanlig tankevurpa är att man i iterationen ska testa dessa i tur och ordning – målet är inte missa viktig testning av den funktionalitet som implementeras.

• Q1: Teknologi-nära tester som stöder teamet. Typiska tester är komponenttester – många gånger skrivna av utvecklarna som skriver komponenterna. Dessa är till stöd under utveckling och kan med fördel återvinnas som regressionstester (J). I många fall kan även integration av två eller ett par komponenter åt gången testas betraktas som del av Q1.
• Q2: Business-nära tester som stöder teamet. Typiska tester är funktionella tester, acceptanstester, exempel eller prototyper. Allt som kunden lätt förstår som hjälper teamet. I vissa kan även denna typ av test automatiseras och lätt användas vid regressionstester.
• Q3: Business-nära tester som kritiserar produkten. Typiska tester är utforskande tester, alfatester, betatester och felgissning. Även demonstrationer kan vara ett bra verktyg.
• Q4: Teknologi-nära tester som kritiserar produkten. Typiska tester är lasttester, skalbarhetstester, säkerhetstester, prestandatester, användbarhetstester och så vidare. Ibland kan verktyg som utökat testdata eller aktivitetshanteraren i Windows användas (eller top och free i Unix).

Vart energin skall läggas beror på typ av funktionalitet som skall implementeras i iterationen. Några exempel:

• I illustrationen har jag indikerat ett stor antal teknologi-nära tester som stöder teamet (kvadrant 1). Om man bara får välja en typ av testaktivitet är det i allmänhet denna man bör prioritera. Det är sällan en dålig idé att skriva komponenttester.
• Skall en inloggningsfunktion utvecklas kan det vara på sin plats att satsa en hel del krut på säkerhetstester (som kan anses tillhöra kvadrant 4: Teknologi-nära tester som kritiserar produkten). I så fall kanske extern kompetens i penetrationstester krävas.
• Skall en kundvagn på en internetbokhandel implementeras kanske exempel är till stor med att låta automatiserade robot-användare testa att lägga till varor, ta bort varor, betala eller "hitta liknande varor" i en prototyp (kvadrant 2: Business-nära tester som stöder teamet).
• Upptäcker man att många användare påbörjar köp i internetbokhandeln men sällan avslutar kan det vara läge att köra användbarhetstester för att reda ut om användarna förstår/hittar betala-knappen. Kanske är det för komplicerat att ta bort varor ur korgen? (kvadrant 3: Business-nära tester som kritiserar produkten.)

Utökningar

Man skulle kunna tänka sig att specificera denna testprocess vidare för att täcka hela systemets livscykel. Man kan då tänka sig fyra faser.

• Förstudie-, krav- eller uppstartsfas. Som tidigare A-C.
• F-H som en fas av överlämnande och testning innan systemet överlämnas till kund/slutkund.
• Mellan uppstartsfasen och överlämnandefasen: som tidigare en agil utvecklingsfas.
• Efter överlämnande kan en lång fas av underhåll eller utökning komma. Man kan lätt tänka sig att kunder eller slutkunder kommer med nya krav eller hittar oönskade avvikelser i systemet. Dessa hanteras på ett liknande sätt som i den agila utvecklingsfasen. Stora skillnader ligger i att projektledning/CCB har två viktiga filter:
  1. Som tidigare gäller att nya krav accepteras av strategiska skäl och inte av automatik. I det ideala fallet utökas krav- och testspecifikationer även i denna utvecklingsfas. Annars bör en ny slags testspecifikation upprättas med lämpliga högnivåtester för ett acceptanstestprotokoll.
  2. Det nya steget (N) gäller huruvida en ny iteration genomföras. Man kan även tänka sig att projektet ligger vilande mellan iterationer för att samla tillräcklig back-log.
• Utöver regressionstester som genomförs varje iteration bör vid behov någon form av utökad system- eller acceptanstestning (O) genomföras då och då. Alternativet att endast testa nya krav kan leda till regression

Tillhör Kategori Test
Tillhör Kategori Mjukvara
Se också Riskbaserad Testning
Se också Lean Utveckling