Errors, faults and failures = fel?

För några veckor sedan laddade jag ner ett par kandidat-uppsatser som alla handlade på ett sätt eller annat om test. Det var titlar som Model Based Testing for Non-Functional Requirements, QA Activities in Agile, Investigating Exploratory Testing in Industrial Practice, etc. Alla väldigt fascinerande (antar jag efter vad titlarna och abstrakten säger) men den som fångade min blick var Testarbetets svåra val. Främst för när jag läste abstrakten slogs jag av denna smocka till mening:

”Nackdelen med test inom systemutvecklingsorganisationen är att test tar mycket tid.”

Vilket direkt reser nackhåren. Visar sig sedan när man läser abstraktet samt resten av uppsatsen att den tolkning jag direkt hoppade till inte var den som menats med meningen. Dra mening ut ur kontext, etc. Samtidigt ”gärna hitta fel”:testare::”gillar laga mat”:kock. Iallafall. Det i uppsatsen som fick mig att börja tänka är när de börjar prata om errors, faults och failures och mer specifikt när de börjar diskutera dessa med sina intervjupersoner.

För att färska upp minnet är error, faults och failures helt enkelt olika sätt att kategorisera något som inte står rätt till i test-objektet. Om vi säger testobjektet är en applikation så  genom bristfällig kod uppstår en error som ger ett fault i en funktion som sedan skapar en failure i applikationen.

De tar upp dessa definitioner redan i sin ordlista, där jag fnyser initialt åt onödan i att definiera dessa termer. När jag strosar nedåt i uppsatsen ser jag att denna mentala fnysning har repeterats av en av intervjupersonerna:

”Under alla mina år inom test (drygt 10) har jag aldrig hört någon prata om Error, Faults och Failures annat än på utbildningar…”

”Precis!” tänker jag. Varför behöver man ha specifika termer när alla vet vad fel innebär? Men. Är det så lätt? Direkt kopplas min förra testledares röst på:

”Vem är alla? Delar dem verkligen din syn? Hur vet du det?”

Om vi säger att alla inblandade i testprocessen börjar använda sig av dessa termer. Att alla ”testare” börjar använda sig av samma termer. Om alla test-specialister börjar säga ”jag tror jag har hittat en error” till utvecklaren. Borde detta inte leda till en bättre kommunikation i utvecklings-teamet?

Jo jag vet, sjukt retoriskt. Men då kommer följdfrågan, om detta är självklart, varför används inte dessa och/eller liknande termer?

Vad begreppen Kvalitet och Test betyder för oss

Jag får ibland frågor som "Vad är kvalitet för dig?" eller stöter på en mängd olika tolkningar kring syftet med att testa. Jag tänkte här försöka reda ut begreppen för vad begreppen test och kvalitet betyder för oss på Sogeti. 

Enligt TMap är definitionen av test:

 a process that provides insight into, and advice on, quality and the related risks.

Jag tar mig här på bloggen friheten att komplettera denna definiton med min personliga tolkning. Översatt blir definitionen; Test är en process som erbjuder inblick och råd kring kvalitet och kvalitetsrelaterade risker. En testorganisation skall således enligt min enkla mening erbjuda information kring testobjektets kvalitet. Effekten av vår slutprodukt ger utvecklingsorganisationen mervärde i form av kunskap om testobjektet som utgör en tillförlitlig beslutsgrund. En testorganisation ökar därför inte kvaliteten automatiskt för den kan inte påverka testobjektets kvalitet direkt, utan endast ge råd! Det är bara de som utvecklar testobjektet som kan bygga med kvalitet; jämför husentreprenör och besiktningsman.

 

Vad är då kvalitet?

 TMap hänvisar här till en känd ISO-standard: Quality is the totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs.

Vi pratar här alltså på ren svenska om att kvalitet är den samlade bild av egenskaper för en produkt som vilar på dess förmåga att tillgodose fastställda, eller antydda behov. Det handlar alltså inte om att uppfylla det som står i kravspecar, utan att erbjuda en produkt som uppfyller användarens faktiska behov. ISO delar sedan upp kvalitet i egenskaper listade nedan i sin standard 9126-1, som TMap hänvisar till:

• Functionality (Funktionell)
• Reliability (Tillförlitlig)
• Usability (Användarvänlig)
• Efficiency (Effektiv)
• Maintainability (Underhållbar)
• Portability (Portabel)

 Dessa sex kvalitetsegenskaper är sedan uppdelade i undergrupper, läs mer här om själva ISO-standarden. 

