ReQtest AB

Effektivisera testerna genom att testa mindre

Nyhet   •   Aug 23, 2012 09:44 CEST

Om man följer V-modellen utan att tänka efter är det mycket lätt att testerna blir tröga och ineffektiva. Utvecklingen tar lång tid och det blir dyrt. Nästan alla lägger idag väldigt mycket tid på test efter det att kodningen avslutats.

V-modellen beskriver en bunt aktiviteter som behöver utföras på något sätt i en ungefärlig ordning. Allt som finns i modellen är tänkvärt, men modellen säger ingenting om hur omfattande aktiviteter som ska göras. Dessutom hänger de olika aktiviteterna ihop. Om någon av kravfaserna genomförs dåligt behövs mycket mer testtid och vice versa.

Med enkla ändringar i arbetssättet går det att minska testtiden samtidigt som kvaliteten ökar. Det är möjligt att minska kostnaderna med 80 % och samtidigt öka kvaliteten avsevärt.  Nyckeln till framgång ligger i att arbeta mycket mer med kvalitetssäkring och mindre med testning.

Har ni användningsfall för att dokumentera kraven? Använd dem som acceptanstestfall också. Kom ihåg att acceptanstest endast syftar till att kolla att verksamhetskraven är uppfyllda. Syftet är inte att göra detaljerade tester. För detta funkar användningsfallen utmärkt. Om de inte går så är det något fel på användningsfallen. Om kraven inte är tillräckligt bra, skriv acceptanstestfallen samtidigt som kraven tas fram. Ett arbetssätt är att skriva user stories som kompletteras med acceptanstestfall.

Under System requirements-fasen kan flera aktiviteter inom kvalitetssäkring göras. T ex användningstester i syfte att ge feedback till utvecklingsteamet om användbarheten.

Parprogrammera ofta och regelbundet, det gör att utvecklarna lär sig mer om varandras delar och då minskar personberoendet. Låt utvecklarna granska koden i samband med rättningar. Användare och systemtestare kan testa utforskande parallellt med utvecklingen. Det gör att de flesta felen och följdfelen kommer att hittas extremt tidigt, när det är som billigast att åtgärda dem. Utför användningstester i samband med programmeringen, då finns det inget behov av att göra dessa tester på systemtestnivån, då det ändå är för sent att åtgärda de användbarhetsproblem som påträffas.

Automatisera lågnivåtesterna. Det är ofta lönsamt att automatisera komponent- och integrationstesterna och att införa continuous integration. När vi automatiserat dessa tester har vi ofta fått ner antalet manuella tester till 20 %.

Har ni massor av testfall? Det finns stora dolda kostnader i att förvalta gamla testfall. En lösning är att skriva färre testfall och arbeta mer med checklistor och utforskande testning. Ett första steg kan vara att göra testfallen enklare så att de blir lättare att förvalta.

Det är billigare och mer effektivt att proaktivt arbeta med kvalitetssäkring än att arbeta reaktivt med testning.

Resultatet

Genom att arbeta på det här sättet kommer aktiviteter längst V-modellens högra sida att genomföras men avsevärt mindre än vad som görs normalt. Väldigt många av testaktiviteterna görs längs den vänstra sidan i V-modellen och det görs att felen hittas tidigt. Genom att arbeta mer med kvalitetssäkring i V-modellens vänstra sida blir kvaliteten på det som skapas bättre.

Nästa steg

Fokusera mer på kvalitetssäkring och mindre på test. Strömlinjeforma processerna så kommer ni spara både tid och pengar. Mät effektiviteten före och efter ändringen. Och välj rätt verktyg som stödjer processen. Många fel kommer att hittas även när arbetet bedrivs på det här sättet. En stor del av testerna kan göras med checklistor och en hel del kommer förmodligen fortfarande göras med vanliga testfall. För detta behövs ett effektivt verktyg. Får jag föreslå ReQtest?