October 22^nd to 24^th 2013 I attended the User Conference on Advanced Automated Testing (UCAAT) in Paris. The conference was organized by the European Telecommunications Standards Institute (ETSI), Smartesting and ALL4TEC. This year’s event was dedicated to automated testing in general which was a change from last year’s Model Based Testing (MBT)-only conference. But still the headline “MBT in the testing ecosystem” gave an MBT focus to the arrangement. Below are some of my impressions of this conference.

The overall experience

The track I chose to follow during the tutorial day kicked off with an MBT for beginners session by Eddie Jaffuel. The presentation also contained a live demo which explained and gave an overview of the MBT process. Due to its mainly graphical nature MBT seem well suited for live demos. A demo was also done by Kristian Karl and Peng Ge from Spotify. We got a view of how the agile development cycle works and is organized at Spotify. For example “testers” write models explaining what should be tested, and “java developers” fills in the exact syntax of the model in order to turn the model into something executable.

There was a lot of effort put into the conferring aspect of the conference from the organizers side. We had a fair amount of time to confer with each other during the breaks and the concept of “poster sessions” was used. At these poster sessions several speakers each presented their own poster on the wall to people who stopped by and listened. Here discussions and conferring was happening everywhere. The venue MAS felt a bit small at first during the coffee breaks considering the number of people. But it turned out to be a good thing that people were standing shoulder to shoulder since it made talking to new people easier and more relaxed.

Anne Kramer at sepp.med who was one of the poster session speakers handed out a survey to everyone at the conference. The survey was called “Locate yourself in the MBT universe” and was aiming at a unified MBT taxonomy. I found the survey questionnaire very interesting in itself since it helped me to put words on what I am actually doing with MBT. Also some other speakers touched on the importance of a common taxonomy. The term “test plan” was mentioned at one point as an example of something that has more than one meaning.

Final words

Many of the speakers gave the same message that with an MBT approach bugs are found earlier in the process and it therefore drives the quality upstream, as Chan Chaiyochlarb from Microsoft put it. The word “pragmatic” was heard a couple of times during the conference, and there seem to be a general understanding that MBT alone does not solve all problems, i.e. it is not a “silver bullet”. In general I experienced a healthy “do what works for you”-attitude during the event.

Årets tema var ”Questioning Testing” – en uppmaning till oss att fundera på vilken roll test har och hur vi kan tillföra värde. En stor del av presentationerna handlade om attityder och kommunikation mellan människor.

Konferensen inleddes traditionellt med en och en halv dags tutorials. Till svenska översätts detta till handledningar. Det innebär att man dyker djupare ner i ett ämne och oftast innebär det en hel del övningar på egen hand eller grupp.

I år fick jag själv delta med en hel dag om testdesign med stort fokus på visuell problemlösning. Kursmaterialet innehåller ett white paper på engelska som finns att läsa på www.ryber.se, för den som vill dyka djupare ner i ämnet och öva på egen hand.

Det brukar ju sägas att egenutveckling börjar där komfortzonen slutar och att hålla kurs för sextio pålästa testare på engelska är ett rejält kliv ut ur sagda zon.

Efter avslutad första dag hamnade vi i himlen. Alla talare bjöds nämligen på gratis dryck i skybaren Heaven 23. Eftersom tilltugget bestod av extrasaltad skinka, oliver och lagrad hårdost så gick det åt en hel del dryck för att skölja ner saltbomberna.

Som värdig avslutning på dagen hamnade jag på Test Out West med release av boken FelFelFel vilket ganska väl beskriver statusen för denna betaversion av det skrivna materialet. Boken som till stor del bygger på blogginlägg innehåller intressant läsning från den perfekta LCHF-äppelkakan, tips om testautomatisering, wicked problems och en hyllning till V-modellen. Enligt uppgift kommer den att finnas till försäljning i en felfri version inom kort.

Tisdagsmorgonen spenderade jag på Ian Rowlands föreläsning Thinking Outside The Locks. IT står I hans fall för Impossible Thinking vilket lite fritt kan översättas med att fundera på hur vi låser in oss i gamla hjulspår istället för att tänka mer fritt. Även om en hel del av teknikerna är rätt välkända vid det här laget var det nyttigt att få en sammanfattande genomgång. Inte minst var det en strålande uppvisning av trollkonster, skämt, angrepp på Margaret Thatcher och kluriga övningar. För den som vill ha en underhållande och nyttig bok så rekommenderas Edward De Bonos: Lateral Thinking.
Den sammanfattar stora delar av vad som togs upp. Ian avslutade med att äta upp en glödlampa men påpekade att detta inte räknades som en av de tekniker vi skulle prova att göra hemma.

Första keynoten hölls av Laurent Bossavit från Agila institutet i Frankrike.

Efter att lyssnat på hans mycket grundliga genomgång av hur det helt saknas tillförlitliga siffror på hur mycket det kostar att hitta och rätta defekter beroende på när man hittar dem uppmanade han oss till att inte låta oss bli överkörda av bullies med siffror som vapen. Det visade sig vid hans närmare efterforskningar att de källor som nämndes var direkta kopior av äldre mätningar från 1980-talet som redan då var tveksamma att dra slutsatser från.

Det är skillnad på att säga att vissa typer av fel kan bli väldigt kostsamma om de hittas väldigt sent och att hävda att det är en generell slutsats. De mätningar han hittade gav inga som helst sådana slutsatser – snarare var kostnaden i genomsnitt ungefär lika hög oberoende av var man identifierade och åtgärdade felen. För den som vill läsa mer finns en hel bok med granskningar av i många fall helt ogrundade påståenden.

