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

Q: Q som i kvalitet - allt utom test!

Av Charlotta Carlsson 2020-02-23

Har du som systemleverantör eller beställare tänkt att kvalitet åstadkommer vi med en bra testprocess? Finns det bristande kvalitet så är det mer test som behövs? Med risk för att diskvalificera mig för alla framtida konsultuppdrag inom test vill jag säga: glöm det! Alltså att mer test skulle vara lösningen på dålig kvalitet.

Visst, vi blir absolut bättre på att hitta fel i form av missförstånd och buggar om vi testar strukturerat. Vi kanske undviker att släppa alltför dåliga lösningar till användarna. Men jag vill påstå att det finns andra saker som har större påverkan på kvaliteten i systemleveranser än mängden test. Dessa kommer jag på på rak arm:

• Beställarkompetens
• Konfigurationshantering (CM)
• Sammanhållen systemarkitektur
• Konsekventa utvecklingsriktlinjer
• Användarcentrerad systemutveckling (UX, effektstyrning, användbarhet, interaktionsdesign...)
• Återkoppling från service management
• Ett iterativt arbetssätt
• Att IT och verksamhet jobbar tillsammans mot samma mål
• Kravhanteringskompetens

Börjar man borra i detta så visar det sig nog att testaktiviteter hör hemma inom många av dessa områden. Men det är alltså inte testandet i sig som ger kvalitet. Det bidrar bara med information om nuläget vad gäller kvaliteten.

Vi som jobbar med kvalitetssäkring i IT har några återkommande mantra: "Systemet blir inte bättre än kraven" och "Det går inte att testa bort dålig kvalitet". Det vi menar då är inte att det ska skrivas perfekta kravdokument. Vi menar att ju tidigare i projektet som felen hittas, desto billigare blir de att åtgärda.

Detta skulle jag säga är extra sant på acceptansnivån!

Eftersom det då inte i första hand handlar om rena buggar utan om systemets relevans hos en användargrupp. Har man väl byggt in sig i en viss design av produkten så blir det kostsamt att försöka ändra på det senare. Dvs. fel på acceptansnivån som hittas i en traditionell acceptanstest i slutet av ett projekt nära inpå driftsättning är ofta helt enkelt för sent att göra något åt. Istället hamnar man lätt i en diskussion om vad som ska betraktas som fel, eftersom tolkningen av kraven även har bäring på de ekonomiska mellanhavandena.

I upphandlingar av IT-system hoppas och tror jag därför att det blir allt vanligare att beställare vid sidan av vanliga funktionella och icke-funktionella krav även ställer krav på systemleverantörens arbetssätt.

Slutsats för bokstaven Q: Kvalitet skapas inte av test.