Gå till innehåll

Jaha, så ska jag ut och flyga i orkanens skugga. Då kraftiga vindar hade utlovats i Skåne bestämde jag mig för att kolla avgången 10.40 till Malmö innan jag tog mig till flygplatsen. Går man in på luftfartsverkets hemsida finns det en länk till flygplatserna och aktuell information - BRA. På Bromma-sidan står det att planet går som vanligt, vad bra! För säkerhets skull bestämmer jag mig för att även kolla upp Sturup. Här visar sig planet vara inställt. Hmm, undrar om det verkligen går från Bromma men aldrig landar...det verkar inte speciellt troligt. Nu får jag istället ringa upp trafikinformationen fast det känns så gammaldags. Efter ett mycket start antal signaler så kommer jag fram till en telefonist som upplyser om att planet verkligen är inställt och att jag måste boka om biljetten. Då ringer jag först upp biljettbokningen hos MalmöAviation, efter ett stort antal val kommer jag fram till personlig service där jag får beskedet att det bara går att boka om på flygplatsen, som tur är får jag ett direktnummer dit. Jag ringer direktnumret och hamnar i ...Malmö!

-Du måste ringa Bromma svarar de på min fråga om ombokningen.
-Men det gjorde jag svarar jag, ja men efter tre signaler kopplas det om till oss om de inte svarar.
-Jaha, så lösningen är att låta tre signaler gå fram, sen lägga på och ringa upp igen.
-Ja det blir bra, svarar hon.

Bra och bra, det undrar jag. Så jag börjar ringa direktnumret om och om igen...efter 47 samtal på fem minuter så svarar det på Bromma. Min glädje finner inga gränser. Jag slipper åka till flygplatsen för att boka om biljetten. Teknikens under!

- Ja du vet stormen säger han, det finns platser ikväll eller imorgon klockan åtta.
- Då får det bli ikväll svarar jag.

Så totalt sett har jag surfat in på tre olika sidor och ringt till fyra olika platser. Bra lösning - nej knappast.

Hur skulle användbarheten kunna förbättras radikalt?

1. Det ska ALLTID finnas aktuell, korrekt information på flygplatsernas hemsidor
2. Förutom informationen om att det är inställt vill jag kunna klicka på ordet inställt och få mer information: tex det är inställt pga tekniskt fel, inte vädret! Du måste ringa nummer 08-123123 för att ändra bokningen och allra helst logga in med en kod och ändra tiden själv!

Dessa relativt enkla åtgärder skulle förenkla för mig som kund och spara et massa onödiga telefonsamtal. Ja med detta i åtanke är användbarheten någt av det viktigaste som finns för en publik sajt och ett serviceföretag.

Äntligen dags för vår första Peer Conference i test

Helgen 11-12 november samlades ett tappert gäng på Högberga gård, Lidingö för att i två dagar diskutera testdesign. Konferensen har som mål att deltagarna ska få presentera sin egna erfarenheter och alla får sen ställa frågor och kommentera. Skillnaden mot "vanliga" konferenser är att dn som presenterar säger det han ska och sen ställs det ett par frågor för sakens skull. I vårt fall är det tvärtom, presentationen tar mellan 20 och 30 minuter och den efterföljande diskussionen för de först två presentationerna tog en dryg timme för varje presentation. För första gången på länge känner jag att vi verkligen har en diskussion och och utbyte av värde. Förhoppningen är att detta första mötet följs av åtskilliga liknande möten.    

Till vår hjälp hade vi testgurun James Bach som troligen är den som deltagit i flest liknande konferenser i USA och England. James började med att berätta reglerna för mötet vilka kan sammanfattas som:

1. Alla presentationer bygger på egna erfarenheter

2. Allt som sägs på mötet får föras vidare

3. Varje presentatör får presentera sin sak utan att bli avbruten

4. Efter detta följer diskussionsstunden där övriga deltagare ställer frågor eller kommenterar det som sagts. Vi bestämmer själva hur länge diskussionen pågår genom att sluta ställa frågor.

5. Agendan för mötet och inbjudna deltagare bestäms av Content Owner: den person som arrangerar mötet. Moderator som håller reda på diskussioner och frågor kallas i vårt fall Facilitator.

Deltagare denna gång var:
Content Owner: Torbjörn Ryber
Special Guest: James Bach
Deltagare: Siv Carlsson, Klaus Andersson, Daniel Nordling, Pablo Garcia (han som har många strängar i sin villa enligt CS 10 nov), Jörgen Damberg, Anders Claesson, Frederik Rydberg, Michael Albrecht, Örjan Svensson, Rolf Nilsson, Ann-Charlotte Bolander

Jag fick äran att inleda konferensen med en kort presentation om test av en kreditratingfunktion. Efter en tjugo minuter lång beskrivning av hur testdesign fungerade otroligt kraftfullt för att hitta fel i kraven innan någon kodning hade startat följde en timmes frågestund. Verkligen kul att alla är så engagerade. 

Klaus Andersson berättar om hur de använder sig av all-pairs för att få en rimlig mängd testfall då de får nya versioner av elektroniken i bilar. Spännande att höra om all funktionalitet som finns kopplat till bilen i form av signaler från krockkuddar, bensintank, GPS etc och automatiska funktioner som skickar SMS vid en krock. James visade en demo av ett nytt verktyg för att ta fram parvisa tester som heter PICT. 

Dags för nästa presentation om Free User Testing på Maquet.  Frederik Rydberg berättar hur de kompletterar de skriptade testerna som krävs av FDA (USAs kontrollorgan för medicin) med fria tester. Vi hade en mycket lång diskussion som kom in på fördelarna och nackdelarna med utforskande testning. Det var så intressant att vi beslutade oss för att låta James presentera sina erfarenheter av utforskande testning nästa dag.

Lördagkvällen bjöd på en utsökt trerätters middag, jacuzzibad, vedeldad bastu, whisky i Kinasalen, nytt försök med vedeldat bastu och efterföljande brankårsbesök. Brandmännen påpekade att de var mitt i lördagsfilmen och bad oss att i framtiden använda den eluppvärmda bastun istället så att de kunde åka hem och se hur filmen slutade.

Söndagen började med nypressad apelsinjuice, bacon och kaffe för att skaka liv i våra trötta kroppar. Efter det gjorde vi en check-in där alla fick berätta om upplevelsen av gårdagen och förväntningarna inför dagen. 

James berättade om ett lyckat projekt där Exploratory Testing var sättet de arbetade på. Fokus var scenariotester som beskrevs i form av charters dvs en översiktlig beskrivning med data, förberedelser och variationer. Till testutförandet och analysen av testerna användes flera mycket användbara verktyg. Allt testarna gjorde inklusive anteckningar loggades med hjälp av Spector (spelar in vad som händer  på skärmen, 99 USD) så att testledaren kan läsa och analysera i efterhand. Loggfilerna analyserades via Excel för att se testtäckning. Exempelvis kan du be utvecklarna att skriva ut väldigt detaljerat till loggen, att numrera alla funktioner eller objekt och utifrån loggfilen se vad som använts.

Dessutom finns Strings som hjälper dig att dumpa all text från en databas för att sedan analysera den. Beskrivningar av verktygen och länkar till verktyget hittar du på James blog.

Sista presentationen är Pablo Garcia som berättar om test av ett avancerat telefonisystem. Problem han hittade var att dokumentationen av kraven var undermålig. Kraven var inte granskade och samma dokument existerade i flera olika varianter fast det på revisionsbeteckningen var samma datum och version. Första åtgärden blev att skaffa kontroll över kraven och utbilda alla i CM. Nästa steg var att besöka fabriken som tillverkade enheterna fysiskt och där införa manuell kontroll av monteringen. Följande steg var att organisera test, uteckling, dokumentationsstruktur och processen som helhet. Allt var väldigt formaliserat och alla testfall beskrivna i detalj. Resultatet blev att komponentens kvalitet ändrades från instabil till extremt stabil. Fortfarande två år senare var komponenten väldigt stabil men då inga script eller testfall hade uppdaterats hade kvaliteten fömsämrats till viss del. Men på grund av regressionstesterna kunde man ändå hålla en bra nivå.  

Den efterföljande diskussionen handlade mycket om hur detaljerad information som måste sparas för regressionstester. I detta fall fanns det 500 sidor detaljerad testfallsinfo eftersom det inte fanns möjlighet att få bra eller ens halvbra testare i framtiden. Vi inser att dokumentation är ett bra ämne till nästa konferens.

Vi avslutar med att diskutera framtiden och ser alla fram emot nästa gång vi träffas. James lovar att återkomma gratis för att facilitera möten i framtiden. Allt ser lysande ut!      

Hur kommer det sig att fokus för automatisering av tester ligger på användandet av dyra kommersiella verktyg som mycket sällan ger någon vinst åt andra än verktygsleverantörerna? Få är de som verkligen lyckats tjäna något i det långa loppet medan historierna om misslyckanden duggar tätt. Möjliga faktorer är en massiv marknadsföring samt en brist på alternativa synsätt hos oss testare. Jag vill därför presentera ett alternativt synsätt som kallas agil automatisering.

Agil automatisering handlar om att vi istället för synsättet att verktygen ska ersätta oss manuella testare genom att utföra samma tester automatiskt, så är verktygen ett sätt för oss att utföra tester som är svåra eller omöjliga att göra manuellt. Ett exempel är verktyg för prestandatest. Det är i princip omöjligt att simulera trafik utan någon sorts verktyg - där funkar faktiskt de kommersiella bra så länge det finns experter som sitter bakom spakarna. För mig som testare kan det handla om att jag vill lägga upp 200 användare i min testdatabas via det grafiska gränssnittet - här kan det passa bra med ett litet script. Det kan också handla om att analysera loggfiler med tusentals rader och markera det som verkar konstigt. Något jag skulle ha velat ha i ett nyligt projekt var ett sätt att själv ställa frågor till en komponent utan att ha det grafiska gränssnttet klart samt att få ut svaren och skriva dem på ett aptitligt format. Här behöver jag någon som kan hjälpa mig med det tekniska - troligen en utvecklare i projektet. James Bach pratar om Toolsmith - en verktygssmed - som kan hjälpa oss med den här typen av verktygsbyggande. Oftast löser vi problemen med hjälp av gratisverktyg eller hemmabyggen. Nyckelorden är snabbt, billigt och omedelbar användning.

Jag har bara nosat litegrann på detta otroligt intressanta ämne men hoppas att kunna förkovra mig vidare. Letar efter någon med programmerarbakgrund som gillar test och vill jobba med testautomatisering som INTE handlar om att använda dyra kommersiella verktyg. Jag efterlyser talare som jobbat med egna verktyg och vill prata om hur det lyckats.

För den som vill börja själv finns gratisverktygen Canned Heat och Holodeck Lite att hämta hem från James Whittakers sida. AllPairs och PerlScript är två verktyg skapade av James Bach. Allpairs skapar testfall för alla par av värden mellan variabler PerlScript hjälper dig att skapa testdata, exempelvis en sträng av ett visst antal tecken eller alla ASCII-tecken.

Läs en utmärkt artikel på engelska om Agile automation

Alla kan vi göra fel, eller inte riktigt orka ända fram eller helt enkelt så misslyckas något fast vi gjort allt vi kan. Det första jag tänker på är min egen bok. Det var ju inte så svårt att se att vissa av bilderna i boken är suddiga och knappt läsbara. Vad beror det nu på efter alla timmars korrekturläsning och granskning av experter. Vem är syndabocken? Att jag själv inte hade tillräckligt bra koll på hur bilder måste behandlas för att de ska se bra ut i en tryckt bok sa jag redan från början till min förläggare. det löser sig sa han, vi tar in ett proffs som sätter boken. Hon kommer att säga till om dina bilder inte duger, trodde han ja! Antingen visste hon inte vad som dög eller så visste hon inte att hon skulle berätta det för mig eller så antog hon att det hon fick var det slutliga som inte gick att ändra. Resultatet blev följande:

1- Jag skapade bilderna i Visio eller Powerpoint och sparade dem sen som GIF eller JPG på ett som jag tyckte likvärdigt sätt - uppenbarligen inte tillräckligt bra i vissa fall, men helt OK i andra - märkligt!

2 - Dessa bilder fanns i början i ett Worddokument som jag tyckte såg helt OK ut vid utskrift

3 - Nästa steg var att all text separerades från bilderna och boken sattes i ett speciellt redigeringsprogram.

4 - Vid sättningen försvann tabellformat, rubriknumrering, fotnoter, innehållsförteckning, figurtexter, index och annat kul autoformatterat.

5 - Resultatet blev ett antal granskningar innan alla dessa detaljer var på plats. Gransknngen skedde på en PDF-version där jag fick uttryckliga instruktioner om att bildkvaliteten i pdf-filen var lägre än den slutliga så bilderna uppfattade jag att jag skulle strunta i

6. Slutligen då, en dag före tryckning, meddelar tryckeriet att vissa bilder - inga specifika nämnda utom ett par som byttes ut - hade för låg kvalitet och skulle bli dåliga. Hmm, lite väl sent att göra om allting då.

Slutsats: Tråkigt men sant, jag tyckte att jag gjort vad jag kunde. Vad tänker jag på inför nästa gång, nästa version? Ja då plockar vi in ett nytt proffs men den här gången träffas vi och kommer överens om vad vi förväntar oss av varandra. Så att jag vet vad som krävs av mig och han vet vad vi vill ha. Sen kräver jag att få en slutlig version att granska som är av samma kvalitet som det slutliga trycket. Om det lyckas bättre då, det får vi hoppas. Hade inte förstått alla komplikationer det innebar att ge ut en bok. Vem syndabocken är spelar mindre roll, det är jag som får lida för det och ni som irriterar er på de (som tur är ganska få) - bilder som inte är av perfekt kvalitet.

Med stor spänning sprättade jag upp den första bruna papplådan från tryckeriet i Borgå. Finnarna höll sitt löfte och skickade en extra sänding nytryckta böcker direkt till Bonnier konferensavdelning i god tid till SASTs kvartalsmöte. Det kändes både underbart och lite overkligt att äntligen hålla ett exemplar av boken "testdesign för programvara" i handen. Det hann bli många kvällar och helger framför datorn med oändliga korrekturläsningar, omstruktureringar och rättningar. Jag har haft förmånen att ha en granskningsgrupp med bra variation som gett mig konstruktiva kommentarer och del huvudbry. Ett stort tack till hela gänget, utan er hade det inte blivit så bra som jag tycker det blev.

Boken

För ovanlighetens skull fick jag stå på scenen och prata om test istället för att presentera andra talare. Ämnet var kanske inte helt oväntat testdesign. Jag ifrågasätter hur vi arbetar och om våra kunskaper om test verkligen är tillräckliga. Även om vi är duktiga finns det stora möjligheter att bli ännu bättre. Första steget är att lära sig mer om testdesign det andra är att ändra attityd och bli mer analyserande istället för att klaga över dåliga underlag. Jag säger inte att vi testare ska ansvara för att ta fram kraven men vi kan med analys och frågor hjälpa till att höja kvaliteten tidigt i projektet.

Boken fick ett varmt mottagande och inte mindre än 70 böcker såldes under dagen. Pablo på SolutionPoint slog till och köpte 20 böcker att delas ut till samtliga anställda plus plus ett par i reserv. Självklart hoppas den nyblivne författaren att fler följer hans exempel. Beställ idag på www.uppkopplat.se/butik

Dagen avslutades med ett besök i isbaren för att underhålla vår gäst Andy Redwood som ställde upp och talade utan avgift. Vi fortsatte sen till Winjas där vi festade loss på ost och charktallrik i sällskap med några spanska viner från Pablos eget förråd.

/Tobbe