Många deltagare följde Laurents råd och twittrade om Lephrechauns i samband med torsdagens presentation om vad som motiverar en testare utifrån en utvärdering av vad som ansågs vara tveksam data.

Tjusningen med en konferens är att det finns så mycket att välja mellan.

Det fanns ett utomordentligt roligt testlabb där alla inbjöds att lösa kluriga problem med spel, färgstyrda robotar och inte minst James Lyndsays hemmabyggda flashapplikationer. Dessutom träffade jag så klart en del gamla och många nya vänner som bjöd in till intressanta diskussioner om systemutveckling, problemlösning, öl och andra väsentligheter. Som vanligt var det en del riktigt bra presentationer och en del riktiga bottennapp. En föreläsare uppmanade till utökat samarbete med övriga yrkesroller samtidigt som han aktivt stödjer certifiering och standarder som tas fram utan någon som helst konsensus från utvecklare, kravfolk, arkitekter eller projektledare.

Det är väl mer och mer tydligt att vi testare måste vara en del av ett team som jobbar ihop på riktigt och inte bara rapporterar tid på samma projekt.

Tisdagskvällen var en höjdpunkt då jag hamnade i sällskap med en norrman, två spanjorer och en tysk.

Tillsammans utforskade vi en italiensk restaurang och Tre små rum, en pub för sanna öl älskare. Vi provade på Westvleteren 12 – av många rankad som världens bästa öl. Fem små glas och en flaska för 295 spänn var rätt lagom. Andra upplevelser var julölen Rudolf och Arrogant bastard som på etiketten hävdar att vi inte är värdiga att dricka den. Åter till Heaven23 för diskussioner och klurigheter till vi blev utslängda en timme efter att baren hade stängt.

Jerry Weinberg – något av en husgud för agila utvecklare och de kontextdrivna testarna förärades Testing Excellence Award och Zeger van Hese – förra årets EuroSTAR ordförande fick priset för bästa paper. Mina egna favoriter av Jerrys böcker är Exploring Requirements, Are your lights on och Secrets of Consulting.

Sammanfattningsvis var det en givande konferens som gav nya idéer, förstärkte mina egna tankar och bjöd på bra underhållning. Nästa år bär det av till Dublin så det är bara att börja fundera på vad DU ska skicka in för bidrag.

Torbjörn Ryber – Visuell problemlösare med lång erfarenhet inom effektkartläggning och test. Författare, bloggare och tyckare. Ordförande SAST Örebro. Gillar att cykla i skogen, vandra i fjällen och åka skidor. Har senaste veckan gjort fem beställningar på Adlibris.

Som en del i vår strategi att leverera affärsnytta till våra kunder driver AddQ ett antal utvecklingsforum inom bolaget. Utöver att effekten av dem innebär en vinst för våra kunder bedrivs de också utifrån ett av våra ledord inom vår värdegrund – Ständigt lärande. Andra aspekter för dessa aktiviteter handlar om engagemang hos medarbetarna, spridning av kompetens inom företaget samt inte minst ett trevligt tillfälle att träffas! Merparten av oss sitter ju trots allt ute hos kunderna och man behöver ibland träffas för att umgås under mer avslappnade former.

Förra veckan träffades vi inom Automationsforumet för att lära oss mer om ett verktyg som ingår i en kategori av testverktyg som baseras på bildigenkänning. Det finns ett antal leverantörer inom denna kategori: Sikuli, EggPlant, T-Plan Robot, Ranorex, etc.

Vi tittade närmare på ett verktyg från en svensk aktör – Jautomate; med representant från verktygsutvecklaren, Swiftling/JAutomate, samt deras supportrepresentant i Stockholm, Nohau. De gav oss en presentation av verktyget och beskrev dess styrkor och i viss mån svagheter samt gav exempel på framtagna skript. Verktyget är skrivet i Java och kan köras på alla miljöer som stödjer Java från Oracle.

Typtillämpningen för verktyget är automation av verksamhetsnära GUI-funktionalitet. Vad innebär detta? Jo, att allt som är synligt för användaren på skärmen kan automatiseras via JAutomate. Allt som är synligt tänker du kanske… Jag har ju ett kommandofönster, en web-applikation och en Telnet-klient öppen; kan jag manipulera och verifiera alla dem samtidigt via ett verktyg?! Yepp – det är precis vad du kan göra! OK, men då måste jag vara Javaprogrammerare? Nix! Du kan ta fram enklare skript genom att förstå begrepp som: Click, Verify, Drag/Drop, Type, Wait, While, …
När du tex. vill använda dig av kommandot Click efterfrågar verktyget vad som skall klickas. Du anger då med musen detta, precis som användaren skulle göra. Resultatet blir att skripten inkluderar bilder, så de blir extremt lättförståliga.

Vad tror du tex. följande skript gör?

Just det!

• Startar upp browsern och går till ”www.addq.se”
• Väntar på att AddQ-loggan skall bli synlig (dvs. väntar på att sidan laddat klart)
• Hovrar över ”Om AddQ”-menyvalet (för att drop-downmenyn skall bli synlig)
• Klickar på ”Värdegrund” i drop-downmenyn
• Väntar på att Värdegrund -sidan skall ladda klart
• Verifierar att ett av våra ledord står för ”Ständigt lärande”

 Testrapporten från körningen ser ut så här:

Man ges också möjligheten att via URL titta på skärmdumpen från verifieringssteget.

