onsdag den 19. februar 2014

Hvad laver en tester?

Skrevet af Bolette

Ofte sker det, at jeg skal præsentere mig for nye mennesker og bekendtskaber, og hver gang hopper mit hjerte en lille smule, fordi der sker følgende: hende jeg bliver introduceret til siger: ”Jeg er kommunikations- og marketingskonsulent”. ”Okay,” siger jeg, ”jeg er tester”. Pause. Og lige præcis hér kan jeg aflæse, at hun ikke ved, hvad det er, jeg har sagt. Ikke at hun ikke har hørt mig eller ikke forstår ordet ”tester”, men hun ved ikke, hvad det er. Jeg krymper mig altid en lille smule, om det er på egne vegne eller på mit fags vegne, er jeg ikke helt klar over endnu, men jeg har bare altid drømt om at være i en profession, hvor det ligesom var selvsagt, hvad jeg lavede, når jeg arbejdede. Altså sygeplejerske, læge, programmør eller noget der ligesom gav sig selv. Men når jeg siger, at jeg er tester, bliver der stilhed. Langt de fleste ved ikke, hvad de skal sige eller spørge om, og selv mine kloge højtuddannede veninder og familie med mange års erhvervserfaring indenfor ingeniørfaget ved ikke, hvad de skal sige.

Jeg er nået frem til, at det kan være to forskellige scenarier, der udspiller sig. Det første er, at de ikke interesserer sig for mit arbejde. De holder af mig og vil gerne dele en masse ting med mig, men lige præcis dét der med arbejde (specielt når det er test), det siger dem ikke så meget. ”Hvordan går det ellers?”, spørger de.

Nu er det bare sådan, at jeg elsker mit arbejde og jeg synes test er det mest fantastiske arbejdsområde i verden, så jeg har svært ved at acceptere, at de (veninder, familie, kollegaer) ikke også synes, det er virkelig interessant. Og dette får mig hen til det andet scenarie: De ved ikke, hvad en tester laver. De ved ikke, hvad det vil sige at være tester, og de ved slet ikke hvad test egentlig er. Og hermed til formålet med dette indlæg:
 Til alle jer der ikke synes test er til at forstå, eller godt vil have det forklaret på en lidt lækker (Ryan Gosling-agtig) måde, here goes:  
  • Meget bredt: En tester undersøger verden
  • Bredt: En tester undersøger bestemte forhold i verden
  • Mindre bredt: En tester undersøger hvordan et produkt er (eksisterer, opfører sig, kommer til udtryk)
  • Snævert: En tester undersøger et produkt, som fx kunne være en malebog, ved at anvende og observere den
  • Konkret: Gennem konfiguration, anvendelse og observation vil jeg evaluere malebogens opfattede kvalitet for købere/kunder





Før jeg kan gøre dette, skal jeg have en idé om, hvad der er afgørende for kunderne og hvem kunderne er af denne malebog. Uden at have talt med nogle eller alle kunder gætter jeg på, at vigtige kvalitetskriterier er: brugbarhed (kan jeg rent faktisk tegne og male i bogen?), robusthed (går den nemt i stykker, nedbrydes den af farven), brugervenlighed (malebogen kan bruges med det samme, uden oplæring eller introduktion), karisma (malebogen tiltaler sanserne), nytænkning (malebogen er unik, ny eller speciel) og glæde (er det sjovt at bruge malebogen?)Udover disse kategorier for kvalitet, er der valget af hvilke elementer/dele af malebogen, jeg vil teste, altså hvilken dimension jeg ser på – er det det fysiske udtryk, materialet, omslaget, siderne? Er det, hvad man kan med malebogen, fx er der variation over tegningerne, størrelse, områder man kan male? Er det hvordan, malebogen bliver brugt, altså er der forskellige typer kunder eller brugsscenarier? Skal man have bestemte farver eller underlag for at bruge malebogen? Skifter farverne i bogen over tid?

Endnu har jeg ikke hensyn til de mange faktorer der gør sig gældende for projektets baggrund. Normalt ville jeg forholde mig til hvilken mission jeg havde med at teste malebogen, fx hvem er kunderne, hvad forventer de af produktet eller hvis mening om produktet tæller/betyder noget. Eller jeg kunne spørge hvem kan jeg tale med om denne malebog for at lære mere. Ryan Gosling selv ville selvfølgelig ikke være af vejen, men er der andre lignende malebøger jeg kan sammenligne med? Findes der designere eller eksperter i malebøger jeg kunne konsultere? Har jeg adgang til dem, der har lavet denne malebog? Kan jeg stille dem spørgsmål? Er jeg alene om at teste, eller har jeg et team bag mig? Har jeg selve malebogen til rådighed, når jeg (og mit team) skal teste? Har vi flere eksemplarer? Hvor lang tid har vi? Har vi brug for bestemte værktøjer, pensler, farver, tuscher? Hvilken afrapportering er forventet? Skal arbejdspapirer afleveres eller kun testresultatet? Og i hvilken form?   


Når jeg har besluttet mig for hvilke kategorier og elementer jeg vil fokusere på, vil jeg gå til udførslen af selve testen på en eksplorativ, dvs. udforskende måde. Dette sker i korte sessions ved at udføre eksplorativ test, hvor jeg på forhånd har defineret en mission som kunne se sådan her ud:

Udforsk siderne i malebogenmed vandfarvefor at opdage problemer med papirkvaliteten

eller

Sammenlign tegningernemed fotografier af Ryan Goslingfor at opdage afvigelser fra Ryan Gosling IRL

