Syftet är uppenbart uppenbart

Bara häromdagen skulle jag använda lite lin för att få till en tät rörkoppling, och stötte på något som gav mig myror i huvudet. Av någon anledning var första steget som det var beskrivet i instruktionen, att börja på mitten av linet och linda det runt röränden för att försiktigt dra av rätt längd. Jag insåg att jag inte hade den blekaste aning om varför man skulle göra så, vad syftet var, och kan därför heller inte avgöra om jag gjorde rätt. Än så länge är det tätt.

Vad innebär det då? jag tänker att du kan inte veta om något är rätt eller fel innan du vet syftet med det. Det går nästan alltid att göra en generell bedömning utifrån sina egna föreställningar och idéer men att faktiskt veta om det är rätt eller inte är inte möjligt.

Ett annat exempel stötte jag på i somras när de skulle läggas takpapp. Till takpappen kom en mycket detaljerad och illustrerande instruktion som beskrev hur pappen skulle skäras i olika typer av skarvar. Vi skulle göra den enklaste typen av skarv och där med bara skära av en grad i nedre hörnet, det som skulle ligga under nästa våd av pappen. Det var inte knepigare än att vi skar en bit av kanten, ungefär som det såg ut på bilden. Vi hade också det generella syftet klart för oss; det har något med vattnets avrinning att göra. Problemet vi hade var att vi inte visste det exakta syftet men det skurna hörnet så vi kunde inte avgöra om våra hörn uppfyllde det. Hade vi skurit för mycket, för lite, för rakt, för krokigt? Helt omöjligt att bedöma. Allt vi kunde göra var att gissa.

Hade det varit exakt specificerat att hörnets sidor skulle vara 10×10 cm hade vi åtminstone vetat att vi uppfyllde kraven, men fortfarande hade vi inte kunnat göra en anpassning efter hur våra specifika förhållanden såg ut, eller om problem uppstod.

Seriöst alltså

– Ja, jag är ju certifierad inom ISTQB så det är seriöst och så.
Så presenterar sig en ny testare som efter många år inom supportverksamheten bytt linje och ska jobba med det här med mjukvarutestning. Och det är inte alls ISTQB-certifieringen som stör mig, det finns säkert något man kan lära sig där, utan det är sättet den används för att hävda kompetens. Och ganska snart visar sig mina farhågor om hur certifieringsutbildningen omsätts till praktik vara befogade.

‘Facit’ är rätt nödvändigt om man vill testa seriöst

Uttalandet kommer i mailform till mig och i övrigt efterfrågar detaljerad information om specifika rättningar i senaste versionen som ska testas.

Jag förstår vad som efterfrågas, men de två orden ”testa” och ”seriöst” sammansatta i ett påstående får mig att rysa och det börjar bubbla av irritation. Utloppet blir ett meddelande på Twitter, på sant digital knyta-näven-i-fickan vis.

Så vad är problemet?
Om vi hade haft facit för funktionen så skulle den inte behöva testas alls. Om något ska efterfrågas är det ett exempel på ett fall där vi vet att funktionen presterar som förväntat. Jag skulle kunna skicka fler exempel på när den fungerar som förväntat men det hade alltid funnits minst lika många till att visa.

Och vad hade gjorts med den beskrivningen? Testats seriöst? Jag gissar att alla mina beskrivna fall där funktionen beter sig som förväntat hade gjorts om till teststeg i ett testfall som verifierar vad vi redan vet. Hur seriöst det nu är?

Vad hade jag kunnat kommunicera?

Först och främst vad syftet med de här testerna bör vara. Väl därefter skulle det stå klart att någon som helst detaljering av större delen av rättningarna i fråga hade varit helt onödig

Obetänksamt beteende