Hur ser det då ut om skriptet fallerar? 
Manipuleras verifieringssteget till att bli: 

 och testet körs om så fås följande resultat (nedkortat till verifieringssteget):

 Tittar jag på länken till skärmdumpen för det fallerade steget ser jag att bilden ser ut så här:

Ganska intuitivt enl. min mening!

Skripten kan förstås göras betydligt mer komplicerade med tex. If/Then-, While-satser, anrop av andra JAutomate-skript, anrop av externa Java-funktioner, datadrivna anrop etc. Man kan tex. göra generiska skript som via indata anropar olika bildbibliotek för att tex. testa olika språkvarianter av samma applikation – kanske verifiera att avtalsvillkor presenteras korrekt beroende på marknad.

Som nämndes ovan så lämpar sig inte verktyget till all sorts verifiering; bla. så är det inte så lämpligt att verifiera loggar som skulle behöva skrollas igenom (även om verktyget stödjer denna funktion), då det kan göras betydligt mer effektivt på andra sätt. Det har leverantören hanterat genom att erbjuda möjligheten att anropa externa Java-funktioner; och via detta gränssnitt öppnar sig oändliga möjligheter för vidare datamanipulation.

En användningsbar funktion är också att man kan trigga skripten från Continuous Integration (CI) servers (tex. Jenkins) och presentera testresultaten i dess miljö. Du har därmed möjlighet att genomföra händelsestyrda (tex. vid incheckning i kodversionssytem) eller schemalagda körningar i regressionssyfte.

Automationsforumet avslutades med att vi labbade med verktyget med stöd från verktygsrepresentanterna. Det hördes ett och annat ”Coolt!”, ”Det här skulle kunna underlätta på mitt uppdrag!”, ”Man kan använda detta ur ett användarvänlighetsperspektiv”, etc. från de närvarande kollegorna. Det kändes efter sammankomsten att vi förutom haft kul också hade lärt oss en hel del!

Arrangör för forumet/vid tangentbordet:
Fredrik Lind
QA Specialist
AddQ Consulting

”Högt i tak”, ”medarbetarna är vår främsta resurs”, ”vi främjar olikheter”, ”lärande organisation”, ”vi är transparenta”. Regelbundet möts vi av denna typ av ord med syfte att beskriva hur kulturen fungerar på en arbetsplats. Men vad betyder det att det, till exempel, är högt i tak på en arbetsplats? Jag återkommer till det lite längre ned i texten.

Att jobba med kvalitetssäkring som yrke, till exempel som kravanalytiker eller testare gör att man blir ganska bra på att granska krav och utvärdering och att säkerställa vad som fungerar och inte fungerar när det gäller ett IT-system. Men hur bra är vi på att ta hand vår kultur på arbetsplatsen och att vara delaktig i att skapa den kultur vi vill ha? Vi kanske ska införa mer av de etablerade metoderna för att genomföra test av IT-system för att ta temperaturen på hur väl kulturen är kongruent mellan det som sägs och hur det efterlevs på arbetsplatsen?

Högt i tak? Ja, så länge vi sitter ned!

Jag inledde denna text med några av de vanligast förekommande flosklerna, om man nu ser dem som floskler. Det är fina ord och om de verkligen visas i handling så är de definitivt inga floskler längre. Men vad betyder de egentligen? Här kommer några reflektioner att fundera på.

Har vi högt i tak så betyder det för mig att man på en arbetsplats får ifrågasätta, vara rak och ärlig utan att bli bestraffad. Främjar vi olikheter så ska det också synas genom en blandning av människor i olika åldrar, kön, etnisk bakgrund, sexuell läggning och så vidare. Medarbetarna är vår främsta resurs, men hur visas det då? Genom hög lön och förmåner eller att man får bidra med hela sin kompetens och genom det kan pröva nya områden? Lärande organisation är till för att hela tiden lära av varandra och att utvecklas framåt men uppmuntras det så att tid kan avsättas för att utbyta information och är klimatet tillåtande och generöst så att alla vill släppa ifrån sig information.

Ta en öl efter jobbet så trivs vi ihop

Arbetsplatsen är en arena för relationer och till skillnad från andra arenor där du skapar långsiktiga relationer har du sällan fått välja de du ska umgås med på arbetsplatsen. Det är en plats där någon har föst ihop människor i en flock och sedan sagt åt dem att trivas. Vi arrangerar kickoffer, trivselkvällar, after work-pubar och annat för att vi ska fungera bra ihop och trivas. Och alla de här delarna ligger också till grund för vilken kultur som ska råda på en arbetsplats. Det finns en mängd undersökningar inom området och det som brukar lyftas fram som verkligen hjälper till för att skapa hög trivsel och an bra grund för gemensamma värderingar på en arbetsplats är variation och utveckling i arbetet, eget ansvar, yrkesstolthet och meningsfullt arbete. När det gäller organisation och företagets agerande lyfts följande faktorer fram: korta beslutsvägar, närvarande chef, feedback, tydliga riktlinjer och lyhördhet. Finns de här delarna på plats då kan man också jobba vidare med en väl fungerande kultur.

Jag jobbade för några år sedan med ett oerhört framgångsrikt införande av värderingstänk i en organisation. Det vi gjorde i det här fallet var att titta på situationer i vardagen och gå igenom hur vi agerade i de olika situationerna. Utifrån de verklighetsbaserade casen kunde vi snabbt konstatera vad vi skulle fortsätta med, sluta med och börja med utifrån den kultur och de värderingar vi ville ha på den arbetsplatsen. Det blev ett oerhört uppskattat arbete som gav gemenskap, insikt i hur olika vi människor resonerar i vardagen och det blev en enighet kring vad faktiskt värderingar står för.

