Blogg - Omfattning

https://commons.wikimedia.org/wiki/File:Godin_van_de_Wind_4_Nieuwpoort.jpg

O: Omfattning - allt!

Av Charlotta Carlsson 2020-02-21


Vad ingår egentligen i en acceptanstest? Ditt projekt och sammanhanget i övrigt kan sätta ramarna på många olika sätt. Kanske är det "bara" en ny release av ett befintligt system i en given teknisk och organisatorisk miljö. Eller också ska precis allting bytas ut, inklusive systemleverantörer, verksamhetsprocesser och förvaltningsmodell. Oavsett var på skalan din acceptanstest befinner sig behöver du i din teststrategi och -plan besvara frågan: Vad är det vi ska testa?


Flera aspekter av "vad" kan finnas:


1. Leveransens omfattning. Var noga att stämma av med systemleverantören(-erna) att ni har samma uppfattning om leveransomfattningen. Det är förstås en projektfråga i stort, inte bara en testfråga. Men jag rekommenderar att lägga in en leveransavstämning inom ramen för testförberedelserna. Det konkretiserar förväntningarna och på så sätt uppdagas det om det finns olika uppfattningar.


2. Testobjekt. En programvara av något slag brukar vara ett självklart testobjekt. Kanske behöver det preciseras vilka moduler som omfattas och vilka användargränssnitt.
Men det kan också finnas andra mindre självklara testobjekt såsom dokumentation, förvaltningsrutiner, supportåtagande, utbildning.


3. Plattformar. Jag skulle inte säga att det typiskt hör till en acceptanstest att testa systemet på alla upptänkliga webbläsare och devices även om det skulle finnas generella krav på portabiliteten. Men testen bör definintivt omfatta de olika typer av klienter och webbläsare/motsvarande som ska användas när systemet går i drift.


4. Infrastruktur. När systemet ska tas i drift kommer det att landa i en teknisk infrastruktur och denna behöver också testas. Här kan det vara andra aktörer inblandade förutom den/de systemleverantörer vars leverans som det är fokus på i acceptanstesten. Med "infrastruktur" menar jag sådant som en driftmiljö med viss kapacitet och brandväggar, SOA-plattformar, autentiseringsramverk, e-post- och sms-funktioner. Det sägs ofta att acceptanstest ska ske i en "produktionsliknande miljö".  Det är en bra utgångspunkt men man behöver definiera vad detta betyder konkret i det aktuella projektet.


5. Systemkonfigurationer och data. För att en acceptanstest ska ge nödvändig information och säkerhet inför produktionssättning bör den omfatta alla de datakonverteringar, register och konfigurationer som ska produktionssättas. Att bara testa programvarans "funktion" räcker inte. Det ska för övrigt normalt vara avklarat i systemtester hos systemleverantören. I acceptantesterna vill vi verifiera att alltihopa funkar tillsammans.


6. Integrationer. De systemintegrationer som ingår i eller påverkas av leveransen ska testas. Vilka är det? Den kartan är inte alltid lätt att definiera. De som ansvarar för de integrerade systemen behöver involveras i testplaneringen. (Jag har tänkt skriva mer om teststrategi för systemintegrationer vid bokstaven I.)


7. Verksamhetsprocesser. Acceptanstest handlar om att landa system i verksamheten hos användarna. Acceptanstesten bör därför omfatta alla de verksamhetsprocesser som påverkas av systemleveransen, och angreppssättet blir att testa hela flödet precis på det sätt
som det ska användas i praktiken.


Frågan om acceptanstestens omfattning kan som synes besvaras i många dimensioner. DU behöver avgränsa och hantera det praktiskt utifrån situation. Kanske faller några av dimensionerna ovan utanför ramen för acceptanstestledningsuppdraget? Om så är, behöver det finnas inom någon annans ansvarsområde.


Jag brukar använda mig av begreppet "Testområde" för att dela in hela testomfattningen i lämpliga bitar och koppla dessa till ansvariga personer eller projektgrupper. Ett testområde kan då vara vilken som helst del av allt det ovan, eller i kombinationer som är praktiska att hantera i ett svep.


När du har skaffat dig koll på omfattningen av testen kommer nästa fråga: Kan man verkligen testa allt? Nja, en riskbaserad prioritering är bra att göra (se bokstaven P) men det lönar sig sällan att blunda för viktiga aspekter av systemleveransen och allt som den påverkar.


Slutsats för bokstaven O: Acceptanstestens omfattning är hela leveransen. Den kan praktiskt delas in i testområden.