mandag den 19. januar 2015

Vi har været tavse længe og det er fordi vi overvejer hvordan vi skal bringe bloggen videre. Måske med gæste-skrivere, måske på en helt anden måde.
Tak for tålmodigheden :-)

mandag den 10. marts 2014

Tag nu ansvar

Skrevet af Bolette

For et par uger siden læste jeg et blog indlæg af Katrina Clokie med titlen Own it og dette har siden rumsteret i baghovedet.

Kort fortalt handler det om at tage ejerskab og ansvar som tester, og Katrina har en vigtig pointe. Vi testere er alt for gode til at pege fingre: Det er udvikleren der har skrevet dårlig kode, der er ikke noget stabilt build at teste på (også kaldet et running target), projektlederen har ikke givet mig tid nok til at teste i, produktchefen har ikke tydeliggjort prioriteringer for mig, osv. Det er med andre ord alt, alt for let som tester at skubbe ansvaret fra sig og dermed over på andre i udviklingsafdelingen.

Men når jeg ikke skriver koden, ikke definerer hvordan produktet skal se ud, ikke bestemmer hvornår softwaren skal releases, ikke bestemmer hvilke bugs der er de vigtigste at få rettet – hvad bestemmer jeg så – og hvordan influerer det min følelse af ansvar og ejerskab? Mine opgaver er jo “bare” at undersøge, informere og oplyse om tingenes tilstand? Jeg bestemmer i sidste ende ikke særligt meget. Jeg kan give anbefalinger og gøre opmærksom på tingenes tilstand. That's it. Det er op til andre at tage beslutningen.

Og dermed er vi ved sagens kerne. For mit vedkommende hænger ansvarstagen og ejerskab sammen med muligheden for at have indflydelse og medbestemmelse på et produkt eller en proces. Og nu vil du sige ”Jamen det har du da også - de bugs du finder og de testplaner du lægger har betydning for produktets kvalitet.”

Har de det? Det faktum at jeg “kun” informerer, gør det ikke at jeg kan fralægge mig ansvaret, hvis og når produktet fejler? Er vi testere endt i en form for ansvarsløs rolle hvor vi ikke tør eller vil tage ejerskab og ansvar for produktets fejl og (manglende) kvalitet?

Hvad ville der ske hvis testere blev holdt ansvarlige for deres arbejde på samme måde som udviklere bliver det via bl.a. kode reviews, kontrol af kildekode og fokus på hurtig levering af funktionalitet? Måske er det en kliché, men hvem tester testerne? Jeg tror, at testere ofte kan skjule sig, fordi udviklere eller ledere ikke ved, hvad vi laver. Men jeg tror også, at hvis vi selv tog mere ansvar og åbnede op for review af vores daglige test arbejde og synliggjorde det, så ville det være de første skridt på vejen mod anerkendelse af test som en vigtig selvstændig disciplin, bedre produkter og givtigt samarbejde med udviklere og andre på projekterne. 
Måske vi også ville opleve større personlig tilfredshed i vores arbejde, og ja – undgå at føle os ramt af jokes som denne:

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.


søndag den 19. januar 2014

Om risici ved afholdelse af workshop

Skrevet af Bolette Stubbe Teglbjærg

Kan man lære af andres fejl eller kun af sine egne? Hvis du tænker du kan drage nytte af andres fejltagelser, så læs med her. Jeg vil gerne fortælle om hvordan man ikke afholder en workshop.

Fornylig afholdt jeg en workshop om risk assessment af udvidelsen af en applikation. For mit vedkommende var det første forsøg som facilitator af en workshop og jeg gruede lidt for det. Ikke fordi det var et svært emne eller nogle vanskelige kollegaer, tværtimod faktisk. Men af en erfaren kvinde indenfor branchen havde jeg fået påbud om, at jeg før workshoppen skulle være helt skarp på, hvad jeg gerne ville have ud af den og vigtigst af alt - være i stand til at formulere og kommunikere dette til deltagerne.

Måske på baggrund af dette påbud var jeg længe om rigtig at få fart på forberedelserne til workshoppen. Jeg ville gerne først lave en opdeling af applikationen i funktioner og komponenter, som vi så kunne tale ud fra. Jeg havde også en idé om at deltagerne skulle udføre forskellige opgaver i legoklodser eller modellervoks – indtil jeg blev spurgt hvordan jeg ville vise mit (test-) arbejde i modellervoks. Så blev den idé lagt på hylden. Med det samme.

