Agila Testkvadranter

Bakgrund

I Boken Agile Testing av Lisa Crispin och Janet Gregory (isbn 9780321534460) nämns konceptet Agila Testkvadranter - och det är ett kraftfullt verktyg. Det är tydligen ett begrepp som Brian Marick myntade i sin blogg 2003 (se [1]) och som hottades upp av Lisa och Janet i boken (se mer i Lisa Crispins blogg: [2]). En viss "rubytester" gjorde en trevlig slide show för att på sitt sätt förklara kvadranterna (se [3]).

Översikt

I princip går agila testkvadranterna ut på att dela upp testing i ett plan med två axlar. Den ena axeln delar aktiviteterna i tester som stöder teamet och tester som kritiserar produkten. Tester som stöder teamet är till exempel enhetstester (de kan fungera som ett stöd vid utveckling, faktorisering och som regressionstester) och säkerhetstester av typen sql-injection. Den andra axeln delar upp test aktiviteterna i tester som är teknologi-nära (eller kod-nära) och business-nära (eller kund-nära). Teknologi-nära tester är till exempel last-tester och kund-nära kan vara GUI-tester.

Det intressanta nu är att test-aktiviteterna blir uppdelade i fyra kvadranter:

1. Teknologi-nära tester som stöder teamet
2. Business-nära tester som stöder teamet
3. Business-nära tester som kritiserar produkten
4. Teknologi-nära tester som kritiserar produkten

Att dessa fyra delar fått nummer 1-4 är bara ett sätt att dela upp dem och hålla ordning på dem, Lisa påpekar i sin blogg (och i boken upprepade gånger) att det inte är en prioriterings-lista och man behöver inte göra det ena innan det andra - man behöver hålla koll på alla fyra samtidigt. Ibland behövs kanske bara en del tester och ibland behövs aktiviteter för att täcka alla fyra kvadranter. Som utvecklare är det lätt att tänka Vi har så bra enhetstester, vad ska vi med testare till? Det är vid den sortens tänk som agila testkvadranterna snabbt och enkelt kan visa att nej, det räcker (oftast) inte.

Jag gillade det här konceptet ganska mycket och letade efter en bra bild att använda här - men jag hittade ingen - så jag ritade om bilden som finns i boken och lade till lite egna tolkningar och exempel på test-metoder. Vi får se om jag lägger upp bilden på Wikipedia. Så här är i alla fall min tolkning av agila test-kvadranter:

Agil TestKvadrant 1: Teknologi-nära tester som stöder teamet

Här kommer de tester som man traditionellt anser hör ihop med agil utveckling: enhetstester, modultester och integrationstester mellan moduler. Med dessa får utvecklare en känsla av att koden går att lita på, och med dessa tester i ryggen är det lättare att vara modig och genomföra ändringar i koden (refaktorera). Exempel på verktyg för detta är xUnit (se till exempel mina sammanfattningar om Python Unit Test och Csharp Unit Test In Sharp Develop) eller doctest (se Python Doctest And Docstring och min mall för Python Module With Doctest).

Agil TestKvadrant 2: Business-nära tester som stöder teamet

Dessa tester är tester som visar på att systemet man utvecklar "gör rätt", men de är skapade med ett språk eller i en domän som kunden förstår.

För automatisering hänvisar boken till verktyget FitNesse (se wikipedia: [4]) - men de påpekar att antagligen inte går att automatisera alla business-nära tester som stöder teamet. Jag har nosat på FitNesse tidigare men aldrig fått chansen att använda det.

Agil TestKvadrant 3: Business-nära tester som kritiserar produkten

Att demonstrera systemet för kunden eller låta slutanvändare alfa/beta testa systemet är bra exempel på business-nära tester som kritiserar produkten. Att studera slutanvändare som använder produkten skulle kunna ligga till grunden för användbarhetstester som också hör hemma i den här kvadranten.

En metodik som återkommer ofta i boken är exploratory testing (se wikipedia [5]) som är en blandning av testning, test design och inlärning. Viktigt här är att man avskärmar vad man vill testa (antagligen både i scope och tid) och att man dokumenterar. Resultat från en session av exploratory testing kan mycket väl ligga till grund till framtida regressionstester.

Agil TestKvadrant 4: Teknologi-nära tester som kritiserar produkten

Lisa och Janet ger som exempel: last-tester, säkerhets-tester och användbarhets-tester. Dessa är antagligen inte kundens expert-område men kan vara otroligt viktiga. Ska man till exempel göra ett verktyg som exporterar data från en databas är det bra att testa med en liten enkel databas som ryms i minnet i sina teknologi-nära tester som stöder teamet. Men det inte ok att applikationen kraschar eller blir som sirap när den riktiga databasen används.

Att glömma bort att planera eller budgetera för teknologi-nära tester som kritiserar produkten är lätt.

Lisa och Janet påpekar också att man kan ha behov av externa verktyg eller konsulter för den här typen av tester - men att man kan komma oväntat långt med enkla medel som top, free och att titta i log-filer (se till exempel [6]).

Se mer i Boken Agile Testing
Tillhör Kategori Mjukvara
Tillhör Kategori Test