En reflektion över ISO29119

test

Kände bara för att kommentera min syn på arbetet runt ISO29119 och dess – i mitt tycke – meningslösa syfte.

Jag har jobbat med utveckling inom storföretag sedan slutet av 80-talet och har vigt mitt liv åt test sedan tidigt 90-tal.

Hur många manår jag har lagt ner på utveckling med vattenfallsmodellen vet jag ej men hör jag PROPS eller Prince 2 en gång till så kommer jag troligen att kräkas!
Det monolitiska ramverk och process-träsk som dåtidens testmetodik förespråkade var baserad på gigantiska projektcykler där det inte var ovanligt med 12-24 månaders utvecklingsfas – utan inkrementella leveranser!
På den tiden så hade man en implementation proposal att jobba efter och den var skriven på kodnivå så att det skulle bli exakt som arkitekterna ville ha det. Här pratar vi om enorma domänkunskaper som grund till detta arbete och var en förutsättning för att det skulle lyckas.

Med denna utvecklingsmodell så var man tvungen att ha ett system som baserades på dokumentation, dokumentation, dokumentation och åter igen dokumentation.

Fast forward till 2008 och nu med en marknad som svänger som snabba motorbåtar till skillnad mot 90-talets oljetankers och den problematik man har haft med den gamla rigida metodiken, nu har vinden äntligen börjat vända även på storföretagen och man inser att projektcykler på mer än ett år ger på tok för höga risker och osäkerhet med return of invest.
Först dyker Scrum upp som en gubbe i lådan och det tog inte lång tid innan den Agila metodiken med LEAN som grundpelare implementeras i rask takt och helt plötsligt så börjar man släppa, visserligen små, nya versioner varannan vecka och möjligheten att ta igen en del av utvecklingskostnaden utan att behöva vänta tills det är “klart” och vi kanske träffade rätt?

Under detta paradigmskifte så fick många projektledare stryka på foten till fördel för utvecklande scrum-masters och LEAN applicerades på all den dokumentation som tidigare bara hade producerats för att “så skulle det minsann vara” – även om ingen läste den! Det fanns stora besparingar att göra helt klart.

Vi vill absolut inte tillbaka till det träsket där man i syfte att skapa business nylanserar en ny certifieringsprocess och standard där man i stället för LEAN i botten skriver att “det även fungerar för agil metodik”. Jag hävdar bestämt att det inte spelar någon som helst roll vilken utvecklingsmetodik man använder – så länge man följer den slaviskt så blir det rätt. Den utopin finns inte och då måste man ner på lägsta nivå och applicera “design for testability”.

Bra test är rätt test och det beror helt på hur kravställningen ser ut, vilken kvalitetsgrad man begär och hur mycket man förväntar sig att tjäna på produkten. I dag kostar konsumentelektronik avsevärt mycket mindre än det gjorde förut och jag kan lova att även om hårdvaran har blivit billigare så har inte mjukvaran blivit det, snarare tvärtom!

Då måste vi hitta metodiker som testar rätt redan från början och genom att bedriva design for testability och automatisera till “rätt” grad för att uppnå de kvalitetskrav vi ställer på våra produkter.
Att i denna miljö börja kräva testspecar, testrapporter och andra icke-drivande dokument finner jag absurd och kan inte se andra intressenter än de konsultbolag som hoppas kunna debitera mer timmar än nödvändigt då de nu även “måste” skriva en massa tidsödande dokumentation.

Arbeta agilt och anamma LEAN ordentligt, se till att ni har test automatiserat redan från designstadiet, och för guds skull se till att alla testresultat är tillgängliga i realtid via en databas och adekvat front-end så att även den mest skeptiska chefen kan få ett snapshot när han/hon vill. Att i sedvanlig ordning byta namn på gamla processer eller metodiker/modeller är lika produktivt (enligt min åsikt) som att byta namn på ett företag som gjort bort sig och med desperation försöker förnya sig… “-Lipstick on a pig” kanske klingar bekant? 😉

Min utopi är så mycket automatiserat som möjligt och dynamisk testverksamhet som drivs av “one team” tillsammans med aktiva stakeholders som skriver adekvata user-stories och kvalitetskrav baserade på förväntad return of invest. Den har jag nått!

Jag är inte beredd att tåga in till mina team med en bokhylla märkt “ISO29119” och ordern “- kolla här grabbar! det här är det bästa som hänt sedan skivat bröd och nu kommer allt att bli så mycket bättre…”

Detta är inte en sågning av någons eventuella arbete, det är en sågning av den något optimistiska synen på hur test skall bedrivas kontra den faktiska verkligheten. (nja, lite sågning är det nog allt ändå…)

Given, When, Then!

Author: politisktinkorrektpappa

Share This Post On

Submit a Comment

Your email address will not be published. Required fields are marked *

%d bloggers like this: