Kan du testa?
Jag skrev i min förra bloggpost IT-utveckling är ett lagspel ”Ofta när företag inser att deras produkt inte håller måttet, så anställer de testare, eller ännu oftare ger de någon anställd ansvaret att testa den färdiga produkten. Att försöka lösa kvalitetsproblem med test av en färdig produkt är lite som att bota tandvärk med Alvedon. Det blir kanske lite bättre temporärt men vi måste se till att man hanterar roten till det onda.”
Jag påstår alltså att ganska många som jobbar med test inte kan test. Visst, de hittar fel i de system som företaget de jobbar för bygger, men det bygger endast på erfarenhet. De vet var felen brukar dyka upp och de hittar dem förhoppningsvis. Problemet är dock att så fort företaget gör något nytt så släpps onödigt mycket fel igenom och de hittas i bästa fall sent i utvecklingsprocessen.
Att ett system fungerar bra i produktion just nu, behöver inte betyda att vi har en bra produkt. En dåligt testat system kan få stora problem med allvarliga konsekvenser långt senare, men det tänker jag inte gå in på djupet just nu, det tar vi i en senare bloggpost.
Vad är egentligen testning?
Är det att ”prova” om ett system eller program fungerar? Är det att leta efter fel? Är det något annat?
Test är allt ovan och mycket, mycket mer. Att försöka sig på att definiera vad som är test är jättesvårt men enligt James Bach så är testarbete: ”a set of ideas, instructions, or data designed to aid in testing some product in some way”. D.v.s. allt som du utför i samband med test. Tex så samlar du in material, läser krav, får idéer om test, som du sedan utför.
Test i sitt sammanhang
Innan vi börjar testa så är det viktigast av allt att sätta test i sitt sammanhang. Varför testar vi just det här? Vad har vi för syfte? Hur vet vi att de specifika testerna uppfyllt kraven? Inte heller detta tänker jag gå igenom i den här bloggposten, men det är något du måste veta innan du börjar.
Hur du skall testa beror på en massa olika faktorer, tex:
Konsekvenserna om något blir fel
Det är en glidande skala där vi har kattbloggar samt förströelse i ena och pengar samt liv i den bortre ändan. Det säger sig själv att om vi skall testa en internetbank eller en pacemaker så är konsekvenserna större om vi gör fel än om vi skall testa en kattblog eller ett enkelt förströelsespel. Det är även en glidande skala inom ett system/program. Att kontaktformulären fungerar har troligtvis inte lika hög prio som att inloggningssäkerheten på en internetbank.
Var i integrationscykeln befinner vi oss
Enhetstest, integrationstest, systemtest, systemintegrationstest, acceptanstest och prestandatest är olika testområden som kräver alla olika kompetenser. För att göra det ännu mer komplicerat så finns det massor av testtekniker under var och en av dessa. Vad jag tog upp här är bara några exempel på testområden så det kan vara mycket mer komplicerat.
Var i produktcykeln vi befinner oss
Håller vi på att utveckla systemet eller är det redan i drift?
Vi har ett fungerande system som vi tex skall:
- Uppgradera med nya funktioner.
- Flytta till en annan miljö
- Uppgradera hårdvara (nätverk/server/etc)
Förutom ovanstående så har vi saker som tid, kompetens, utvecklingsmodell, testmiljö och mycket annat att ta hänsyn till men det får jag ta upp en annan gång.
Test kräver kompetens
Det finns följaktligen många olika saker som påverkar valet av tekniker och om du inte kan grunderna är risken stor att du inte hittar fel eller testar ineffektivt, eller troligare både och samtidigt. Testerna bör utföras på ett sätt som är lämpligt för det du skall testa just nu.
Utvecklare bör lära sig grunderna för att kunna utföra utföra egenkontroll av sitt arbete. Om projektet är stort med många inblandade bör de få stöd av personer som kan ta ett helhetsgrepp över testerna och coacha utvecklarna.
Eller som jag brukar svara på de flesta frågor ”Det beror på”.