I ett av Sveriges största motormagasin läser jag en krönika där författaren förklarar sin irritation över hur hans biltestande kollegor överanvänder körriktningsvisaren, blinkersen. Till krönikörens förtret ska det i tid och otid blinkas, även om ingen finns där för att tillgodogöra sig informationen. Författaren efterfrågar istället för detta automatiska beteende en tänkande bilförare som i varje situation avväger om signalerandet är överflödigt eller inte.
En tänkande bilförare låter bra men jag håller inte alls med om att en avsaknad av blinkande skulle vara signifikativt för en sådan! Jag ser att ett automatiskt beteende i handlingen att blinka gör att kommunikationen som blinkandet innebär inte uteblir i de fall den personliga bedömningen fallerar.

Att jag hade en så klar åsikt om bilförare fick mig att börja tänka på liknande fall inom test, där det också pratas mycket om ”den tänkande testaren”. Vilka situationer finns det ett automatiskt beteende inom testningen? Avgörande är att beteendets kostnad är försumbar men den möjliga vinsten påtaglig, precis som bilförarens blinkande; att blinka en gång extra handlar om att röra ett finger en liten liten bit (eller tummen om man kör Ferrari 458..) och det är säkert så att i många fall är handlingen helt utan värde men med chansen att den vid ett enstaka tillfälle bli värd enormt mycket.

Det visade sig inte helt enkelt att hitta ett sådant beteende men ett förslag jag fick var att alltid buggrapportera. Även om en bugg åtgärdas omgående och i samförstånd inom ett utvecklingsteam kan det vara värt att lägga en liten stund på att loggföra buggen. Just i stunden känns det onödigt; vem skulle vara intresserad av den informationen?, men det möjliga värdet kan växa antingen i ett enstaka tillfälle eller över tid.

Checklistan

Synen på vad en testare är kan ibland vara lite skev, speciellt om man inte någon gång förklarat ordentligt vad en testare gör eller kan göra i ett projekt. Det blev tydligt när två olika checklistor anlände till mig från utvecklare och andra oroade projektmedlemmar. En var en checklista med saker att kontrollera för att säkerställa att frontendkoden; html-markup, javaskript, css och allt som hör därtill, håller en förväntad hög lägstanivå. En bra lista med vettiga punkter att kontrollera. Min panna rynkades.

Nästa lista att dimpa ner var en SEO-lista men punkter att kontrollera för att säkerställa att optimiseringen för sökmotorer håller en tillräckligt hög nivå. Min panna rynkades ytterligare..

Det är jättebra att få listor på punkter som olika kompetensområden anser utgöra grunden för god kvalité inom det området. Vad som gjorde att pannan rynkades var uppenbarelsen av bilden av en testare som någon som har tid till att sitta och kontrollera att saker blir gjorda. Det engelska yttrycket Quality assurance svepte in över mina ögonbryn som vid det här laget rynkades ikapp med pannan.

Ganska snart fick jag yttrycka mina farhågor att test sågs som en kontrollinstans snarare än en värdefull medlem i teamet. Och visst var det till stor del mitt fel. När test-insatserna i vissa projekt blir för korta riskerar, eller tenderar, de att likna kontroller mer än egentliga tester.

Hur löser man problemet?
I första hand handlar det i mitt fall om att bättre kommunicera vad en testare gör, att tydligt beskriva vilken kompetens en testare har som inte finns i teamet annars och hur en testare kan hjälpa teamet framåt och i kvalitetssäkringsarbetet, som ju är hela teamets ansvar.
För visst kan jag sitta och gå igenom checklistor om det är det teamet tillsammans tycker att de behöver, men då måste alla också vara medvetna om vad man byter bort och att jag inte kommer tycka det är det minsta roligt.

Så, vad är det jag vill ha ut?
Att test måste hävda sin kompetens, visa och förklara och räkna inte med att alla förstår vad du kan och vill göra. Så blir arbetet roligare och uppgifterna mer givande för alla parter.

Textdata

