Det var en gång...

Flera decennier inom QA ger en del dråpliga och insiktsgivande berättelser att förmedla. För min egen skull har jag börjat besrkiva en del av dessa här.

Detta är en av dem.

Styra in kvalitet med statistik

I mitten på 90-talet arbetade jag i mekanisk verkstad. Jag var ganska nyexaminerad maskiningenjör och hade fått ett ingenjörs-trainee-jobb på ett företag som hette Torsten Ullman AB och som tillverkade detaljer till fordonsindustrin.

Utvecklingen skedde enligt Kanban och lagerlöst JIT (Just in time) och dessa erfarenheter har givit insikter kring QA inom mjukvaruvärlden som har hjälpt mig genom resten av karriären, när jag väl tagit mig tid att reflektera kring dessa.

I trainee-jobbet ingick att rulla in fulla häckar (alltså ställningar eller stora lådor fulla med producerade saker) till mätrummet och kontrollmäta ett visst antal exemplar av dessa för att med statistikens hjälp nå konfidensintervall att alla detaljer låg inom toleransnivåerna.

Verktygen bestod mestadels av papper, penna, mikrometer och skjutmått. I dessa tester fick jag en god inblick i det här med konfidensintervall och statistiska tester.
Det är fascinerande att man med relativt få stickprovstester kan få en ganska god uppfattning om den egentliga kvaliteten.

En annan fiffig grej var att vi genom dessa tester kunde säga till när en maskins skärstål började närma sig toleransgränsen så att det var läge att justera svarvstål, borrjigg eller liknande från slitning eller annat och alltså aktivt styra in kvalitet.

Häri ligger en skillnad mellan industriell produktion och IT: IT, som jag mest har jobbat i det i vart fall, handlar om att skapa eller ändra i kod (eller köpa in system). Det blir en engångsgrej, och arbetet måste oftast nötas tills det verkar fungera så att det kan skickas vidare i flödet till mer formell avtestning. I denna analogi påminner utvecklingsteamets arbete således mer om konstruktionsavdelningens arbete där de sitter och skapar ritningar och prototyper. Det är ju sedan kompilatorer och byggverktyg som sedan motsvarar själva produktionsanläggningen som skapar systemet åt oss.

Det är ju egentligen väldigt lyxigt. Vi kan fila vidare på våra prototyper (kompilera vår kod och köra våra tester) tills vi är nöjda och då är produktionen mer eller mindre redan klar.

Det är nog dock också därför som estimat är så svåra. När vi skapar IT-system är det ju inte produktionsarbete utan konstruktionsarbete vilket är mycket svårare att estimera.

Det kan eventuellt också förklara min förvåning när jag märkte hur mycket som skiljer mjukvaru-Kanban från den industri-Kanban jag hade blivit upplärd i.

Insikterna kring statistiskt testning och konfidensintervall har jag senare återanvänt t.ex. när jag jobbade på ett retailföretag vid snabba stickprovsbaserade acceptanstester av inlevererade stora system från en indisk leverantör, eller i datavariationstester med enorm kombinatorik. Liknande tankar kan ju nämligen även appliceras på pair-wise-testing också för att få hygglig täckning på systematiska grunder.

Lärdom

Att jobba inom IT är faktiskt väldigt lyxigt när man tänker på det.

Det är fränt att det går att få en överraskande god uppfattning av kvalitet med stickprov.