Tillåt  mig även tillägga att TMap även har en egenutvecklad kvalitetsmodell som utgått från ISO 9126, men jag föredrar personligen att utgå från ISOs standard när jag är ute och pratar med kunder.

Som grund i denna analys har jag använt den gråa TMap-boken, sida 36 samt 495-

 

Sogetis forskningssamarbete inom verifiering och validering

Sogeti har de senaste åren deltagit aktivt i SWELL-nätverket  (Swedish Verification & Validation Excellence, doktorandskolesamarbete mellan de största universiteten i Sverige) där forskarvärlden och industrin kan mötas. Genom kontakter skapade i nätverket har vi fått stora möjligheter att utbyta erfarenheter med forskare samt andra industrirepresentanter. Bland annat har vi fått den stora äran att agera industrihandledare åt ett examensarbete inom ämnet "Investigating Exploratory Testing in Industrial Practice - A Case Study". 

Just nu är jag personligen mycket intresserad av forskningen kring hur projektmedlemmarnas synsätt, attityder och personlighet kan påverka utvecklingen av mjukvara. Detta kan man även ana i mitt förra inlägg kring "Processtankar - Valet 2010". Här är en artikel som publicerades tidigare i år som visar på att individer som arbetar med utveckling besitter mer liknande personligheter än allmänheten. Det kanske inte är så konstigt, men jag lägger detta till min samling av argument till varför det är uppåt väggarna och direkt farligt att skylla på att "användarna inte förstår" eller "beställaren har beställt en märklig lösning" och så vidare när problem uppstår i eller utanför utvecklingsteamet. 

Jag har inlett diskussioner med forskare på Chalmers om möjligheten att få göra vidare forskning på mig och mina kollegor här på Sogeti, det hade varit spännande att se hur om det går att hitta några forskningsfrågeställningar som förefaller intressanta både för forskarna och oss själva!

Talare på SAST Öresund möte - Ett interaktivt föredrag

Jag fick den stora äran att tala på gårdagens SAST Öresund möte i Malmö och ämnet var "Min personliga utforskning av test" där jag tänkte prata om min resa och min karriär inom testprofessionen. När dagen började närma sig kände jag mer och mer hur ogärna jag ville skapa en traditionell powerpoint-föreläsning om mig själv. Kände instinktivt att jag var på väg att producera ett riktigt sömnpiller.  

Då slog det mig. Jag ber publiken se mig som deras testobjekt. De kloka testarna framför mig fick således dra ut den information de ville ha av mig, exakt som när vi som testare exekverar tester på våra system fick publiken ställa frågor till mig. De båda aktiviteterna har identiska syften, att extrahera samt erhålla värdefull information. 

Jag hade för säkerhets skull förberett ett antal fördefinierade "testfall" i form av samtalsämnen som åhörarna kunde börja ställa frågor inom utifall diskussionen hade problem att komma igång, men dessa passionerade åhörare satte genast fart kring ämnet "Kvalitet" för att sedan utforskas vidare via ämnen såsom till exempel "Automatiserade tester" och "Mina största kärriärmisstag", men även negativa testfall i form av frågeställningar jag inte fördefinierat såsom graden av struktur inom utforskande test men även ämnen som teknisk skuld samt effektiv kommunikation inom distribuerade agila utvecklingsteam berördes. 

På detta vis skapade vi tillsammans ett interaktivt föredrag som i alla fall jag uppskattade enormt eftersom jag aldrig tappade kontakten med åhörarna. Jag hoppas alla närvarande fick någon värdefull liten tanke eller tips med sig hem, tiden vi hade på oss kändes på tok för kort och jag hade med lätthet kunnat fortsätta diskutera dessa ämnen som ligger mig så varmt om hjärtat i ett par timmar till. Men underbart är gott och alla närvarande är självklart oerhört välkomna att kontakta mig även nu efteråt för att fortsätta diskussionerna. 

Om någon som läser detta är intresserad av att sätta upp en liknande aktivitet på ert företag, hör gärna av er till mig: fredrik.scheja@sogeti.se

Varför testar vi?

Har ni som jobbar med test eller jobbat med testare ställt er den frågan någon gång? Har ni ett entydigt svar? 