När jag utforskar en ny webblösning går en hel del tid åt att skapa testdata, att generera innehåll som fyller databasen med vettig och rimlig data. Det har i mitt tycke alltid varit värt tiden att inte bara skriva in ett antal tecken på måfå i till exempel brödtextfältet. Inte så att jag aldrig använder ‘asdf’ som testdata, men jag gör det med måtta och för vissa fall.

Det finns hjälpmedel för att skapa testtexter, dummytexter, i olika längder och formatering. www.slipsum.com är en av de roligare och fillerati.com en personlig favorit, innan stödet för svenska försvann. Alla har dock två problem, de är placerade för långt bort, flera musklick, och de är inte på svenska.

Avståndet är avgörande eftersom jag måste upprepa klickandet väldigt många gånger. Att det inte är på svenska är ett problem när jag testar webbplatser som ska bara ska visa svenska, det kommer inte att indexeras korrekt i webbplatsens sökmotor. Om jag ändå skapar en massa information för sökmotorn att indexera så är det rimligt att skapa information som kommer behövas när indexeringen väl ska kontrolleras.

Till exempel fick jag ta del av en felrapport där allt indexerat data hette ‘test’ i olika former, ‘test, ‘test1’, ‘test2’, ‘testing’, osv. Sedan hade man sökt efter ordet test och undrade varför sökresultatet uppvisade ett visst beteende. Beteendet var faktiskt inte alls fel utan helt korrekt eftersom det inte finns ett svenskt ord eller böjning som motsvarar ‘test1’.

Att hitta på exempeltexter för allt innehåll jag kan behöva skapa på en dag är vissa dagar mycket inspirerande och roligt, det är säkert många som dragit på munnen när mina mer fantasifulla texter, rubriker och namn dyker upp. Andra dagar är det bara frustrerande. Så jag byggde ett litet hälpmedel, ett skript till Autohotkey.

Autohotkey är ett finurligt program som jag använt till mycket olika saker genom åren. Tidigare har jag använt ett enklare skript för att generera textsträngar av bestämda längder bara genom att skriva ett kodord i det fältet jag vill fylla i; t1024 ger mig en textsträng som är 1024 tecken lång, t255, 255 tecken osv. För bättre flexibilitet vill jag kunna skriva vilken längs som helst och få ut just en sådan textsträng, så efter lite trixande kan jag nu skriva ‘xtext’, sedan ett nummer och enter och vips har jag en textsträng i urklippshanteraren som är så lång som det nummer jag angav!

Texten hämtar jag just nu från en textfil som innehåller stycken ut Viktor Rydbergs Singoalla, vilket ofta ger väldigt högtravande men underhållande textstycken. Det är roligare att söka efter ‘ungdomsfägringen’ än ‘testdata 123’.

Den bäste testaren

En svår fråga kan ibland bli lättare att svara på under press, när man inte lägger ner alltför mycket tankeverksamhet på att formulera och veckla ut alla möjliga frågetecken i ett svar. Så var fallet när jag fick frågan;

Vad skiljer en bra testare från en utmärkt testare, en sådan man bara måste jobba med?

Efter en kort, för att vara jag, betänketid svarade jag att det som skiljer är förmågan att dela med sig. Och efter att ha funderat  på svaret så känner jag mig ändå nöjd med svaret. Många är duktiga på att hitta fel och utföra sin uppgift som testare i sin specifika kontext men den som skiljer ut någon man verkligen måste jobba med är just förmågan att förklara och beskriva vad man gör.

Den riktigt duktige testaren kan identifiera tekniker och angreppssätt och sätta ord på dem för att föra kunskapen vidare.

Avbryt för att starta

Inte långt ifrån Stockholms stadshus finns en stor stenbyggnad som huserar Stockholms stads utbildningförvaltning. Här har jag spenderat en hel del tid den senaste månaden och bland annat gjort små utflykter till pentryt som finns placerat på varje våning för att stilla törsten efter kaffe. På ett av borden fanns här, förutom en utskriven tidningsartikel rörande hur negativt arbetsplatser i öppna kontorslandskap påverkar kreativitet, en något lustig instruktion för hur diskmaskinen fungerar.

  1. Lägg i diskmedelstablett
  2. Diska på program B
  3. Tryck på knappen Avbryt för att starta

