VI KAN VÄL AVSKAFFA ACCEPTANSTESTERNA!?

Aida Taye, erfaren konsult inom testledning, skriver om sina erfarenheter kring att många ifrågasätter ifall strukturerade acceptanstester verkligen behövs när man jobbar Agilt.

Jag har arbetat med test och acceptanstestledning i ca åtta år nu, både i organisationer som anser sig jobba agilt och organisationer som arbetar mer traditionellt. Jag har varit testledare för enskilda, komplexa system samt testledare för End2End flöden i projekt där flera system i flödet bytts ut på samma gång. Framför allt så har jag suttit som acceptanstestledare på mottagarsidan, och det är nog just det som gör skillnaden i hur jag ser på acceptanstest.

Genom åren har fler och fler företag anammat agila eller halvagila arbetssätt och på många sätt förbättrat sitt testförfarande. Genom ökad förståelse för tidig testning har även acceptanstestarna involverats i allt tidigare skede vilket har bidragit till att minimera olika typer av risker i leveransen. Trots den ökade förståelsen för agilt arbete, så möts jag i uppdrag efter uppdrag av samma frågor. Frågor såsom

– Behöver vi planera inför acceptanstesterna?

– Behövs verkligen en acceptanstestperiod?

– Behöver acceptanstesterna dokumenteras?

– Behövs verkligen utsedda testpersoner i en agil värld med ett gemensamt testansvar?

Dessa frågor ställs inte minst av erfarna personer inom test och syftar ofta till att ifrågasätta ifall strukturerade acceptanstester verkligen behövs när man jobbar agilt. Detta har fått mig att fundera över vad det är som gör att vi har så olika bilder av hur acceptanstest behöver hanteras. Tydligt är att många än idag likställer ett strukturerat arbetssätt med ett vattenfallstänk och misstar ett adhoct arbetssätt för ett agilt. Så fort dokumentation och struktur förs på tal så bemöts man med att det inte är agilt.

Var i det agila manifestet står det att detta är motsägelsefullt? Om det är detta man påstår så har man missat själva budskapet. Det som är viktigt i ett agilt testarbete (precis som vid all agilt arbete) är att identifiera behovet och ifrågasätta varför man gör de saker man gör. Dokumenterar vi för dokumenterandets skull eller finns det ett behov av dokumentation och i så fall på vilken nivå? Detsamma gäller de övriga frågorna.

Det finns en skillnad i de acceptanstester som görs i en leveransorganisation och de acceptanstester som görs i en mottagarorganisation. De har olika syften och perspektiv och därmed kan även testförfarandet skilja sig åt. Acceptanstestledaren har ett ansvar att fundera över hur testerna bör utformas genom att se över vilken situation man befinner sig i. Har organisationen köpt in ett standardsystem som ska implementeras rakt av eller behöver det anpassas för att stötta ett komplext behov? Utvecklas systemet in-house eller inte och i vilken utsträckning kan i så fall mottagarorganisationen vara involverad i processen? Dessa är förutsättningar som har en påverkan på acceptanstesternas utformning.

Vid systemutveckling kan acceptanstestarna vara inne i ett tidigt skede och kontinuerligt testa enskilda releaser. Detta är dock inte detsamma som att kvalitetssäkra hela flöden eller arbetsprocesser. Vissa organisationer och situationer har behov av en eller flera mindre acceptanstestperioder i tillägg till löpande test av det som levereras. I en leveransorganisation har man ett intresse av att acceptanstesta funktioner och flöden i den applikation man levererar. I en mottagarorganisation kan behovet skilja sig från den i en leveransorganisation. Acceptanstesterna kan innefatta test av End2End integrationer eller tester för att säkerställa att applikationen stöttar arbetsprocesser och särskilda behov som organisationen har. Mottagaren har framför allt ett behov av att säkerställa att leveransen motsvarar det som har beställts.

Acceptanstestledaren ska också se över behovet av dokumentation. Flöden och alternativflöden kan vara så komplexa att det finns ett behov av att dokumentera och bocka av vad som har levererats och acceptanstestats. Det innebär inte nödvändigtvis att alla testfall ska dokumenteras. Återigen så är det behovet som styr.

En fras som det ibland uppstår missförstånd kring är ”test är allas ansvar”. Att test är allas ansvar får inte resultera i att det inte är någons ansvar. Som acceptanstestledare behöver man fundera över vem som testar vad och utifrån vilket perspektiv. Att ha ett stort antal acceptanstestare innebär inte per automatik en bättre kvalitetssäkring. Istället behöver acceptanstestledaren fundera över vad syftet med testerna är och vad man vill kvalitetssäkra. Är det utseendet, funktionaliteten, flödet eller att arbetsprocessen stöttas som är i fokus för testerna? Utifrån detta får man svar på vilka som bör vara inne som acceptanstestare.

Istället för att stämpla planering, struktur och dokumentation som icke-agila fenomen, behöver vi istället fundera över vad behoven är och varför. Annars riskerar vi att falla tillbaka i att arbeta adhoc. Att arbeta strukturerat och att arbeta agilt är inte motsägelsefullt. Detta gäller även acceptanstest. Det som behövs är snarare att inkludera mottagarens acceptanstester i den agila utvecklingen och hitta ett sätt för mottagaren att vara delaktig i ett tidigt skede utan att för den skull ge avkall på kvalitetssäkring av helheten.