Efter traditionell test - en framtidsspaning

I början av 00-talet använde jag uteslutande Windows med Internet Explorer, samt ibland en iMac, för att testa webbapplikationer. För att täcka in webbläsare och operativsystem, var det i allt väsentligt det som behövdes. Ett par år senare dök Firefox upp och följdes snart av Chrome. Livet som testare blev mer komplicerat. Idag måste man som testare, förutom flera olika webbläsare och operativ på vanliga datorer, ta hänsyn till ett väldigt antal olika smartphones och surfplattor (ett år gammal data från maj 2012 visar på närmare 4000 olika kombinationer av Android-OS på olika hårdvaror!). I framtiden kommer detta att eskalera ytterligare. Vi kommer att ha betydligt fler surfbara enheter, t.ex. medialösningar, smarta TV-apparater, spelkonsoler och underhållningssystem i bilar. Våra webbapplikationer vill vi ha tillgängliga och användbara överallt. Som traditionell manuell testare blir det förstås omöjligt att testa mot alla dessa olika plattformar. En tuff utmaning för alla testorganisationer därute!

Samtidigt under dessa år har de agila utvecklingsmetoderna vuxit fram, vunnit allt mer mark och blivit allmänt vedertagna. Gemensamt för de agila metoderna är att man ser förändring och omprioritering som en normal del av utvecklingsprocessen, istället för särfall att hantera i en separat changeprocess. Traditionella teststrategier, med långa startsträckor och dedikerade testfaser fungerar dåligt i kombination med agil utveckling. Allt fler integrationer, ökad komplexitet och kortare utvecklingscykler med täta releaser är andra trender som kommer att förändra testområdet i grunden. Det blir allt svårare, att till rimliga resurser och rimlig tidplan, genomföra bra tester med traditionella testmetoder. Återigen en tuff utmaning!

Inom testvärlden har det börjat viskas om att ”traditionell test är död” och många teknikdrivna företag sätter sin tilltro till testautomatisering. Vad betyder det för testarskrået? Har traditionell test ett ”bäst före”-datum? Vad kommer då istället?

Generella tester med syfte att kontrollera uppfyllnad av funktionella krav, det som de flesta testare ägnar sig åt idag, kommer i framtiden att göras med olika tillvägagångssätt av flera olika personer på olika nivåer. Kravställare börjar exemplifiera med acceptanskriterier som utvecklarna kan luta sig mot. Utvecklarna kommer att behöva testa mera själva och även lösa en stor del av testarbetet med testautomatisering. Manuella tester kommer att göras av produktägare, kravställare, verksamhetsrepresentanter och initierade användare i alfa- och betareleaser. Utökad övervakning och loggning kommer då att vara en viktig del av felrapporteringen och insamling av fel sker till stor del automatiskt. Vanliga funktionella tester och vanlig felrapportering kommer inte att göras av heltidstestare. De personer som kallar sig ”testare”, och testar på heltid, är i framtiden betydligt mer specialiserade än idag. De ägnar sig åt olika områden där det krävs speciell erfarenhet och är ett extra stöd till utvecklingsteamen i kvalitetsarbetet. Det kan röra sig om kvalificerad testning av prestanda, säkerhet, komplexa integrationer och andra icke-funktionella områden. Det kan även röra sig om kontextdrivna utforskande tester som ett komplement till de mer generella funktionella testerna.

Den traditionella testledaren kommer att ha allt mindre betydelse i framtiden. När det inte finns några egentliga testfaser eller testresurser, finns det egentligen ingenting som testledare har att administrera. Framtidens testledare är mer av en testarkitekt som möjliggör effektiv testning genom att se över hantering av testmiljöer, testdata, testverktyg och teststrategi. Testarkitekten är också en mentor som utbildar och coachar inom test på alla nivåer. Det kan röra sig om att kvalitetssäkra krav, utvärdera risker, hjälpa utvecklare med TDD och continuous integration, stödja verksamhetsrepresentanter vid funktionella tester och kartlägga behov av testspecialister. Traditionell testledning kommer främst ha ett syfte vid omfattande systemintegrationstester med många inblandade system. I sådana sammanhang kommer nämligen de administrativa egenskaperna helt till sin rätt i arbetet att koordinera testdata, releaser och testfall.

Dreyfus - vad datorer inte kan