Til sidst overvejede jeg helt at droppe workshoppen fordi der ”sikkert ikke kommer noget brugbart ud af det alligevel”. Heldigvis er jeg klog og livserfaren nok til at genkende en stor lysende advarselstrekant når jeg ser én, og det fik mig til at indse, at jeg blev nødt til at afholde den fordømte workshop uanset om jeg ville (turde) eller ej.

Jeg vendte tilbage til udgangspunktet og de basale spørgsmål: Ville risk-based testing give mening i dette projekt og hvordan griber jeg det i så fald an?

Projektet jeg er tester på blev fra starten af kendetegnet ved to ting. 1: Det er et risikofyldt projekt og 2: Det er vagt defineret.

Jeg er ene tester på dette projekt som er af relativ kort varighed, så derfor giver det mening at forholde sig til konteksten og spørge: hvis dette er et risikofyldt projekt, hvordan kan jeg bruge denne information til at fokusere og styre testindsatsen hen til dét der er vigtigt?

Jeg afholder en workshop, tænkte jeg. En workshop der har til formål at: i samarbejde at identificere mulige risici i det implementerede system og en vurdering heraf.

Opnåede jeg dette? Nej. I hvert fald kun delvist.

Var der gode lærepenge i afholdelsen af selve workshoppen? Ved jeg nu mere om, hvordan jeg skal gribe én an næste gang? Ja.

Der er risici ved at afholde en workshop. Og her er der 6 punkter der fortæller hvordan du ikke skal gøre:

  • Brug ordet risiko om dine kollegaers arbejde uden at forklare sammenhængen og baggrunden
    • Risiko er ikke et positivt ladet ord, så vær varsom med at sige, at der en risiko ved et stykke arbejde uden samtidig at forklare at det kan håndteres – at du har tænkt dig at gøre netop dette
  • Inviter alle udviklere i projektet
    • Som udgangspunkt vil de fleste softwareudviklere (som jeg kender) hellere kode end at tale processer, kigge på Excel ark eller PowerPoint slides. Hvis der er en ”lead” i projektet som godt kan lide at tale og kommunikere, så inviter ham/hende. Der er ingen grund til at slæbe alle de andre med. Invitér dem evt. som “Optional Attendees”.
  • Afhold workshoppen oveni en bunke andre møder
    • I starten af et projekt er der mange usikkerheder og uvisheder der skal afklares. De fleste søger at finde fodfæste samtidig med de gerne vil i gang med at kode. Hvis udviklerne har travlt og lige har været til en bunke andre møder, så er det måske ikke det rigtige tidspunkt at hive dem (alle) ind til et nyt.
  • Påtag dig alle roller
    • Du kan ikke både være facilitator, tester, skribent og procesleder. Og det skal du ikke forsøge at være. Uddelegér og vælg omhyggeligt dine medhjælpere til at udfylde de vigtige roller.
  • Undlad at gøre det tydeligt hvad målet og formålet med en risk assessment workshop er
    • Hvis deltagerne ikke forstår hvorfor de er der, eller hvad det er du gerne vil, så bliver det svært for dem at bidrage. Hvis workshoppen er til for at hjælpe dig i dit arbejde, så udtryk dette – også mere end én gang. Husk at takke dem for deres deltagelse.
  • Lav om i alle dine slides, Excel-ark, noter og andre papirer kort før workshop start
    • Din forberedelse til workshoppen er din basis, dit udgangspunkt og dét du ønsker at gennemgå med de andre deltagere. Lav det om i sidste øjeblik og du vil have trukket tæppet væk under dig selv, nærmest bogstaveligt talt.

Held og lykke med din egen workshop hvis og når du kommer dertil. Jeg glæder mig til at høre om dine fejltagelser, måske jeg kan lære af dem!


torsdag den 9. januar 2014

Ro, Rytme og Renlighed

Skrevet af Carsten Feilberg

Som udviklingsteam kan vi ofte komme til at referere til det system vi arbejder på som "vores lille baby" og bruge fraser der mest er kendte fra småbørnsfamilier ("skal holde i hånden", "små spæde skridt").

Et gammelkendt princip prædiket mest prominent af Sigrid Riise til nybagte børnefamilier er Ro, Rytme og Renlighed. Og i softwareudvikling og test af samme kan vi også finde anvendelse for disse tre grundpiller, der i årtier har domineret dansk spædbarnsopfostring.

Ro er vigtig, for uden ro er der ingen koncentration og intet overblik. Alting bliver derimod bare hektisk - alting vælder op i en: indkøb man skal huske, møder man skal nå (hvad er klokken egentlig), og jeg skal også lige have ordnet dether, og .. og .. og..