...for at komme igang, og derefter - når jeg ved lidt mere - kan jeg komme på endnu mere værdifulde missioner.

Jeg ved ikke, om jeg har tabt dig, kære ikke-tester, men for at gøre en lang historie kort(ere): Man kan teste meget, men ikke alt, så mit arbejde er at undersøge et produkt så betydningsfulde mennesker (som er vigtige for produktet) kan tage informerede beslutninger (løst oversat fra interview med James Bach).

Hvad dette produkt er, hvad der skal undersøges og bliver undersøgt, hvordan dette sker – og hvem de vigtige og betydningsfulde mennesker er – det er lige præcis dét, der er det spændende ved at være tester. For det afhænger af den enkelte kontekst og af mig som tester (mine evner, nysgerrighed, og mod).

Jeg er glad for, at der er rigtig dygtige testere derude, som sørger for at medicinsk udstyr, flymotorer, elevatorer og andet livskritisk udstyr bliver testet. Det er i den tunge ende. Jeg er også glad for at test findes af lettere produkter, som kontorartikler eller gadgets. Og af Enterprise software til større virksomheder som jeg sidder med til dagligt.

Fælles for os testere er dog, at du roligt kan spørge os, hvad vi tester og hvordan vi tester. Jeg lover dig, at den næste tester, du møder, vil blive imponeret og overrasket over, at den normale og halv-pinlige pause efter den gængse introduktion bliver udskiftet med et ”Okay, så du er tester - hvordan undersøger du verden?”

tirsdag den 4. februar 2014

Problemet med testcases

Skrevet af Carsten

I mange år har jeg talt dunder imod brugen af ordet test case. Mange har stillet sig uforstående overfor mig og sagt: jamen....!

Ja, kan jeg svare, vi testere bruger test cases, for en test case er jo bare et check - et enkelt sted i tid og (system) rum, som vi afprøver værdien af. For os testere er det ligetil.
Det jeg opponerer imod er alle andre end testeres brug af test cases.

Jeg bliver deprimeret af at tænke over alle de gange en ellers velmenende projektleder har bedt mig om at sætte mig hen i hjørnet og skrive nogle test cases, eller bedt mig spørge en arkitekt, hvor mange test cases der nok skal laves. Det er forkert på så mange niveauer, at det er til at skrige over.

Som tester bruger jeg test cases som en tømrer bruger søm og hammerslag. Jeg bruger så mange jeg synes der skal til. Nogle gange bøjer sømmene, nogle gange rammer jeg ikke lige hovedet på sømmet. Så kommer der et hammerslag til, eller jeg skifter et søm ud - som tømrer. Som tester konstruerer jeg nye test cases hele tiden. Jeg er jo igang med at undersøge noget. Og jeg véd hvad jeg gør - jeg er en god tester.

Så derfor kan jeg ikke på forhånd sige, hvor mange test cases jeg skal lave før jeg er færdig. Jeg kan gætte, men givetvis vil jeg blive nødt til at tage nogle fra, og lægge nogle til og en del er måske alligevel ikke værd at udføre, eller kan slet ikke udføres. Derudover er der mange, som jeg kun vil udføre en eneste gang - for at følge analogien med tømmeren: når sømmet nu ér slået i, så er der jo ikke nogen grund til at gøre det igen.

Det opfattes ofte som ren rebelskhed ikke at ville tælle test cases, for så kan man jo ikke måle den daglige tilvækst / fremdrift / metrik. Mit bedste svar er: "så hold op med at bruge en liniær model. Udfordr digselv og brug en organisk vækstmodel istedet". For mig er antallet af checks jeg udfører ligeså ligegyldigt for mit resultat - den information jeg skal levere - som antallet af hammerslag, tømmeren udfører for at bygge et hus, er for den der skal bo i huset. Bare fordi man kan tælle ting betyder det jo ikke at det man når frem til kan bruges til noget.

Hvis jeg absolut skal tælle test cases havner jeg nemlig i samme problem som drengen der skal gøre op, hvor mange stykker legetøj han har. En bold, det er en. En ishockeystav, to. Modelbiler, så er vi på fem. Brio-togbane, hmmm.. er stationen noget der skal tælles for sig - er vognene, eller er det bare en bane og et tog, eller et stykke legetøj ? Og hvad skal det i det hele taget også bruges til? Er det ikke fløjtende ligegyldigt om der er tyve eller hundredogsyvogfyrre?

Nogle gange er det rædselsfuldt at bevidne brugen af liniær logik i et projekt. Som dem der havde næsten totusinde prædefinerede test cases, som de ikke gik igang med, alene fordi de havde regnet ud at med den planlagte gennemsnitstid gange antallet, divideret med antal testere - og så holdt op imod de få uger de havde tilbage inden deadlinen, så kunne de ikke nå at blive færdige. De havde simpelthen snookered sig selv, med meningsløs logik. For der var jo tid: det behøvede jo da ikke være alt eller intet. De vidste jo ikke engang om de totusinde test cases var de rigtige! De kunne jo have startet med at sætte en enkelt tester hen i en time eller to og se hvad der kom ud af det. Så  kunne de have fået en idé om, hvorvidt systemet virkede bare nogenlunde, eller om det var helt til hest. Nogle gange kan det være svært at se lyset for bare tælle.

Når andre end testere begynder at se på test cases som et produkt i sig selv går det ganske enkelt galt: for et systems evne til at fungere kan på ingen måde udtrykkes fornuftigt i form af test cases.
Så fjern fokus fra test casene, og flyt det over på dét du egentlig gerne vil vide noget om.