Från okul tur till kul tur

Sammanfattningsvis vill jag skicka med fem saker som bidrar till en kul tur:

• Delaktighet – Se till att du är och känner dig delaktig och hjälp dina kolleger med samma sak. Att känna att man är delaktig i sitt arbete är mycket viktigt. Känslan av att kunna bidra till något gemensamt, att vara behövd skapar motivation inför arbetet.
• Inflytande – Säkerställ att du på den här arbetsplatsen kan påverka. Om man kan vara med att påverka sitt jobb, både på kort och lång sikt, bidrar det till ökad arbetstillfredsställelse och motivation.
• Utvecklingsmöjligheter – En arbetsmiljö som karakteriseras av möjligheter till personlig utveckling är eftersträvansvärd och associerad med det goda arbetet. Vi mår bra av att känna att vi ständigt lär oss nya saker och har ansvar för vårt arbete.
• Sociala relationer – Att ha goda sociala relationer beskriver många som något av det viktigaste med arbetet. Goda sociala relationer innefattar både relationer med de man jobbar tillsammans med dagligen och relationer med chefer eller ledning.
• Rättvisa – En arbetsplats ska också vara rättvis. Detta innebär till exempel att alla behandlas respektfullt och att inga särbehandlingar eller trakasserier sker. I dagens samhälle känns detta som en självklarhet, men ändå förekommer det mycket orättvisor inom arbetslivet.

Jag deltog nyligen i ett spontant SAST Meetup hos ingen mindre än Spotify – där temat för kvällen var ”Agilt hos Spotify”.

Det var en intressant kväll som bjöd på både inspirerande och givande erfarenheter från testsfärens olika hörn. Spotify bjöd på mer än bara gott att äta och dricka: med 5 s.k. blixttal med korta men fullspäckade presentationer var lika uppfriskande att lyssna på som drickan som serverades.

Presentationerna var lagom korta/långa för att åhöraren inte skulle hinna tröttna på att lyssna. Det var upplagt för bra stämning och intressanta diskussioner efteråt.

Intressant var också att se hur Spotify mött de utmaningar man hade ställts inför, inom en snabbt och ständigt växande organisation som samtidigt anpassar sig efter sina behov med ett agilt arbetssätt. Fördelningen och grupperingen av testare som man strukturerat i parallella grupper kunde effektivt integreras med varandra när det behövdes. Det här var ngt som kvällens keynote och första talare; den agila coachen Claes Richàrd, hade varit med och drivit igenom. Kanske var detta tal också kvällens mest inspirerande?

Arbetsmiljön är kanske vad man kan vänta sig av en organisation som Spotify.

Moderna och tilltalande miljöer i öppna planlösningar och loungeliknande fikaplatser som ligger centrerat i lokalen för att skapa en tydlig öppenhet.

Presentationerna handlade mestadels om testautomatisering och gav flera intressanta lösningar på hur man har valt att jobba inom test. Planerandet och användningen av automatgenererade tester med minimalt underhåll verkade åtminstone effektivt på ytan.

Personligen har jag lite svårt att tänka mig att det kan passa alla, att utföra automatiserade tester i den mån som Spotify gör eftersom många tester är beroende av färsk och skiftande testdata m.m. som gör att testerna blir bräckliga och allt för underhållskrävande.

Men budskapet var tydligt: låt de automatgenererade testerna sköta så mycket av det monotona och tråkiga testarbetet som bara är möjligt.

// Jan Challma

Janne började arbeta inom test för drygt 2 år sedan, och har sen dess andats och levt test. Han tycker det är lika givande varje gång man träffar människor från branschen ifrån olika håll och får uppleva test ur andras ögon och perspektiv. Sen några månader tillbaka jobbar han med en betalningsplattform på Arbetsförmedlingens huvudkontor där han har haft turen att jobba med och lära av några av de mer kompetenta personerna i testsfären.

Hur ofta har det inte hänt att ditt mätsystem fått skulden när en mätning inte gått som det var tänkt? Ett av de vanligaste sätten att hantera detta är att helt enkelt mäta en gång till och hoppas att det fungerar nästa gång. Detta brukar fungera ganska bra i praktiken, men kan vi verkligen lita på mätsystemet? Hur bedömer vi kvalitén på våra mätningar?

Innan vi börjar bedöma kvalitén på vårt mätsystem, kanske vi ska fundera igenom vad som är vårt mätsystem? Det första som man kommer att tänka på är vanligen de instrument som används vid mätningen, men även mätmetoder, fixturer och kablage, mjukvara, operatör och omgivning utgör del av ditt mätsystem och kommer att påverka mätningarna.

Mätsystemanalys går ut på att bedöma kvalitén på dina mätningar genom att titta på de olika källor till variationer som kan uppkomma i ditt mätsystem, inkluderade hela ditt mätsystem. För att vara rättvisande måste analysen genomföras med multipla mätningar under stabila förutsättningar. Det vi vill åstadkomma i en mätsystemanalys är att beräkna bidraget som varje källa till variation bidrar med och se hur stor del av den totala variationen som denna variationskälla utgör.

Variation och variationskällor

Variation definieras genom att beräkna de statistiska egenskaperna, medelvärde och standardavvikelse. Det trevliga med både medelvärde (μ) och standardavvikelse (σ) är att de har samma mätenhet som själva mätvärdena har och blir då lätta att tolka. Då de flesta mätningar är normalfördelade vet vi att teoretiskt ligger 99.73% av alla mätvärden inom +/- 3σ från medelvärdet.