Jag blir såklart lite nyfiken på hur den här maskinen egentligen är konstruerad, vad är det man avbryter när den ska börja diska? Står diskmaskinen och simulerar vädermodeller? Då vill man ju inte avbryta!

En närmre titt på diskmaskinen avslöjar hur det ligger till. Maskinen har tre knappar och ett vridreglage. Ovanför varje knapp är en symbol utskriven; en trekant som brukar betyda Play, en knapp som nog betyder något med ekonomisk tvätt och en knapp för fintvätt (ett begrepp jag inte förstår mig på i diskmaskinsvärlden).

Det är inte helt ologiskt att det är knappen med trekanten som sätter igång maskinen, Play. Så varför står det klart och tydligt ”Avbryt” i instruktionen.
Jag föreställer mig att någon gång sedan den här maskinen med det förmodat enkla användargränsnittet installerades i pentryt på utbildningsförvaltningen har behovet att avbryta diskningen uppstått. Det finns ingen stopp-knapp bland de tre knapparna! Här har någon förmodligen läst sig till, eller frågat någon servicetekniker, hur man gör; man trycker på Play igen.
Driftigt nog tejpades snart en lapp upp under play-knappen med texten Avbryt. Problemet löst!Nä, problemet förflyttade sig nu till att ingen vågade trycka på play-knappen, det står ju klart och tydligt Avbryt under! Dessutom har trekanten som ska påminna om Play långsamt nötts bort till oigenkänlighet.

Jaha, vad gör man nu då? Det går inte att ta bort klisterlappen, då kommer ingen att förstå hur man stänger av maskinen. Nä, det är bara att skriva en tydlig instruktion, köpa in en sådan där smidig anslagshållare i plast och ställa i närheten av maskinen. Till stor glädje för mig!

Det här är ett underhållande exempel på fler saker; hur ett löst problem alltid orsaker ett nytt oförutsett problem, eller att det är svårt att förutse hur produkten kommer att användas när man sitter och designar, utvecklar eller testar. Enkelheten i tre knappar kanske verkade briljant men visade sig vara otillräcklig för målgruppens behov. Förmodligen hade man inte ens koll på målgruppen i det här fallet och gjorde valet att använda symboler istället för text för att kunna nå fler marknader.

Fel eller dåligt testfall

Bland de välkända svar som ges till svar på en testrapport ligger

Men så där kommer aldig någon användare att göra

bra till för ledarpositionen. Testfallet man utfört anses inte relevant eftersom det bara är klåfingriga och desperata testare som någonsin skulle få för sig att göra något liknande och alltså är det ingen bugg som är värd att fixa.

Idag läser jag på svt.se om mannen som lånat ut sin ”smarta” telefon till sitt barn. Förmodligen, liksom så många andra föräldrar idag, i syfte att avleda och lugna. Telefonen, med sin färgglada skärm och audiovisuella feedback, är ofta räddningen för att slippa gråt och skrik. Problemet visar sig när pappa får tillbaka telefonen och den är låst i 42 år framöver efter att simlåset skrivits in fel gång efter annan.

Ok, är det någon som ser vad jag ser? Ett testfall som förmodligen hanterats enligt ”det där kommer ingen att göra” vilket leder till en bugg som nu gör telefonen oanvändbar inom rimlig tid.

Algoritmen för att beräkna tiden att låsa telefonen är helt klart felaktig, eller utformad enligt den amerikanska straffskalan kanske, och anser man inte att den är fel så måste det byggts in något sätt för supportavdelningen att hantera en liknande låsning. Att vara tvungen att köpa en ny telefon känns inte rimligt.