I ett samtal med min mentor kom vi in på ämnet lärande och hur man arbetar som coach utifrån den erfarenhetsnivå som adepten har. Min mentor tog upp Dreyfus ”What computers can’t do” som en bra modell att utgå ifrån. Dreyfus skrev sitt arbete början av 70-talet i en tid då AI var på frammarsch och många trodde att datorer snart skulle kunna ersätta det mänskliga medvetandet. Idag vet vi att vår hjärna är betydligt mer komplex än att kunna simuleras med datorkraft (trots att vi nu har tillgång till datorkraft som man på 70-talet bara kunde drömma). Det mänskliga lärandet är helt enkelt av en helt annan art än vad vi med datorer kan konstruera och efterlikna.

När jag läste in mig på Dreyfus arbete kunde jag inte undgå att dra paralleller till test. De tidiga erfarenhetsnivåerna, där man gärna följer regler, kan liknas vid att upprepa fördefinierade testfall. Senare nivåer kan liknas vid riskbaserad eller utforskande testning, där man instinktivt känner vad som är rätt och hur systemet borde agera. Eftersom datorer inte kan utrustas med intellekt, instinkt och systemtänkande så kan man ej heller med automatiserad testning hitta lika många fel som en skicklig manuell testare, även om datorer spöar en oerfaren testare blott genom mängden testfall som utförs med högre hastighet.

Jag vill tacka Lotta på Arbetsförmedlingen IT för beskrivningen av Dreyfus arbete nedan (som jag stulit och fritt översatt från hennes bok)…

Inom epistemologin (d.v.s. den del inom filosofin som handlar om mänskligt vetande) har boken ”What computers can’t do”, av Hubert L. Dreyfus 1972, spelat en stor roll. Dreyfus presenterar fem kunskapsnivåer som vanligtvis passeras när vi lär oss nya saker. Dessa fem nivåer är novis, nybörjare, kompetent, erfaren och expert.

Novisen känner bara till enkla förhållanden eller fakta och behöver tydliga regler för att avgöra vilka åtgärder och steg som bör tas. Dreyfus ger exemplet om någon som övningskör och avgör fordonets hastighet genom att titta på hastighetsmätaren. Övningsföraren använder sig sen av regler och kanske bedömer när det är dags att växla genom att hastighetsmätaren passerar 10 km/h. Att bara följa enkla regler kan ha sina nackdelar. Övningsföraren kommer förmodligen att få motorstopp om hen växlar för snabbt i ett motlut eller med tung last.

Förutom enkla fakta börjar nybörjaren att ha bättre förståelse om kontexten. Efter att ha upplevt tillräckligt många exempel så börjar nybörjaren att förstå sammanhang. Dreyfus liknar detta med bilföraren som lyssnar på motorljudet för att avgöra när det är dags att växla. Nybörjaren följer fortfarande givna regler men lär sig genom återkommande händelser och ökar sin erfarenhet. Eftersom både novisen och nybörjaren bara blint följer regler, känner de liten egen skuld vid ett misslyckande och upplever ofta att det är reglerna som är felaktigt utformade.

En kompetent person tar fram en plan och väljer en utgångspunkt för att kunna hantera den oftast överväldigande informationen som hen har lärt sig att identifiera. Planen, som härstammar ur egen erfarenhet eller instruktioner, hjälper den kompetente att skilja mellan viktiga och mindre viktiga aspekter och underlättar beslutsfattandet. Dreyfus menar att vid den här nivån följer bilföraren inte enbart regler. Bilföraren har ett mål i sikte och ifall den kompetente råkar i en nödsituation kanske hen bara fokuserar på att nå fram utan att bry sig om passagerarnas komfort eller trafiklagen. Dreyfus poängterar att det i de allra flesta fall är omöjligt att enbart förlita sig på regler. Inom varje område kan det uppstå flera olika situationer och det är omöjligt att täcka in dem alla. Den kompetente personen inser det och måste därför själv sin utgångspunkt. Man kan inte veta vad som är det rätta valet i förväg och det kan uppfattas som skrämmande. Den kompetende känner ett stort eget ansvar eftersom resultatet verkligen beror på deras val. Det finns en emotionell investering i varje val och människor blir naturligtvis skrämda, upplyfta, besvikna eller håglösa beroende på resultatet.

En erfaren person kan ofta känna sig uppfylld av sin egen skicklighet, d.v.s. befinner sig ”in the flow”. Hen ser vad som borde göras men behöver kanske lite tid för att bestämma sig hur det ska genomföras. Minnen av liknande erfarenheter i det förflutna leder till planer baserat på vad som har fungerat förut.