I ett mätsystem definieras de olika variationskällorna som dels variationer i testobjektet och dels variationer i mätsystemet. Hur kan vi då räkna ut fördelningen mellan dessa två källor till variation? Tyvärr är inte standardavvikelsen summerbar, men det visar sig att kvadraten av standardavvikelsen, variansen, går att summera. Enligt nedanstående formel:

Den totala variansen är lika med summan av variansen av part-to-part, dvs. variation mellan de olika testobjekten, och variationen i mätsystemet. Helst vill vi att alla variationer är part-to-part och mätsystemet inte bidrar alls, men verkligheten visar sig inte vara på detta sätt.

Variationen i mätsystemet kan nu i sin tur delas upp i två olika delar och vi får nu nedanstående formel:

Mätsystemets variation består nu av två olika delar variationer beroende på repeatability och variationer beroende på reproducibility. Innan vi går in närmare på dessa två källor, är det nu dags att beskriva hur en mätsystemanalys (MSA) går till rent praktiskt. En klassisk MSA genomförs genom att utföra ett antal kontrollerade mätningar där ca 10 mätobjektet mäts 3 gånger vardera av tre olika appraiser i slumpvis ordning. En appraiser kan antingen vara en operatör, en maskin, en testutrustning eller en position på en PCBA testplatta.

Nu kan vi definiera:

• Repeatability – kan en appraiser repetera samma mätresultat för samma mätobjekt?
• Reproducibility – är det skillnad mellan hur de olika appraisers mäter?

Gage R & R – Repeatability and Reproducibility Study

Denna typ av mätsystemanalys kallas Gage R&R och är den vanligaste mätsystemanalys och definieras av en svårtolkad AIAG/ISO16049 standard. Resultatet av mätningarna ställs samman i en symmerisk tabell och nu kan vi beräkna variationerna mellan de olika källorna med hjälp av en s.k. ANOVA – Analysis of Variance. Mycket förenklat är grundtanken att medelvärdet beräknas för de olika mätningarna i olika led, och en viktad varians beräknas, se figur nedan. Dessa beräkningar är svårt att utföra manuellt utan verktygstöd som t.ex. AddQs QRM eller Minitab, varför detta rekommenderas starkt.

Resultatet av en Gage R&R är ett mått på precision, men inte ett mått på absolut noggrannhet (som genomförs med en s.k. Gage Study Type I, mer om detta i en kommande blogg).

Presentationen av Gage R&R resultatet kan dels ses i en tabell, se nedan där en Gage R&R tabell från QRM visas. De intressanta värdena är markerade med fet stil. %Contribution som anger hur stor del av variationerna som ligger i mätsystemet, Total Gage R&R, och som beror på Part-to-Part. Total Gage R&R redovisas också som en uppdelning av Repeatability bidraget och Reproducibility bidraget.

Enligt AIAG standarden ska totala bidraget till variansen i ett acceptabelt mätsystem vara <1% och potentiellt acceptabelt om bidraget är <9%. I praktiken är det mycket svårt att nå upp till <1%, allt beroende på vilka krav som ställs på mätsystemet och i vilket sammanhang det användas, så är <9% ofta tillräckligt.

Det andra resultatet som är av intresse är P/T (precision-to-tolerance), vilket anges som %Tolerance i tabellen ovan. Detta mått kan beräknas om det finns en kravgränskopplat till mätningen. P/T anger hur mycket av kravet som ”äts” upp av variationerna i mätsystemet. Enligt AIAG standarden är kravet <10% för att vara acceptabelt och <30% för att vara potentiellt acceptabelt. Varför är det då 9% i ena fallet och 30% i andra fallet? Jo, kom ihåg att det ena kravet är för varians och det andra för standardavvikelsen. Kvadratroten ur 9% är just 30%, så kravnivåerna är samma. Det gäller att inte jämföra äpple med päron! Det går även att presentera Gage R&R resultatet som ett stapeldiagram, se nedan.

I kommande blogg fördjupar vi oss i hur resultatet från en Gage R&R analys ska tolkas och vad man bör se upp med.

Referenser:

• Bass, Issa, 2007: Six Sigma Statistics with Excel and Minitab. ISBN: 978-0-07-149646-9
• AIAG Manual Measurement System Analysis 4th Edition. ISBN: 978-1605342115
• Wheeler, Donald J: Evaluating the Measurement Process EMP III. ISBN: 978-0945320678

Om författaren:

Mattias Ericsson har jobbat med test- och mätsystem i 15 år. Han är R&D manager inom AddQ Göteborg och jobbar med framtagningen av AddQs resultathanteringssystmet QRM när han inte är upptagen med kundprojekt.

Desto mer jag läser om det, engagerar mig i och testar användbarhet desto mer övertygad blir jag om att nyttan verkligen ligger i användandet. För om du inte kan få en användare att förstå nyttan av de system du är med och utvecklar så spelar det ingen roll hur snabbt eller användarvänligt systemet är. För om användaren inte förstår nyttan så kommer motviljan att använda det nya systemet vara stor och kanske till och med leda till stress hos användaren.

Jag har den senaste tiden utfört ett antal intervjuer med användare efter en avslutad pilotperiod i mitt projekt och de svar var jag fick var väldigt varierande på många punkter men det samtliga piloter var rörande överens om var att systemet måste fungera och underlätta deras arbete annars kunde de lika gärna vara utan. Det vill säga att dom måste förstå nyttan.

Att få ett system att fungera är vi inom test och utveckling rätt bra på, men att få systemet att underlätta användarens arbete det är något vi ofta hoppas på att systemet gör när det väl är i produktion, men hur verifierar vi att det verkligen gör det?