Sedan barnsben testar vi ständigt, vi slutar aldrig. Från min egna fascination för att dra i sladdar till barnen som använde vårt staket som fyrverkeriuppskjutsningsramp förra nyåret. Allt detta är test, i syfte att erhålla information (och till viss del glädje)! I mitt fall fick jag reda på att sladden till videokameran skulle jag inte dra i (den gick till slut sönder då jag inte tog lärdom av informationen pappa presenterade). Grannbarnen var dock smartare än jag då de slutade att avfyra fyrverkerier från vårt nymålade staket när jag bad dem det. 

Enligt min mening testar vi för att utvinna värdefull information om testobjektet.

Denna information kan sedan adresseras till den som har användning för informationen. Hittar vi ett fel paketerar vi den informationen i en felrapport till utvecklaren, men om jag ser en betydande projektrisk adresserar jag den informationen till projektledaren eller den kvalitetsansvarige. Utmaningen blir således att effektivisera frukten (informationsnyttan) av vår investering (vår tid). 

Ofta  ställer jag frågor likt dessa till mig själv:

• På vilket sätt får det jag håller på med oss att erhålla mer information om testobjektet?
• För vem är denna information viktig?
• Hur kan jag utvinna maximal mängd med information per utfört test?
• Vad kan vi ha missat? Vilken viktig informationspusselbit kan vara högre prioriterad  att gräva i än den vi jobbar på just nu?

Jag anser det viktigt att alltid ha detta i bakhuvudet eftersom  jag annars inte har  en chans att få grepp om det jag gör i stunden faktiskt i slutändan har en chans att bära frukt.

Jag upplever det skrämmande ofta att vi arbetar utan att veta syftet med vårt arbete. Det är nämligen lätt för en ingenjörshjärna att fastna vid det vackra i att bygga upp fantastiskt välskrivna testplaner, testfall, automatiserade testscript och avancerade testverktyg, vilket alla är bra verktyg och hjälpmedel. Men det är just det - dessa är hjälpmedel, hjälpmedel som förenklar för oss att få fram värdefull information kring vårt  testobjekt. 

Det är den värdefulla informationen som vi som testorganisation kommer att bli tackade och ihågkomna för, inte de snygga verktygen.

Testverktyg - my precious och samtidigt min fotboja

Testverktyg är något jag har en hatkärlek till. Det är ofta jag märker att verktygen styr människorna som arbetar från att tänka fritt och således sänker människors effektivitet istället för att öka densamma. Som ett tecken på detta sitter jag just nu som testansvarig inom en distribuerad utvecklingsgrupp på drygt tio man. Inga testprocesser är satta sedan tidigare, jag har det fulla ansvaret och samtidigt den fulla friheten. Inga testverktyg används förutom samma opensource ärendehanteringssystem Redmine som resten av projektteamet använder. Detta system använder vi initialt som placeholder för vår testdesign, våra testloggar, våra testresultat och defekter. Verktyget erbjuder dessutom möjligheten att ha spårbarhet mellan alla dessa artefakter, men även till krav och ända ner i källkoden (!). 

Trots bristen på avancerade testverktyg och endast en skissartad testprocess så här i början på testarbetet utbrast min testarkollega Martin igår när vi diskuterade ett defektprocessrelaterat dilemma:

 -"Men detta är ju som att testa, fast på riktigt". 

Detta tar jag som ett gott betyg kring att vi är på väg i rätt riktning. Vi kommer lägga till ett testverktyg först när vi ser att vi verkligen behöver det, och det tror jag är nyckeln till att lyckas vid uppbyggandet av en alldeles ny utvecklingsorganisation. Börja enkelt och utveckla processen och verktygsfloran vid behov. När jag studerat arbetsprocesser är en av mina slutsatser att det är viktigt att först och främst undersöka vad vi verkligen försöker åstadkomma, vilket behov vi försöker tillfredsställa. Sedan försöker vi hitta ett sätt att jobba, en process för att tillfredsställa detta behov så effektivt som möjligt, och till sist lägga till verktyg som kan stötta processen. 

Ett alternativ till att försöka leta efter Det verktyget som ska klara av alla situationer, alla arbetsprocesser redan från början, är att vara med i utvecklingen av ett verktyg och kunna påverka dess utformning. En av Sogetis partner ReQtest utvecklar ett webbaserat testmanagementverktyg som jag tycker om, men har svårt att använda i en del av de fundamentalt olika situationer jag hamnar i som testkonsult. Därför blev jag glad när jag i veckan pratade med en representant för ReQtest om möjligheten för mig att kunna få vara med och påverka vidareutvecklingen av ReQtest. Det är en möjlighet jag ser fram emot!

 