Experten ser inte enbart vad som borde göras utan vet intuitivt hur det ska genomföras. Experten har en utvecklad och genomarbetad förståelse och kan omedelbart genomföra vad som krävs. I normalfallet är det ofta tillräckligt och expertens arbete leder därför allra oftast till ett gott resultat.

Pratar på NFI Testforum

Jag har blivit inbjuden att prata på NFI Testforum den 16 april. Ni som deltar kommer att få lyssna på min presentation "från backlog till produktion på två veckor". Presentationen handlar om agil testning i ett Scrumteam med integrationstester och produktionssättning inom sprinten.

>>Väl mött!

Roller - ett arv från medeltidens skråväsende och den romerska armén

Den gamla romerska armén var bland de första att använda sig av olika roller som noga definierade ansvar och befogenheter . Den romerska armén hade en noggrant fastställd befälsordning som användes för att kommunicera och verkställa order samt att få alla legionärer att inrätta sig efter givna regler och påbud. Brott mot befälsordningen straffades mycket hårt t.ex. med stening eller genom att stoppas i en säck med ormar och kastas i en sjö. Den romerska armén var känd för sin effektivitet och disciplin. Systemet har därför kopierats av alla försvarsmakter sedan dess.

Genom historien har det också funnits gott om roller utanför de millitära sammanhangen. I medeltidens ståndssamhälle inrättades folket efter social status.  Det var sällan som människor umgicks över ståndsgränserna och att gifta sig utanför sitt stånd var inte ens att tänka på. Poängen var givetvis att kontrollera den stora massan människor, t.ex. torpare, statare, fattighjon och landstrykare, som var utan ståndstillhörighet och därmed inte hade något att göra med samhällets beskaffande. Skråväsendet från samma tid, där man för första gången delar in människor efter yrke, är en annan typ av rollkonstruktion som skapades för att minska rörligheten på arbetsmarknaden. Ifall alla fick bli skomakare skulle skopriset rasa och lönerna gå ner.

Det moderna rolltänkandet har sitt ursprung i industrialismens fabriker. Industrialismens grundtes är att genomtänkta processer och extrem specialisering ger möjlighet till massproduktion och jämn kvalité. Tillverkningsprocessen delas in i små steg och arbetsuppgifter tilldelas enligt olika roller. De hierarkiska konstruktionerna finns kvar för att styra de många arbetarna. De industriella metoderna fungerar utmärkt ifall processens alla steg är kända, kan planeras i förväg och kommer att se exakt likadana ut under överblickbar tid.

Den yrkesmässiga rollen är ett sentida arv från det rigida medeltida skråväsendet. Personer definierar sig t.ex. som arkitekter, testare eller utvecklare trots att gränsen mellan olika utvecklingsaktiviteter är synnerligen flytande. Inom företagsvärlden används fortfarande roller för att definiera ansvar och befogenheter.  Jag känner till en organisation vars systemutvecklingsmodell definierar nästan trettio roller, hur har man tänkt då? De flesta arbetsplatser skiljer sig lyckligtvis ifrån livet i den romerska armén och blind lydnad verkar snarare hämmande på ett företags utveckling. De flesta företag skiljer sig även ifrån de gamla bruksindustrierna. Din projektledare har troligen en ganska luddig föreställning om dina dagliga arbetsuppgifter och har inte en möjlighet att ge tydliga och genomtänkta direktiv i en föränderlig omgivning. Ifall man reflekterar över att roller historiskt används för att uppnå blind lydnad i krig, upprätthålla hierarkier och stävja dynamik på arbetsmarknaden, varför använder vi begreppet fortfarande idag?

Scrumövning med Lego Creationary

När vi ändå är på lekhumör så tänkte jag tipsa om Lego Creationary som en metod att demonstrera utveckling med Scrum. Creationary är en byggsats/spel från Lego Group och innehåller faktiskt allt du behöver för att simulera Scrum enligt förslaget nedan. En övning på två sprintar tar ungefär tio minuter.

Material: Lego Creationary, timer

