Testnivåer används för att fokusera testarbetet och testa
utifrån olika egenskaper hos systemlösningen. Vid olika testnivåer upptäckts
olika typer av fel samt att de olika testerna skiljer sig i hur lång tid
genomförandet tar. Man börjar med basala tester av arkitektur och grundläggande
funktioner. Då får man snabb återkoppling om utvecklarna är på rätt spår. De
övre testnivåerna handlar om komplexa tester av komplicerade användarfall och systemsamband.
I den här bloggposten visar jag hur olika testnivåer kan kopplas till den agila utvecklingscykeln.
Ett vanligt synsätt är att man ska sträva efter att hitta
alla fel så tidigt som möjligt vilket beror på ett antagande att kostnaden för
att åtgärda buggar ökar med tiden. Jag anser att det inte nödvändigtvis är
sant. T.ex. är det kostsamt att hitta och rätta obskyra integrationsfel vid
tidiga testnivåer, utan tillgång till angränsande system. Sträva istället efter
att testa ekonomiskt och vänta med de komplexa testerna till senare faser.
Ifall de basala funktionerna åtgärdas tidigt, så kommer antagligen de felaktigheter
som upptäck senare att kunna åtgärdas relativt enkelt.
Några ryska matrushka-dockor får symbolisera olika
testnivåer. Varje testnivå har olika syften och tid för återkoppling till
utvecklarna skiljer sig åt.
TDD och parprogrammering
Testerna börjar redan medan utvecklarna skriver sin kod. Med
bra utvecklardiciplin kan många fel hittas redan från början. De fel som hittas
kan åtgärdas omgående och dessa typer av utvecklingsnära tester kan alltså bli
mycket effektiva. Ge utvecklarna tid för att experimentera med parprogrammering
och testdriven utveckling. Även testare och utvecklare kan arbeta i par och
bidra med respektive kompetens.
Continuous integration
Här handlar det om att implementera och integrera små
utvecklingsdelar i taget. När utvecklarna är klara med en delfunktion adderas koden
till den gemensamma kodbasen. Därefter följer ett automatiserat kodbygge med
ev. automatiserade modultester. Kodbygget kan även innehålla enklare regressionstester,
deploy till testmiljöer och liknande. Genom täta incheckningar och kontroller
av hur ny kod fungerar i systemet så kan avvikelser åtgärdas tidigt. En annan
fördel är att med continuous integration får man ett bra ramverk för
versionshantering, releasehantering och testautomatisering.
JAM-test
I det agila projektet finns behov av proaktiv testning av
utvecklingsaktiveter allt eftersom dessa blir klara. Eftersom
utvecklingsaktiviteterna ej är entydiga med användarfall eller testscenarier så
kan man inte tala om regelrätta systemtester. Syftet är istället för testarna
att ge så effektiv återkoppling som möjligt på de nyutvecklade funktionerna,
gärna med utforskande testtekniker. Jag kallar detta för JAM-test och redogör
för detta i tidigare blogginlägg.
ACT-test
I slutet av en agil utvecklingscykel ser jag ofta behovet att
göra systemtester och regressionstester på hela levererade kodbasen efter
kodfrys. Eftersom tidigare tester gjorts på delar av funktioner utifrån
delleveranser från utvecklarna så är detta kanske första gången som användarfall
kan köras i sin helhet. Det är också första gången som alla funktioner finns
med i en potentiell releasekandidat. Jag kallar detta för ACT-test och ser det
som ett koncentrerat hypereffektivt systemtest. Testerna är nu mer formella än tidigare
testnivåer och veriferar de användarfall som ska levereras utifrån de
testscenarier som skapats av testerna. Jag berättar mer om ACT i ett tidigare
bloginlägg.
Systemintegrationstest och acceptanstest
Systemintegrationstest och acceptanstest är väsenskilda de
övriga testnivåerna eftersom de ofta görs utanför den agila utvecklingscykeln. Dessa
tester innefattar angränsande system och organisationer utanför det agila
teamets kontroll. Man kan därmed inte ställa samma höga krav på effektivitet i
genomförande och återkoppling. Se till att planera för nödvändiga
testaktivteter och åsidosätt resurser i lämpliga sprintar så att teamets övriga
arbete inte blir lidande när systemintegrationstester och acceptanstester pågår
samtidigt som ordinarie utvecklingsarbete.
Inga kommentarer:
Skicka en kommentar