Totalt oanvändbart

Ibland, tack och lov inte alltför ofta, stöter jag på e-lösningar som får mig att fundera på att byta yrke. I min enfald trodde jag att de flesta ”hål-i-huvet” lösningar var historia och att alla levde i den upplysta värld som förstår att användaren är kung. Så fel man kan ha!

Efter att häromdagen bokat en resa, så tänkte jag att jag skulle beställa lite gott och nyttigt att förtära under resan. Så glad i hågen loggade jag intet ont anande in på den e-handelsplats där jag förväntades beställa. Vad jag inte visste var att den som utvecklat tjänsten kom från den varma plats byprästen förr i tiden hotade församlingsmedlemmar med. Logga in gick ju bra men det var sen problemen började. Efter fem minuter började datorn kännas som sirap i frysskåpet. Det gick så fruktansvärt segt att mitt stackars operativ skickade upp en varning att ”nu var det minsann ett skript som håller på att ta död på datorn”. Bokstavligen.

 

Men skam den som ger sig, så jag klickade glatt vidare för att fyll min varukorg med fast och flytande. Det är ju ganska tröttande att beställa så jag tänkte att nu kan jag väl fortsätta i morgon. Så jag loggade ut och stängde min webbläsare. Så gör man ju överallt. Trodde jag. När jag en stund senare checkade min mail såg jag att jag fått ett meddelande från AirShopen som de kallade sig. –Tack för din beställning, stod det.

Nu blev jag lite fundersam. På webbsidan så stod det klart och tydlig att beställningen skulle göras i 3 steg: 1. Fyll varukorgen 2. Bekräfta 3. Skicka ordern
Så uppenbarligen hade jag väl klantat till det och skickat iväg ordern av misstag. Attans! Jag ringer kundtjänst:
Stefan: Jag fick en orderbekräftelse från er webbshop och jag tror det blev något fel.
Kundtjänst: Ja?
Stefan: Jag plockade i saker i varukorgen men skickade aldrig in nån beställning.
Kundtjänst: Och?
Stefan: Ja, det borde väl inte gått iväg en orderbekräftelse?
Kundtjänst: Stängde du ner webbläsaren?
Stefan: Ja, det är klart jag stängde webbläsaren.
Kundtjänst: Men då gick det ju så klart iväg i order.
Stefan: Men är inte det lite korkat!
Kundtjänst: Det är ju så vårt system fungerar. Det är bara att gå in och lägga en ny order så är det den som gäller i stället.
Stefan: Är inte det lite krångligt, både för mig och för er?
Kundtjänst: Nej, det är så vårt system fungerar.
Stefan: Så om jag går in på en bilsajt och plockar ihop min drömbil så läggs en order samtidigt? Är det så ni menar?

Den sista meningen är vad jag borde sagt men tyvärr så kommer man inte på det uppenbara när det behövs. Hur som helst, jag har faktiskt fortfarande en order lagd, men har varit inne och ändrat i den flera gånger. Mest som ett experiment för att se vad jag får i slutändan. Jag ser fram mot det. Blir nog en av höjdpunkterna på resan.

En extra knorr på orderhanteringen fick jag tre dagar senare när min fru ringde mig på jobbet.
-Stefan, jag har fått ett konstigt brev. Det verkar vara en order från Airshopen.
Det visade sig att hon gjort på samma sätt som mig; gått in och plockat i lite varor. Det var så att alla resenärer kunde logga in var för sig. Skillnaden var bara att hon inte skrivit in nån mailadress. Så då kom det ju givetvis en orderbekräftlese per brev.

Jag bör tillägga att resebokningen på Ving fungerade alldeles utmärkt. De hade helt uppenbart anställt ett annat projektteam.

Nu tänker jag fortsätta mitt korståg i sann Vincent Flandersanda ( webpages that sucks) och bekämpa dålig användbarhet. See you all.

The best of bokmässan

Som sann bokmal åkte jag ner till bokmässan i Göteborg i helgen och förkovrade mig i allt från signering med Ernst till tassa förbi Horace Engdahl. Bland deckare och kokböcker hittade jag faktiskt årets bästa [jobbrelaterade] litteraturinköp! Möteskokboken 1 och 2. Spontant hoppade jag in i deras monter och efter att direkt ha fastnat för det otal workshop-tips och möteslekar som finns i dessa böcker så investerade jag. För det är en investering. En investering i att gå från good to great i mötes- och workshopledning.

Tillräcklig regressionstest på 3 timmar!?

En ständig utmaning i Scrum är regressions testning. Hur i *pip* ska man hinna göra en full regressionstestning av hela systemet varje sprint om man inte byggt upp en gedigen bas av automatiserade tester som är heltäckande?

Varje sprint växer systemet, omfattningen av regressionstestet växer för varje vecka som går - men Sprintens längd gör det inte. Om man gjorde ett försöka att hinna med en komplett manuell regressionstestning varje sprint skulle man väldigt snabbt springa in i väggen och explodera i ett moln av stress.

På SAST Q3 presenterade Fredrik Carlemalm från NCP (No Common People) kanske en lösning på problemet utan att han själv visste om det…

I cirka 40 minuter berättade han inför en högst skeptisk publik hur man genom att slumpmässigt göra stickprovstester kan säga något om systemet i helhet. Det kändes som om jag var den enda därinne som var helt fascinerad över vilka möjligheter angreppssättet öppnade om man skulle kombinera detta med Agil utveckling.

 

AQL – Accepted Quality Level

I statistisk testning pratar man om något som heter AQL – Accepted Quality Level, vilket syftar på hur felfri en produkt ska vara för att vi ska betrakta den som ok och levererbar. Det går aldrig att kontrollera att ett system är 100% fritt från fel eller buggar (såtillvida vi inte har oändligt med tid och systemet inte har några som helst yttre beroenden), så en rimligare AQL är kanske 99,75%...

Med metoden Fredrik beskriver kan man genom att enbart testa en väldigt liten delmängd (som är helt slumpmässigt utvald) med stor säkerhet säga huruvida systemet som helhet lever upp till satt AQL eller inte. 

Har vi en bas med mellan 3200 till 10000 testpunkter (dvs. inte hela testfall, ett testfall består oftast flera steg eller testpunkter) och vill veta om systemet uppnår AQL 99,75% räcker det med att mellan 125 + 125 av dessa körs. Hittas inga fel, eller för många (dvs 2 eller fler), bland de första 125 behöver man inte köra de sista 125.

 

En bråkdel beskriver helheten

Helt plötsligt kan vi veta något om systemet i sin helhet genom att endast köra en bråkdel av testfallen. Testar man Exploratory i sin sprint betyder det att man inte bygger upp en testbas att utgå ifrån i sin statistiska testning. Då får man istället falla tillbaka på att slumpmässigt välja ut kravdetaljer från sin aggregerade trave User Stories att testa emot.

Metoden är väl beprövad och tillämpas hela tiden i tillverkning för att genom stickprov kunna säga något om kvaliteten på batchen i helhet. Vill du själv prova på några räkneexempel och läsa mer om teorin bakom, gå till: http://www.sqconline.com/mil-std-105.html. (Obs. Man tillåts endast göra 5 räkneövningar gratis.)

Jag kommer att fördjupa mig rejält i detta och återkommer när jag har vunnit större insikter och förstått mekaniken och statistiken bakom bättre.

Matematikpedagogikens baksida

Läste en intressant artikel i Sydsvenskan under semestern:

http://sydsvenskan.se/lund/article537020/Matematik-inte-bara-siffror.html 

Den handlar om sättet vi hart lärt oss att se på skolämnet matematik och hur vi lärt oss detta ämne i skolan under många år. Matematik handlar om så mycket mer än att lära sig multiplikationstabellen och pythagoras sats utantill. Men det är inte det som skolan belyst de senaste generationerna. Vi är vana vid att ha facit i slutet av boken som vi kunnat tjuvkika på under vår studietid. (Själv myntade jag uttrycket "facitbaserad inlärning" under högskoletiden) Men när vi sedan kommer ut i arbetslivet och inga facit finns tillhanda, hur gör vi då? Klamrar vi oss fast vid bräckliga, otillräckliga uppgifter och anser de vara facit eller har vi insett att det inte finns något rätt och fel utan att resan är full av mer eller mindre välunderbyggda beslut?