I det här projketet har jag tack och lov fått möjligheten och tiden att utföra användbarhetstester mitt i projektet också. Vi gjorde en del  användbarhetstester med slutanvändarna utifrån designskisser i början av projektet, innan vi började utveckla. Nu har vi kommit en bra bit på väg och jag tycker det är dags att köra en runda användbarhetstester till för att dels verifiera att vi tolkat kraven rätt, men även för att få användaren att känna nyttan av det nya systemet.

Jag tänkte den här gången skriva så kallade personas där jag tilldelar användaren en roll och några enklare uppgifter att utföra, men jag tänker inte tala om hur uppgifterna ska utföras. En viktig sak att tänka på är att utföra dessa tester med rätt personer i en miljö där de känner sig trygga, d.v.s. rätt person i rätt kontext. De frågor jag tänkte fokusera på är följande:

1.       Tillfredställelsen

Hur behagligt/trevligt är det att använda systemet?

2.       Inlärningsförmågan

Hur lätt är det för användaren att utföra enklare uppgifter för första gången?

3.       Effektiviteten

När användaren väl lärt sig systemet hur snabbt och enkelt kan dom utföra sina uppgifter?

4.       Felen

Hur många fel gör användaren?

Hur allvarliga är felen?

Hur lätt tar sig användaren därifrån?

Det ska bli otroligt spännande att utföra dessa tester och få se användarnas reaktioner på de nya systemet. Jag ber att få återkomma med resultatet i ett senare blogginlägg. Så fortsättning följer….

I det här blogginlägget vill uppmuntra dig som tror att du inte är kreativ att ändra på den synen på dig själv. Jag vill också avdramatisera vad kreativitet faktiskt är. Det handlar om problemlösning. Mycket enkelt och kortfattat är du kreativ varje gång du löser ett problem som inte har en given lösning.

Kreativitet handlar om möjlighetstänkande och som ger associationer och idéer. Att våga tänka att allt är möjligt gynnar ett ständigt idéflöde, av vilket fantasin är en viktig del. Vi processar till exempel det vi har varit med om och kan se det på nya sätt i efterskott. Men det betyder också i praktiken att omgivningen kan förändras när nya idéer genereras eller när nya produkter skapas.

Ok, det är inne att vara kreativ och vi vill alla vara kreativa. Och hur kreativ är du då i din vardag? Hur kommer det sig att det är svårare att byta plats runt köksbordet hemma än att köpa ny bil? Byt plats vid köksbordet så får du helt nya vyer, ta en annan väg till jobbet, byt roller hemma. Allt som bryter de invanda mönstren öppnar upp för nya perspektiv och skapar ett kreativt flöde.

Jag sa inledningsvis att det är inne med att vara kreativ och visst finns det förväntningar på att vi ska vara kreativa, men inte hela tiden. Vi vill helst inte att tandläkaren är alltför kreativ när han eller hon genomför en rotfyllning, vi vill helst inte att banken är kreativ när det gäller löneutbetalning eller penningtransaktioner, det vore inte heller så kul om busschauffören på morgonen fick för sig att köra en ny liten runda på väg till jobbet. Det efterfrågas någon typ av balanserad kreativitet. Man ska vara kreativ men inte för mycket. Hm… hur håller man den balansen.

Kreativitet är beroende av flera variabler: personliga egenskaper, begåvningsfaktorer, personlighetsdrag och miljö. Och om vi pratar om att balansera kreativiteten så att den bejakas och uppmuntras men ändå inte tar all kraft och energi hela tiden så gäller det att hålla koll på hur våra kolleger, medarbetar, kunder, chefer, och så vidare är kreativa.  Många associerar kreativitet till konstnärliga yrken men om vi lyfter oss från de konstnärliga yrkena och pratar praktisk kreativitet så brukar kreativitet definieras som något som är nytt och originellt (i motsats till gammalt och trivialt). Det ska också vara användbart och uppskattat på något sätt.

Det är lätt att tänka sig att en kreativ person är utåtriktad, en idéspruta som springer på allt. Och ja, de finns men det finns också andra personligheter som är minst lika kreativa. Jag känner till bägge varianterna. Det första exemplet är en person som ser möjligheter i allt och som går fram som en ångvält när han fått korn på något. Han dammar upp ordentligt, pratar med människor, sprutar ur sig idéer men stannar inte kvar och fångar upp. Här gäller det att säkerställa att idéflödet inte stoppas men att det tas om hand på något sätt. Det andra exemplet är en total motpol till det första exemplet, personlighetsmässigt. Den här personen vill att allt vara klart och nedskrivet och välordnat och fakta ska finnas innan han vill börja titta på idéer och lösningsförslag. Men han har minst lika många idéer som den första personen jag exemplifierade. Båda de här personligheterna är kreativa men på olika sätt och behöver uppmuntras utifrån sina egenskaper.

Förutom de biologiska faktorerna som ligger som en grund för människors kreativitet så bidrar också personlig erfarenhet till att utveckla den kreativa förmågan. Kreativitet kräver också kunskap. Ju mer kunskap och erfarenhet man har, desto fler faktorer kan man kombinera, vilket gynnar skapandet. Om lusten försvinner är det svårt att vara kreativ. Många associerar kreativitet till något som är nytt, men inte nödvändigtvis värdefullt. Det sistnämnda är dock viktigt. En riktigt bra kreativ idé ska dessutom vara genomförbar.