Som grädde på moset så skyller den norske skojaren som tillfrågats att kommentera artikeln på användaren!

Agil test på Agical

Agil test har en lockelse sv år att motstå, grundad i en viss mystik och allmän förundran, kanske förvirring. Så när jag fick en inbjudan av en arbetskamrat att följa med till Agical för ett kvällssemiarie om Agil test var det inte svårt att bestämma mig för att tacka ja, trots att kvällen var en måndag. Och förväntingarna var höga. Äntligen skulle jag få höra någon prata om agil test så att jag äntligen kunde förstå varför det är sådant ‘buzz’ kring det!

Jag var den enda testaren i rummet, förutom seminariehållaren. Resterande publik en skara som till större delen utgjordes av utvecklare i en eller annan form, jag vet det eftersom en snabb handuppräckning avslöjande fördelningen. Det visade sig också att seminariet främst riktade sig till den stora publiken, vilket man ju inte kan klaga på men också innebär att för mig var innehållet något klent.

Själva seminariet visade sig ha vissa poänger men skyndade i min mening lite väl snabbt förbi själva huvudämnet för att diskutera test i allmänhet och automation som hastigast.

– Jaha, så det innebär att det pratades om agil test utan att fokusera på automation?

– Precis!

De två är inte nödvändigtvis likställda, det ena kräver inte det andra. Istället handlade det om att involvera testaren under hela utvecklingsfasen, till exempel genom att sitta bredvid en utvecklare och bidra med kritiskt tänkade och testfallsgenerering i stunden. Det kräver dock viss flexibilitet i budget.

Det pratades också om att testa tidigt, att testa små delleveranser.

Är bara ett inputfält klart så kan jag testa det

En idé som inte är ny men är svår att få att fungera praktiskt. Ett krav för att kunna arbeta så är dock att planeringen av kommande arbete tänker i testbarhet. Hur ska vi planera uppgifter för att tillåta test så tidigt som möjligt? En tanke som diskuterats i vissa projekt jag varit delaktig i men som jag inte fått att flyga. Främst för att de tidiga testerna inte gett tillräcklig utdelning utifrån den extra insats som krävts. Men det är helt klart något värt att fundera vidare kring, det kan vara nyttigt för ett team att planera på det sättet. Dessvärre missade jag chansen att fråga efter konkreta exempel.

Jag gillade också verkligen att idén togs upp att aktivt medverka under sprintplaneringar och inledande utveckling genom att bistå med testfallsplanering och en frågande attityd. I många fall är det förmodligen det som saknas.

Över huvudtaget tror jag att testarbetets ”runtomkring-funktioner” underskattas. Mycket av det arbete en testare utför behöver inte nödvändigtvis vara av testfallsexekveringsart. I ett team tillförs mycket genom att någon ställer de obekväma frågorna, granskar funktioner med ytterligare en vinkel, ställer krav som mer syftar till ett, i stunden, internt intresse; vi måste ha en testmiljö, vi måste ha ordning på vår versionshantering, vi måste tänka på att bygga testbart.. osv.

Sen hade seminariet vissa svaga punkter. Det märktes att automation mest presenterades för att publiken ville höra det, ingen egentlig erfarenhet eller poänger låg bakom. Och det var också den delen som väckte mest frågor, föga förvånande.

Det dök också upp en fråga kring skalbarhet i test. Jag hade lite svårt att förstå vad frågan egentligen var men kommer förmodligen få komma tillbaka till det senare eftersom jag var tvungen att haspla ur mig ett något aggressivt svar: dubbelt så mycket kod betyder inte så många testfall!

Positivt fel

Ibland är det viktigt att läsa texten och inte lita på de visulla ledtrådarna. Det här felmeddelandet mötte mig när jag följde en länk till ett engångslogin jag fått i mailboxen.

Det är ju i alla fall positivt!


Klicka på bilden för att se hela