Med ro som udgangspunkt kan der skabes et rum til den aktuelle opgave, i stedet for panik, angst og usikkerhed, drevet af ydre omstændigheder ingen alligevel kan være herre over. Ro er selve det grundelement som skaber os en kreativ oase - ikke dårligt at huske på, i et kreativt fag som vores. Og alt hvad det egentlig kræver er, at vi sætter tid af til at sætte os med opgaven og kun koncentrere os om den. De øvrige ting skal nok melde sig på banen igen, hvis de er vigtige nok.

Rytme, eller regelmæssighed, er ikke altid opfattet som et gode. I en verden hvor der ofte stilles forventning til en om at være tilpasselig, dynamisk og fleksibel - hvorfor så have en rytme? Fordi regelmæssighed er med til at skabe forudsigelighed, og det har vi mennesker også behov for, ind imellem alt det fleksible. Selvfølgelig kan vi alle leve med, at et status-møde flyttes f.eks. en time. Men sker det hver dag, så møder aldrig bliver holdt på det tidspunkt de planlægges til, er den manglende rytme med til at skabe usikkerhed, spildtid og frustration (a la, "jeg kan ikke længere helt planlægge, hvornår jeg kan arbejde på de opgaver jeg har").

Rytme er med til at give forudsigelighed og plads til de ting vi skal.

Renlighed er måske en outsider, når man lige kigger første gang. Enhver der har haft en baby i hænderne er ikke i tvivl om relevansen af renlighed i dén sammenhæng, men i udvikling og test af software?

For mig at se er der en sandhed, som de fleste overser i vittigheden: "hvis et rodet skrivebord tyder på et rodehoved, hvad så med et tomt skrivebord?"
Ja, det er da sjovt, for ingen har jo lyst til at blive kaldt for tomhovedet. Men hold lige billedet af et tomt skrivebord op overfor de to ord vi lige har været igennem: ro og rytme?

Tomhed er ikke forstyrrende, som dynger af papir (som egentlig bare fylder op), brugte kaffekopper, cola-flasker, blyanter og kuglepenne, krummer og hvad jeg ellers i tidens løb har set på både mit eget og andres borde. Det bliver beskidt, støvet og skaber et uroligt billede.

Renlighed er den dyd, der gør at man kan bevare overblikket. Det gør at man kommer af med papirer, hvis relevans forlængst er væk: udprintningen af den C#-metode, der ikke virkede og som nu er skrevet om. Væk med den! Brugte kaffekopper og tømte cola-flasker. Væk! Mødeindkaldelsen fra mødet i sidste uge - som vi kun printede for at kunne huske hvor mødet blev afholdt, da agendaen jo alligevel ikke stod på den. Væk!
Systembeskrivelsen i sit enorme, uhandy ringbind, som blev udskrevet sidste år: Væk! (hvert fald: i det mindste over på hylden)!

Hvorfor skulle det ikke være lidt behageligt, lidt roligt, lidt lækkert at sætte sig foran sin arbejdsstation? Det er i orden at have papirer og ting omkring sig, imens man arbejder - men der skal ryddes op når opgaven er færdig. Ellers bliver ingenting jo aldrig rigtig færdigt.

Den sjoveste historie, som jeg har hørt om dette, handler om en kontor-medarbejder i militæret, der altid havde ryddet sit skrivebord når han gik hjem. Efter nogen tid blev det opdaget, at de ting han ikke nåede at blive færdig med, lagde han i en kuvert til intern post - adresseret til ham selv! Så kunne han næste morgen "starte på en frisk" ved at tømme sin indbakke.
En finurlig og morsom historie, men mest sjov fordi den indeholder et gran af genialitet: vi véd det er næsten snyd, og alligevel vil dette virke (omend intern post i en e-mail-verden, og dog .. men hvordan må du selv finde ud af). Humlen er, at han hver morgen kunne ankomme til et helt rent bord, hvor alting var klar til dagens dont.

Selveste Jamie Oliver har anført dette forhold omkring renlighed. I hans glimrende, omend selvtillidsnedbrydende, serie om "mad på 30 minutter" (hver episode varer lige omkring 23 minutter, just for show-off), starter han de fleste med ordene: "First, clean up your kitchen so you are ready to cook - then ...". Uden at være alt for udleverende kan jeg erkende at dét alene ofte vil tage 30 minutter. Især hvis man har børn i huset - børn af alle slags skaber rod - så vi må tage oprydning alvorligt, hvis vi gerne vil producere noget godt (indsæt selv: software/mad/...). Det hører simpelthen med.