Det jag själv ser som viktiga faktorer för att skapa en kreativ miljö både för konsulter och kunder är att skapa utrymme och tillåtelse att ventilera tankar och idéer, ge tid, efterfråga lösningar, låt människor tänka själva, våga ställa frågor som utmanar nuvarande lösning, släpp prestigen och sätt er framför ”lägerelden” för att kreera tillsammans! Och kom ihåg att kreativitet skapar lösningar både i det lilla och det stora.

Ta till vara på vardagskreativiteten!

Om Eleonore Hammare:
VD Systemstrategerna, senior konsult och rådgivare inom IT-området. Gästbloggare hos AddQ Consulting. Lång erfarenhet som chef och ledare i olika IT-organisationer.
Har också uppdrag som mentor och styrelseledamot.

Spårbarhet som generellt begrepp ger oss möjligheter att koppla olika typer av artefakter till varandra och via dessa kopplingar besvara olika typer av frågor. Inom mjukvaruutveckling finns många exempel på spårbarhet med mer eller mindre komplexa kopplingar. Man kan till exempel tänka sig att spåra mellan krav, testfall, felrapporter, testresultat och produkter.

Dessutom kan man ytterligare komplicera denna bild genom att i sin spårbarhet även ta hänsyn till olika versioner av ovanstående.

Nedan berörs fem centrala frågeställningar när det handlar om spårbarhet mellan krav och testfall.

1. Vad ska spårbarhetsinformationen användas till?
   Innan man implementerar spårbarhet mellan krav och testfall bör man fundera på vad man egentligen ska använda spårbarheten till. Den tänkta användningen kan påverka hur spårbarheten implementeras och/eller vilket verktyg man väljer. Möjliga användningar ges av svaren på följande frågor:

• Vad är hittills täckt och vad återstår? (Planering)
• Vilka krav är EJ uppfyllda, som resultat av ”failade” testfall? (Riskanalys)
• Täcks ett krav i sin helhet? (Test Design)
• Vilka testfall påverkas av en potentiell kravändring (Underhåll)

1. Vem ansvarar för att den skapas, och inte minst underhålls?

Nästa viktiga fråga är vem eller vilka som ansvarar (äger) spårbarhets-informationen. Att skapa en mängd spårbarhetinformation är en kostnad. Därtill kommer även en kostnad för att hålla informationen uppdaterad över tiden. Tanken är att spårbarsinformationen ska innebära ett mervärde som överskrider dessa kostnader. Utan någon som ansvarar för spårbarhets¬informationen och som driver arbetet med spårbarheten är risken stor att organisationen aldrig når en punkt där spårbarheten genererar något mervärde.

I detta sammanhang är det även viktigt att förstå om syftet med att erhålla spårbarhet endast en projektangelägenhet eller om finns en mottagande förvaltning. I det senare fallet är det viktigt att representanter för förvaltningen tidigt involveras i spårbarhetsarbetet.

1. Hur påverkar spårbarhetsstrategi och testfallsstrukturen varandra?

Spårbarhetsstrategi handlar bland annat om hur man väljer att täcka sina krav med testfall. Man kan tänka sig ett 1-1 förhållande, dvs. varje krav testas av (och länkas till) ett och endast ett testfall. Detta är bra ur analyssynpunkt, men i praktiken ofta svårt att uppnå, då både krav och testfall kan se väldigt olika ut. För generella krav kan man behöva flera testfall för att täcka kravet, vilket leder till en 1-N relation. Flödesbaserade testfall har ofta den omvända egenskapen, dvs. ett testfall täcker mer än ett krav, vilket leder till en N-1 relation. Slutligen kan man även tänka sig testfall som testar delar av flera krav, vilket ger N-N relationer mellan krav och testfall.

Vilken eller vilka av dessa relationer man ska tillåta/uppmuntra beror på en massa olika aspekter, men oavsett så kan det påverka den struktur man skapar för sina testfall.

Många gånger kan det även vara klokt att anpassa sin spårbarhetsstrategi över tiden. Initialt, när systemet fortfarande är instabilt används mest 1-1 eller 1-N relationer för att ett fel i ett krav inte ska förhindra godkännande av övriga krav. Senare när systemet stabiliserat sig, utökas scoopet till N-N, för att tillåta längre testfall som bättre avspeglar verkliga flöden.

1. Hur hantera bilder och modeller

Att en bild säger mer än tusen ord håller nog de flesta med om och för att förstå en komplex mekanism är det ju nästan alltid enklare att strukturera informationen i bilder, tabeller eller modeller jämfört med att ha informationen i löpande text eller uttryckt i en stor mängd korta koncisa kravtexter.

Hur gör man då när det handlar om spårbarhet mot ett sådant objekt (bild, tabell eller modell)? Under antagandet att det objekt man ska testa kräver flera testfall för att täckas, så finns det två grundläggande sätt att hantera spår¬barheten beroende på ambitionsnivå.

Med den lägre ambitionsnivån ger man objektet en unik identitet (ungefär som en krav-identitet) och kopplar sina testfall mot denna identitet. Detta ger tydlig spårbarhet mot objektet men inte dess delar.

Med en högre ambitionsnivå så identifierar man delar inom objektet och ger var och en av dessa delar en egen identitet. Med tabeller är detta ofta enkelt; till exempel varje rad, varje kolumn eller varje cell. Med vissa typer av modeller kan det också vara ganska enkelt, t.ex. vägar genom ett användnings¬fall eller en tillståndsmaskin. Bilder däremot är svåra. Kanske kan man dela upp bilden på något sätt, men det kräver samarbete med den som ansvarar för bilden och dess innehåll.

1. Om spårbarhetsverktyget bara har en typ av länk, vad gör man då?