Roller: 1 product owner (som också faciliterar övningen, 1-3 teammedlemmar

Övningen:

1. Product owner tar ett kort som utgör product backlog (varje kort har fyra user stories, eller modeller som ska byggas).
2. Product owner bestämmer prioritering genom att slå med tärningen...
• Bild (hus, bil, träd, skiftnyckel) = bilden med denna symbol är det högst prioriterade behovet.
• ? = product owner bestämmer själv prioriteringen.
• x2 = product owner väljer två bilder som prioriteras.
3. Sprintplanning: Teamet ställer frågor om detaljerna. Vad är det egentligen product owner behöver, hur ska modellen se ut? Teamet gör en sprintplanering. Vad ska vi bygga och hur, vad hinenr vi på två minuter?
4. Sprint: Teamet bygger utifrån sprintplanen. Sprinten pågår i två minuter.
5. Sprintdemo: Teamet demonstrerar modellen för kravsamordnaren som ger feedback.
6. Sprintretro: Kort retrospektiv i teamet. Hur gick det, vad kan vi förbättra till nästa sprint?

Kör minst två sprintar. Om modellen är färdigutvecklad efter första sprinten så väljer kravsamordnaden en ny modell med hjälp av tärningen.

Creationary, Lego Group (c)

Behöver du bra idéer?

Står ditt team inför någon sorts utmaning där det behövs kreativa och nyskapande lösningar? I denna situation har jag använt mig av kombinationen ”Six thinking hats” och ”Now, how, wow” med bra resultat. Hela övningen tar en halvdag så se till att deltagarna är avspända och närvarande.

”Six thinking hats” är en metod av Edward de Bono för att belysa en frågeställning från olika håll. Sex olika ståndpunkter representeras av sex olikfärgade hattar. Här är en övergripande förklaring men mer information kan enkelt googlas fram.

·         Fakta (vit hatt): fakta, neutral, objektiv, information
·         Känsla (röd hatt): intuition, magkänsla, känslor
·         Negativ (svart hatt): kritisk, analytisk, logiskt negativ
·         Positiv (gul hatt): optimistisk, solsken, logiskt positiv
·         Kreativ (grön hatt): idéer, möjligheter
·         Organisatör (blå hatt): agenda, process, överblick, beslut

Steg 1: Använd gruppen för att presentera och samla in tillgänglig relevant fakta (vit hatt)

Steg 2: Fundera kring känslor, obekräftade rykten, dolda agendor o.s.v. (röd hatt)

Steg 3: Tillåt gruppen att vara riktigt negativ, måla fan på väggen utifrån värsta tänkbara scenario (svart hatt)

Steg 4: Byt läge totalt och försökt nu att få gruppen att tänka så positivt som möjligt (gul hatt)

Steg 5: Utifrån alla insamlade fakta, känslor, positiva och negativa aspekter, släpp lös en brainstorm där gruppen utmanas dela med sig av sina mest kreativa och nyskapande idéer (grön hatt)

Steg 6: Den blå hatten används för att facilitera och styra mötet, växla mellan hattar och driva processen framåt. Den är din i egenskap av organisatör

Nästa steg i processen är att värdera de olika idéerna från sessionen med den gröna hatten. Det kan göras med en teknik som heter ”Now, how, wow”. Rita upp en kvadrant enligt grafiken nedan. Läs upp de insamlade idéerna och placera dem i rätt ruta med hjälp av gruppen.

Idéer som hamnar i första rutan är av typen ”lågt hängande frukt” de är lätta att införa, men kommer troligen inte att leda till exceptionella resultat. Idéer i tredje rutan är av typen ”framtida mål”, originella och nyskapande men svåra att genomföra i nuläget. Idéer i fjärde rutan är varken nyskapande eller lätta att genomföra. Dessa ägnar vi ingen mer uppmärksamhet åt.

Det vi är ute efter är idéer som kan placeras i den andra rutan. Här är originella idéer som dessutom är lätta att genomföra. Idéer med stort genomslag som kommer att göra verklig skillnad. Ifall gruppen får ihop ett par tre idéer i denna åtråvärda ruta, har det varit en mycket välspenderad aktivitet.

Testare och utvecklare, kärlek och hat...

Har du någon gång varit med om att du som testare har hittat en riktigt skön bugg? En riktig goding som varit tillfredställande komplicerad att rota fram men som är tillräckligt allvarlig för att sänka hela releasen. Låt oss anta att du har gjort det och, uppfylld av vetskapen av att ha gjort ett riktigt bra jobb, ivrigt registrerar den i ditt ärendehanteringssystem. Efter att ha lagt till komplett med steg-för-steg beskrivning, skärmdump, prioritet, testområde och sjuttio-elva andra saker enligt IEEE 829 känner du dig riktigt nöjd med dig själv. Det är då som du får ett surt ”rejected” tillbaka med enda kommentaren - ”works as designed”. I det läget ligger det nära till hands att förbanna den tröga utvecklaren och påbörja en rejäl bug advocacy. Följaktligen går du på ännu hårdare, återupprepar buggen tio gånger, beskriver i ännu mer detalj, gör en konsekvensanalys, en egen spontan felsökning och är nittio procent säker på vad som orsakar felet! Tio minuter efter återöppnat ärende kommer svaret - ”rejected, works for me”. Vad är det som händer? Det är ju helt absurt? Hatar utvecklare testare?

Det påstås ofta att utvecklare och testare bör hålla sig lite ifrån varandra. Hålla sig på sin egen kant av utvecklingsspektrat och inte beblanda sig alltför mycket. T.ex. står det i ISTQB att ”oberoende leder till bättre tester”. Andra vill dra detta ännu längre och ser till att placera utvecklare och testare i skilda rum, avdelningar, kontor eller kontinenter. Allt detta leder till färre kommunikationsmöjligheter, mindre sammarbete och sämre tester. Hur ska man kunna testa något om man inte vet hur det är uppbyggt och är tänkt att fungera? Ju mer information som finns tillgänglig, desto mer relevanta tester kan göras. Vi pratar mycket om vikten av testtäckning samt spårbarhet mellan krav och testfall. Är inte den tekniska systemlösningen en lika viktig komponent i teststrategin? Istället ser vi att testare och utvecklare hålls isär rent organisatoriskt. De placeras ofta i olika avdelningar under olika chefer. Formella processer stryper kommunikationen och tvingar folk att skriva ärenden i ärendehanteringssystem, istället för att prata med varandra. Jag anser att detta leder till sämre arbetsklimat, dåliga leveranser och dålig systemkvalité.

De flesta utvecklare tycker om att få sin kod testad. Seriösa utvecklare, som vill göra ett bra jobb, tycker det är jobbigt när deras misstag eller missuppfattningar får konsekvenser i produktion. De flesta utvecklare uppskattar en klåfingrig testare som utmanar lösningen med kreativa testuppslag. En testare som har en god uppfattning om kravbilden, verksamhetens förutsättningar och produktionssituationen. En testare som kliar på eventuella sårskorpor tills de blöder och tillsammans med utvecklaren kan bygga en bra lösning. Seriösa utvecklare ser det som en utmaning och en hjälp i arbetet. Testare kan vara extremt nyttig för utvecklaren. Testaren har ofta unik kunskap om hur systemlösningen används i praktiken och kan se hur en isolerad funktion passar ihop med systemet i övrigt. Testaren vet hur kraven ska tolkas, vad som krävs av lösningen i en produktionssituation, vilka som använder systemet och hur. Utvecklare kan ge testaren viktig kunskap om hur lösningen är byggd, vilka svagheter som finns och hur lösningen kan testas. Utvecklaren kan också göra jobbet lättare för testaren genom att bygga in testbarhet, hjälpa med testmiljöer, testverktyg och liknande.

Men ofta ser det ju inte ut så. Testaren får ofta sin leverans långt efter att utvecklaren är klar. Ett specifikt krav kanske inte testas förrän en månad efter funktionen har utvecklats. När fel uppstår ska alltså utvecklaren sätta sig in i och svara för fel som gjordes för en månad sedan. För att förvärra det hela så utgår testaren från en kravspecifikation som kanske är uppemot ett år gammal. Mycket är irrelevant, medan annat har ändrats under resans gång, viktiga saker kan ha tillkommit och det finns säkert ett antal viktiga krav som inte beskrivits alls. Inte konstigt att utvecklare har en tendens att bli irriterade när testare dyker upp med sina fynd. Lyckligtvis kan man ganska enkelt förändra den här situationen.

Sök upp de utvecklare som bygger koden som du ska testa. Ta med dig glass eller bullar och be att få sitta tillsammans med dem. Luncha med dem, lyssna och delta i deras diskussioner. Se till att bli upptagen i gruppen och börja arbeta tillsammans.

Om du är en teknisk testare så ta reda på vilka verktyg utvecklarna använder och lär dig använda dem. Ta reda på hur du kan komma igång och testa effektivt redan i början av utvecklingsperioden istället för att vänta på kompletta leveranser mot slutet. Skaffa en egen utvecklingsmiljö och ta emot de senaste kodversionerna. Använd utforskande testning för att komma igång snabbt utan testfall. Undersök möjligheter att effektivisera tester genom smarta tekniska lösningar och automatisering.

Om du är en verksamhetsorienterad testare, ta reda på så mycket som möjligt om verksamheten och den omgivning som systemlösningen ska verka i. Bli en expert på hur kraven ska tolkas, vilka outsagda krav som finns och vad verksamheten förväntar sig.