Der er altså noget om det: renlighed er med til at skabe fundamentet for ro - og sørger vi dermed blot for lidt rytme eller regelmæssighed, kan vi lave vidunderlige ting sammen - med alle vores små "børn".
Prøv at tænke over hvor meget ro, rytme og renlighed der er i din hverdag...

fredag den 27. december 2013

Se dig (ikke) tilbage

Skrevet af Bolette Stubbe Teglbjærg

Da jeg for en måneds tid siden spurgte på Twitter om der fandtes en blog på dansk om softwaretest, var svaret nej. Min medredaktør ville dog gerne som jeg starte en, og så var vi pludselig i gang.

Vi startede med en diskussion af hvad bloggen skulle hedde, og mit forslag ”pragmatisk test” fik Carsten helt op i det røde felt og triggede bloggens første indlæg: ”Nej, vi kan ikke bare være pragmatiske”.

Når jeg ser tilbage på det sidste år, så forstår jeg godt hvor mit forslag  kom fra. Altså hvorfor jeg ønskede et mere pragmatisk fokus på test end dét jeg havde haft og havde oplevet hidtil. Fordi – for mig er pragmatisk det samme som praktisk, og det er lige præcis dét jeg gerne vil være. Jeg vil gerne ændre noget, jeg vil gerne gøre en forskel. (Senere kom bloggen som bekendt til at hedde Refleksioner over software test og -udvikling)

Jeg deltog i oktober i en fantastisk Master Class i Rapid Software Testing (RST) afholdt af James Bach. Før og efter har jeg læst og dyrket alt hvad jeg har kunne finde om alternativet til ISTQB, dvs. det Bach og hans kumpaner kalder Context-Driven Testing og RST.

Jeg er en stor fan af Bach. Så stor en fan at jeg tror denne Master Class i RST har ændret mit liv. Fra at være en ikke så stolt, men trolig ISTQB certificeret tester (bl.a. på Nokia i mange år) med en lille gnavende følelse af faktisk ikke at have styr på hvad jeg lavede – og have vanskeligt ved at retfærdiggøre det testarbejde jeg udførte - er jeg nu et sted i mit liv og i min karriere som tester hvor jeg virkelig er i tvivl om hvad jeg har lavet indtil nu. Den lille gnavende følelse har gennem Bach fået noget at vokse af og er blevet et fuldvoksent råb som stiller spørgsmål til tingene. For hvad har jeg egentlig lavet?

Da vi i sidste uge på arbejdet havde besøg af to dygtige russere, som heldigvis er blevet en del af vores testteam, og jeg udarbejdede slides der skitserede vores tilgang til test, dukkede tvivlen op igen. For jeg skrev, at vi er inspireret af den kontekstdrevne skole og at vi praktiserer Exploratory Test (ET) og Session Based Testing (SBT).  Dette kombineret med deres spørgsmål om testmetoder, prioriteter og kvalitetskriterier gjorde, at jeg endnu engang måtte se mig tilbage. Og her slog det mig så: Vi kan ikke forklare det! Vi tester som vi gør, fordi vi ikke ved hvad vi ellers skal gøre. Bach og andre der mestrer kontekstdreven test, ville more sig kosteligt over dette.  Eller måske mest af alt nikke genkendende til det.

Den kontekstdrevne skole er en ekstrem stillingtagen til verden. Til test. Når man først er gået ind ad den dør kan man ikke lade være med at stille spørgsmål – til alt. Alt hvad kollegaerne siger, andre testere siger, udviklerne siger, ledelsen siger, skal pludselig udfordres – og man er dermed også tvunget til at tage stilling til hvad man selv mener.

Det er også en relativ indadvendt og personlig proces at foretage dette paradigmeskift fra traditionel ISTQB-fokuseret test til den kontekstdrevne tilgang. Det starter som tanker og fluffy idéer. Det er svært at gøre det håndgribeligt og samtidig er test cases, templates og best practices lige røget ud til højre.

Det er tid til at tage stilling til hvordan jeg tester i hver enkelt kontekst. Derfor længes jeg efter det pragmatiske eller det praktiske. Efter at kunne svare på – hvorfor tester jeg? Hvorfor tester jeg som jeg gør? Hvad er det vigtigste at teste? Hvilken metode bruger jeg?

Når jeg ser tilbage på det sidste år, ser jeg ikke mange svar på de ovenstående spørgsmål. Jeg ser dog, at jeg ikke har forholdt mig kritisk, og på bedste sokratiske manér er det vel også dét, Bach og den kontekstdrevne skole gerne vil opnå, at vi testere udfordrer det givne, ser på hvad vi har gjort indtil nu og tager stilling til, hvad det er vi gerne vil fremover.

Så ved du, hvad du gerne vil?