Ett stopp för tester som faller mellan stolarna

I många projekt leder bristen på kommunikation mellan funktionstestare, prestandatestare och utvecklare till att vissa typer av tester inte blir gjorda, medan andra kanske görs flera gånger. Vi måste inse att vi sitter i samma båt och inte på olika stolar. Då kan vi minska de totala kostnaderna för systemutveckling och underhåll samtidigt som fler riskområden hanteras i testarbetet.

Sedan många år har IT-projekten nått ett arbetssätt där funktionstestning genomförs löpande i takt med att ny funktionalitet levereras av utvecklingsteamet. Prestandatestning däremot kommer ofta in mycket senare, bland annat eftersom det ofta är förknippat med höga kostnader i form av licenser och programmering / skriptning.

Projektledningen kanske ser en möjlighet att spara pengar genom att förlägga de tekniska prestandatesterna sist och därmed undvika kostnader för att underhålla prestandatestskript med mera. Prestandatestarna kommer därför in för sent, med en sämre förståelse för systemet som ska testas och dessutom kanske många av de förberedelser som borde ha genomförts inte är klara. Risken är överhängande att projektet därmed upplever en jättedyr prestandatestperiod utan vettigt resultat.

För lite fokus på teknisk testning i de tidiga faserna

Under projektets livscykel fram till dess att prestandatestning startar ligger funktionstestarnas fokus på att verifiera de funktionella kraven och då speciellt att systemets scenarion går att genomföra och att affärsreglerna efterlevs.

Enkla tekniska fuktionstester förbigås ofta eller prioriteras bort:

1. Finns det exekveringsfel i klienten, t.ex. JavaScript-fel i en webbläsare? Detta upptäcks enkelt med hjälp av verktyg som t.ex. FireBug i FireFox.
2. Kontaktas server-sidan onödigt ofta? I en webbläsare kan återigen FireBug komma till pass, men också loggfiler på servern kan fungera som input till en sådan kontroll
3. Kontaktas databasen onödigt ofta?
4. Förekommer det ogiltiga länkar i webbläsaren?
5. Läggs mycket exekveringstid i klienten?
6. Fail Over – vad händer i systemet när ett av serverbenen går ner. Detta kan enkelt testas med en enda användare genom att ta ner det ben som användaren är inne på för närvarande.

Ovanstående tester sorterar under termen icke-funktionell testning och av den anledningen skjuts dessa tester ofta på framtiden. Andra icke-funktionella testfall tas dock ofta om hand, t.ex. autenticering och behörighetskontroll.

Det är välkänt att defekter kostar mer att åtgärda ju senare de tas om hand. Det gäller förstås även defekter som kommer ur ovanstående typer av tester. Sådana defekter indikerar ofta  arkitekturella problem vilka inte sällan kräver omfattande omprogrammering.

Sen prestandatestning leder till nerdraget scope

Prestandatestarna kommer alltså ofta till skott först mot slutet av projektets livscykel och då under hård tidspress. Fokus läggs på att säkerställa svarstider under belastning. Detta är nämligen något som inte alls har kunnat testas tidigare. Applikationen antas fungera rent funktionellt eftersom den genomgått flera varv av funktionstestning.

Ofta förbises följande:

1. Fungerar affärsreglerna under belastning också? Räknar systemet rätt under belastning? Ett vanligt problem är Javas klasser för strängformatering som inte är trådsäkra.
2. Sker det sammanblandning av olika användares sessioner? Detta kan leda till att användare förlorar den egna informationen och istället ser andra användares data.
3. Fail Over – det saknas tid för att genomföra bra fail over-tester.

Ett helt annat problem som prestandatestarna ofta står inför är otillräckligt eller obefintligt testdata när prestandatestperioden drar igång. Att ta fram testdata är ofta en komplicerad och dyrbar process, som behöver påbörjas tidigt för att nå tillräckligt bra kvalitet.

En kostnads- och kvalitetseffektiv lösning?

Mitt förslag för att överbrygga glappen inom test och förbättra kommunikationen mellan utvecklings- och testteamen är att ta med en person med prestandatestarprofil tidigt i testarbetet. Förvisso skulle dyra prestandatestverktyg kunna börja användas redan tidigt men det finns i detta läge betydligt mer effektiva och billigare / gratis verktyg. I början av projektets livscykel arbetar denna person förslagsvis med att utföra enkla tekniska funktionstester. Det blir också naturligt att denna person diskuterar med utvecklingsteamet för att förbättra testbarheten framöver. Arbetet med att ta fram testdata inför prestandatesterna får också en aktiv intressent genom hela projektet.

Effekten med det föreslagna tillvägagångssättet är att fler prestandatestkörningar hinner genomföras under prestandatestperioden. Detta resulterar i mer information till projektet och en bättre täckandegrad. Samtidigt har många viktiga risker och defekter identifierats på ett tidigare stadium vilket leder till en lägre totalkostnad för att genomföra projektet och leva med systemet i förvaltning.

Den direkta kostnaden för att införa detta blir inte nödvändigtvis högre eftersom prestandatestaren kan fungera som funktionstestare (om än mer tekniskt orienterad) i testteamet genom hela projektet. Dessutom ökar chanserna till synergier mellan test och utvecklingsteamet när den mer tekniskt lagde prestandatestaren finns med och fungerar som katalysator i det projektgemensamma kvalitetsarbetet.