Så snart spårbarhetsinformationen blir lite mer omfattande så finns det bara en väg att gå och det är mot etablerade verktyg. Tyvärr har flera av de stora kommersiella verktygen en inneboende brist i sitt stöd för spårbarhet, nämligen bara en typ av länk för att koppla ihop krav med deras associerade testfall. Varför att detta ett problem? Jo, det finns minst två sätt att se på dessa länkar. Med det första perspektivet så väljer man att länka in alla krav som eventuellt skulle kunna påverka testfallet, även om kravet faktiskt inte testas av testfallet. Som exempel kan man tänka sig ett generellt krav som säger: ”alla menyval ska ha kortkommandon”. Detta krav skulle man med denna utgångspunkt sannolikt länka till ganska många testfall. Fördelen är att om kravet ändras så får man en bra utpekning av alla testfall som behöver analyseras för att säkerställa att kravändringen slår igenom i alla berörda testfall. Nackdelen med detta perspektiv är att man riskerar att få en massa ”false-fail” dvs., krav som är markerade som ”failade” trots att dom är implementerade korrekt.

Med det andra perspektivet så väljer man att från ett testfall bara länka till de krav som verkligen testas (helt eller delvis) av testfallet. Det ger en bra utpekning av krav som inte uppfyllts, vid eventuella ”fail”, men risken är att man missar att uppdatera testfall som påverkas av en kravändring eftersom det inte finns någon länk som kopplar ihop dessa testfall.

Som med alla intressanta och svåra frågor så finns ofta inga givna svar. Sannolikt är svaren på ovanstående frågor situationsberoende men genom att fundera på dessa frågor så ökar man chansen att göra ett bra val.

Om författaren (Mats Grindal)

Mats startade sin testkarriär i början på 1990-talet i en testroll. Sedan dess har han jobbat i många små och stora testprojekt i olika roller, bl.a. som testledare, testprojektledare, testkoordinator och test configuration manager. Mats stora intresse för testning har även lett till ansvarsposter inom både SAST och SSTB. Han är även gästkrönikör på Testzonen och han har hållit ett antal föredrag på både Nationella och Internationella konferenser.

Hand-In-Hands vision är att eliminera fattigdom genom utbildning och företagande.

Hand-In-Hands mål är att skapa 10 miljoner jobb globalt inom 10 år. Med det generösa bidraget från AddQ Consulting, så hjälper man nu Hand-In-hand att fortsätta arbetet med att bekämpa fattigdom genom utbildning och företagande. Hand-In-Hand verkar för närvarande i Indien, södra och östra Afrika samt i Afghanistan.

Hand-in-Hand är en organisation som skapar jobb bland de fattigaste genom att utbilda kvinnor, med nya kunskaper och entreprenörskap kan många kvinnor nu själva skapa bättre levnadsvillkor för sig och sina familjer och därmed bygga en framtid med hopp, värdighet och valmöjligheter.

Läs mer om Hand in Hands arbete på: www.handinhand.nu

Ännu en gång har SET genomfört ett ”roundtable”-möte inom ramen för utforskande tester. Denna gång var det Per Almström från AddQ som berättade om hur han använt Jira för att knyta ihop krav och buggar med sina testsessioner.

Det var en tapper skara som bidrog till mötets framgång (tycker i alla fall jag): Amanda Johansson, Elisabeth Sax, Jan Sjöö, Jörgen Ekman, Lena Sandberg, Liza Ivinskaia, Magnus Holmqvist, Hans Olsson, Johan Bergström, Per Almström och Michael Albrecht.

Pers lösning som han berättade om var lean and mean och fyllde mycket väl sitt syfte. Kul att se en lösning som inte strular till det utan faktiskt blir ett stöd i det dagliga arbetet. Jag tror personligen att har man inställningen att verktyg inte fixar processer och metoder åt dig utan ses som ett stöd, har man nått framgång redan där.

Tyvärr kunde jag under mötet höra hur många är hårt tvingade till att använda vissa verktyg för sin testning och då blir det lätt att man trixar och fixar väldigt mycket för att få till en implementation, man vill stoppa in allt.

Kortsiktigt funkar det säkert att ändra metoder och arbetssätt för att stoppa in dem i ett fint paketerat verktyg men långsiktigt tror jag att det kommer vara rena döden.

Verktyget skall vara ett stöd, inte ett hinder.

När jag är ute och genomför verksamhetsförändringar med inriktning mot utforskande test brukar jag rekommendera att man börjar använda verktyg som Word, Excel eller Xmind (http://www.xmind.net/) för sina utforskande tester.

När man väl lärt sig metoderna och teknikerna, anpassat dem till ”sin” verklighet kan man börja fundera på att stoppa in dem i något Corporate verktyg (om man måste).

Ja, för måste vi verkligen ha alla möjliga rapporter, grafer, kopplingar och spårbarhetsmöjligheter som QC erbjuder?

Jag hävdar starkt att: A Fool with a Tool, is still a Fool

Om författaren (Michael Albrecht)

Michael har haft roller som Scrum Master, Scrum medlem, testledare, projektledare, teststrateg, testarkitektarkitekt, metodspecialist, acceptanstestledare, kravanalytiker, utbildare och testare. Michael har även jobbat mycket med att bygga upp och förbättra testorganisationer. Under senare år har merparten av Michaels uppdrag varit inom metoden Scrum och då som Scrum Master.
Michael är även en mycket uppskattad talare vid seminarium och konferenser och lärare i AddQs externa utbildningar. Under 2014 kommer man även att kunna se och lyssna till Michael tala om xBTM på konferensen Better Software Conference West i Las Vegas