Test automatisering: derfor skal du ikke starte med værktøjer

Læsetid: ca 6 min.

Test automatisering er noget man hører meget om i forbindelse med de agile projekter. Der er meget hype omkring emnet, og oplægget 5 ways automation is like sex fra sidste års Agile Testing Days er med til at bekræfter den teori:

Cassandra Leung:

In my experience, automation is a lot like sex in high school; everyone says they’re doing it but, in reality, most aren’t even close to starting. And many that are have no idea what they’re doing!

Fordelene ved at automatisere testen er ofte opvejet af omkostningerne ved at komme i gang. De succeshistorier, der bobler frem til forskellige konferencer, er ikke altid reproducerbare i den kontekst og organisation man sidder i. Man kommer nemt til at fejle, ved blot at prøve gentage “det de andre gør”. En af grundene til det i min optik handler om at man fokuserer for hurtigt på værktøjer.

At falde for fristelsen

Er man lidt teknisk mindet, vil synet af et nyt værktøj i sig selv være en oplevelse og give lysten til at kaste sig ud og prøve det. Sådan kunne det være, selv om der ikke foreligger en anden strategi bag end antagelsen om at det vil spare tid, hjælpe med at teste noget mere og gøre testen mere konsistent.

Så hvorfor skal man ikke starte med værktøjer, når man vil i gang med at automatisere testen? Der er i hvert fald mindst tre gode grunde, som alle er forbundet med en vis risiko for at:

  • det vil tage mere tid end forventet (og dermed får man ikke noget brugbart op og køre inden for den afsatte tid / budget).
  • det bliver sværere og sværere at vedligeholde det, i takt med ændringer til systemets krav bliver flere og større end man kan nå at få bugt med.
  • fejlene slipper alligevel igennem, selv om man har automatiseret test.

Det tager længere tid end forventet

Den nye spændende værktøj lover at man hurtigt kan komme igang. Måske er det noget som kan optage testforløbet ved at klikke rundt i systemet, eller en GUI til at lave test steps uden at skulle tænke på at skrive kode.

Alligevel støder man ind i problemet: test scriptet er ikke stabilt, ikke konsekvent eller mangler et redskab til at gøre noget specielt som værktøjet ikke lige understøtter. Et typisk eksempel her, er et script som kunne være optaget og eksekveres fint i en browser, men fejler hårdt i en anden:

tool-relative-locators.png

Måden som tool’et identificerer elementer kan være forskelligt, og nogle gange kræver det et know-how at vide hvilke elementer man helst skal interagere med for at det virker – også i andre browsere. Andre udfordringer kunne være håndtering af dynamisk UI (asynkron indlæsning), sikkerhed og måden at interagere med systemet. De mere avancerede værktøjer tager bedre hånd om disse problemer, men sjældent kan håndtere udfordring med dårlige test data eller testbarhed på en applikation, som er ikke bygget til at blive automatiseret.

Stik imod den oprindelige forventning kunne det ende med en erkendelse af, at værktøjet ikke kan automatisere de cases man gerne vil – efter at have brugt en del tid på det. En anden opdagelse man kunne gøre er at værktøjet stiller krav til den måde som applikationen er skrevet: både UI og kodestruktur. Det er noget man ville have haft fordel i at vide, før man kodede applikationen.

Det bliver sværere at vedligeholde det

Den nye og spændende værktøj lovede os det var nemt at komme i gang, og det kunne ske vi var heldige nok at komme igennem forløbet uden at støde ind i forhindringer. Testforløbet, der blev optaget eller kodet virker og resultatet er 0 fejl gang efter gang man kører det. Hurraaaa! Vi klapper os selv på skulderen, fordi det var jo også en succes.

Men så begynder der at ske sporadiske fejl.. Ting vi ikke havde forudset. Vores test data forsvinder. Serveren svarede ikke. Skærmbilledet vi tester nåede ikke at blive indlæst. Der er introduceret et popup-vindue i den seneste version, som vi ikke havde regnet med at se da testen blev skrevet. Vedligeholdelsen af test-scriptet er ikke en triviel opgave, og ej heller en sjælden affære.

Man når hurtigt til den erkendelse at det er nødvendigt at evaluere ændringer til testen samtidigt med ændringer til krav. Helst samtidigt, for ellers ender det som et efterslæb af teknisk gæld man får bygget løbende op. Netop mængden af gæld er det som kan ende med at dræbe den gode intention om at automatisere så meget som muligt.

En anden erkendelse her kunne være at god test design er mindst lige så vigtig som god test implementering – du kan sjældent få et godt resultat uden at have styr på begge dele. Et godt test design kræver at man kender sine forudsætninger: krav, brugerforløb og hændelser i systemet som kan forstyrre eller afbryde solskinsscenariet.

Fejlene slipper alligevel igennem

Endelig, så kunne man have sluppet igennem nåleøjet og nået dertil hvor test designet er solidt, implementering er stabilt. Testen kører, og rettes til løbende, så det svarer til de seneste rettelser i systemet. Men testen finder ikke de fejl som slipper igennem og opstår i ellers så grønne testforløb af en velsmurt Continious-Integration maskine. Hvorfor det?

Man kunne have taget de “nemme” test cases, som var hurtigt at komme i gang med men ikke rammer de vigtigste krav og scenarier, hvor fejlene ender med at opstå i. Det kunne også være fordi test forløbet er overfladisk, og ikke tester alle krav og kriterier i bund. Det er en falsk negativ test, der rapporterer alt ser godt ud – og man sidder derfor med tilsvarende falsk tryghed.

Det er jo ikke målet i sig selv at testen skal være grøn, men snarere at testen skal løbende give noget værdi!

Således kan vores iver efter at komme i gang med et test automatiseringsværktøj blive mødt af virkeligheden, hvor det er nemt at bruge en del af sin tid uden at få den ønskede afkast. Hvad gør man så for at gøre det rigtigt?

Et bedre sted at starte

Jeg tænker minimum de to punkter, som helst løses i bredt samarbejde på teamet:

1. At identificere og afgrænse problemet man prøver at løse. Nogle blogposts her og her kommer omkring noget så basalt som at sætte et mål, og kriterier for done (inklusivt cost/benefit analyse som grundlag for hvad kan betale sig at automatisere). Citat fra den ene blog som sætter det så fint på spidsen:

Jean-Pierre Lambert: The goal is not to simply automate tests. It is about writing tests specifically designed for automation. It is also about writing tests at the proper technical level to give enough confidence at the smallest possible cost: cost of writing, cot of running and cost of maintaining.

Punkt 1. er måske noget af det sværeste at lære, fordi erfaringen med vedligeholdelse af de forskellige typer af test kommer ikke på en gang.

2. At lave en analyse af forudsætningerne for at design og eksekvering af automatiseret test kan lykkedes med at give værdi:

  • Det funktionelle grundlag, i form af veldefinerede, velbeskrevne og identificerbare krav og deres risikovurdering. Alle relevante detaljer medmen også prioritering da ikke alt er lige vigtigt at automatisere.
  • Testdata, inklusiv test brugere og alle relevante test data. Det handler ikke blot om at have data, som at kunne have kontrol over de relevante test data som kan ændre sig over tiden og invalidere test resultatet som følge deraf.
  • Dedikeret testmiljø og konfiguration, som kan svare mere eller mindre til den ønskede opsætning. Delt testmiljø giver delte problemer.
  • Sammenhængen med de øvrige test, som foretages: alt fra manuelle, tekniske integrations- og API tests som kunne i princippet teste det samme flere gange.
  • Tekniske risici og krav til applikationen i forhold til testbarheden – applikationens evne til at understøtte forskellige former for test, inklusivt den automatiserede.

Mere om disse i de kommende blogs fra mig.

Samarbejdet på teamet omkring disse punkter er nøglen til at nå i mål med succes, da hverken problemet eller forudsætningerne kan være 100% klare for en-persons testautomatiserings-team. Hyppige ændringer i krav, design, UI og teknologi kan være nødvendige for at lave det rigtige produkt, men disse er nødt til at være reflekteret i koden som automatiserer testen, hvis det skal give værdi. På den måde sikrer man sig at kunne lave produktet rigtigt.

Reklamer

10 udfordringer som en agil tester

Efter at have rundet 6 år som en praktiserende agil tester, ser jeg ofte de samme udfordringer der går igen og igen. Det blev til en slags mental tjekliste for mig, som begyndte at tage form i løbet af det sidste år, når jeg startede med at bruge min erfaring som en rådgivende konsulent.

De 10 udfordringer viser sig at hænge sammen med nogle af de grundlæggende principper, der i virkeligheden er stykker af sund fornuft, der nogle gange udebliver af forskellige årsager.

De ting, vi siger til hinanden, når vi møder disse udfordringer, rummer ofte svaret på hvordan udfordringen er opstået – hvis man relaterer disse udsagn til de gode principper, som jeg vil opliste i denne artikel.

1. Gøre kvalitet til et fælles ansvar på teamet

At man kører projektet agilt er altså ingen undskyldning for ikke at teste! Som testere og QA ansvarlige er vi pionerer for kvalitet, og det indebærer at arbejde for at alle tænker kvalitet ind fra starten. Nogle gange lykkes det, andre gange ender vi alene med ansvaret.

Tid - Fælles QA ansvar
At der ikke er tid til test er ofte udtryk for, at der ikke er fokus nok på det. Er teamet enig i, at testen er en del af sprint målet og den samlede leverance?

“Testfaser” til sidst i sprintet, hvor alle defekter skal findes af testeren alene, er ofte udtryk for at ansvaret er placeret på et smalt sted.

Kvalitet - Fælles QA ansvar

At stå selv med ansvaret for kvalitet kan blive en tung og udmattende opgave for en enkel person, når hyppigheden af ændringer og fejl svinger meget. Måske kan teamet finde en fælles strategi – en QA-strategi – for at definere, hvordan alle kan bidrage med deres evner og kompetencer til testen. Strategien sikre at alle ved hvad de andre gør i forhold til kvalitetssikring, og denne information er meget værdifuld når det nogle gange går stærkt.

2. Skaffe den rette information på det rette tidspunkt

Arbejdet med afklaring af krav og udvikling foregår ofte i et andet tempo, når man kører korte iterationer/sprints. Man kan derfor opleve, at det er sværere at følge med i det hele.

Manglende viden - Kommunikation

Knap så megen dokumentation og viden der mest deles i forskellige samtaler, kan gøre det sværere at følge med i alle relevante detaljer og beslutninger.

Ideelt snakkede alle med alle på de rigtige tidspunkter, men når dette ikke sker, har vi udfordringen med manglende viden. Det er mindre kritisk på et team, hvor kvalitetssikring er et fælles ansvar, fordi der er en chance for, at nogen af de andre griber bolden. Alligevel kan viden om hvem, der har testet hvad, være nyttigt i det store perspektiv.

Fælles forståelse - Kommunikation

En anden side af det er forståelsesaspektet i de samtaler som finder sted på teamet. Et mangfoldigt team med både tekniske, analytiske og forretningsfaglige personer kan have et større spænd i deres fokusområder og faglige sprog. Tværfaglige teams forsøger at nedbryde siloer, men det kan stadig være svært at forstå alle aspekter af hinandens arbejde. Vi kan godt være eksperter i hver vores felt – QA/arkitektur/kodning – men vi er ikke alene om at bære ansvaret for kvalitet!

3. Kommunikere den rette information på det rette tidspunkt

Teamet har brug for hinandens viden for at være effektive. Det, vi kommunikerer ud, kan have afgørende betydning for succes med opgaver og projektet i helheden. Sagt med andre ord – jeg kan løse opgaven bedre og hurtigere, hvis først jeg taler med nogle, der har den rette viden og erfaring med netop den slags af problemstilling, som jeg selv sidder med.

Men i den gode tro, er det nemt at blive kloge-åge som rådgiver alle om alt, og måske slet ikke på opfordring.

Image result for kloge åge

Tanken er sikkert god – modtageren kunne få brug for den viden senere, men der er også risiko for information overload: Når vi prøver at sætte fokus på mange facetter og detaljer på en gang kan overblikket sløres, og det gør mere skade end gavn.

Set fra en anden side, kan vi blive for påpasselige med at snakke sammen. En Scrum Master kan blive så god til at afskærme folk, at de slet ikke må tale sammen uden en tilladelse.

Image result for network of people visualization

Det burde ikke handle om at minimere small talk, for det er ofte sådan folk opdager andre ved noget, som er relevant og spændende for dem!

Måske handler det om at få skabt en kultur hvor vi med tiden lærer hvordan vi bedst kan understøtte hinanden med den viden vi har, lige såvel som den bedste måde at overlevere den viden på.

4. At kommunikere effektivt og med respekt

Ud over mængden af kommunikation, er det også måden man kommunikerer på, som er afgørende. Det er især vigtigt, fordi agile projekter i højere grad afhænger af god og effektiv kommunikation og mindre overlevering af arbejdet, mennesker imellem. Vi kommunikerer altså mere med hinanden og sandsynligheden for, at det ikke altid går som smurt, er bare større. Det sker, når vi får sagt ting, som vi ikke mener, eller ikke har tænkt os om og bare lader os påvirke af øjeblikket og den situation vi står i.

Respekt - Kommunikation

God kommunikation kan blive sværere under tidspres, konstante forandringer og ikke mindst problemer af projektmæssige karakter. Når det sker, har teamet stadig brug for at kunne tale sammen effektivt og beholde respekten for hinanden, for at kunne klare de udfordringer der opstår.

Det siges at både afsenderen, modtageren, iagttageren og autoriteten har deres andel i at sikre, at den gode kommunikation bliver opretholdt. Det kræver at: afsenderen er klar over effekten af sine udmeldinger, modtageren kan sige fra, mens iagttageren og autoriteten som minimum bør blande sig når det gælder.

Nogle vil sige at årlig kommunikation på grund af stress og tidspres kunne være symptomer på helt andre udfordringer med samarbejdet i teamet, der starter med den måde hver enkel på teamet vælger at prioritere sin tid på.

5. At kunne prioritere sin tid og opgaver

I agile projekter hvor man arbejder sammen som et team, er det teamet og teamets mål som vægtes højest. Når man konsistent vægter egne opgaver og mål højere, løber man risikoen at hele teamet taber som en helhed. Man har altså større ansvar overfor andre, når vi sidder i samme båd.

Tasks - Prioritering

Sat på spidsen, betyder det at man hverken får point for ikke-testet kode eller forberedelse af testen der aldrig bliver til noget. Den daglige status belyser teamets fokus og udfordringer. Kunsten er at være i gang med de opgaver, som bidrager til at der bliver leveret mest muligt værdi i sidste ende. (Og ja det er en svær øvelse som de modne teams mester). I sidste ende er det bedre at få en del af pakken som virker helt, end at få hele pakken som virker halvt. Det er her den større grad af samarbejde viser sit ansigt.

6. At komme tættere på udvikling og kode

I stedet for at finde mange fejl til sidst, giver det langt større afkast at arbejde sammen på at gøre et godt stykke arbejde første gang. Tidlig test giver mulighed for at rette fejl billigere og hurtigere, men det kan give udfordring når det der skal testes er alt andet end noget man kan klikke på i brugergrænsefladen. Det kan være services, komponenter og kodestumper som returnerer talbaserede koder. Det kan også være datamodeller og databaser opsætninger, som kræver adgang og kendskab til værktøjer.

Tidlig test - Samarbejde

Ikke tekniske testere kan godt finde flere veje og måder at bidrage til den tidlige test, men kan med tiden indse fordele ved at have mere af det tekniske know-how. Det betyder i princippet også at komme tættere på automatisering. Gentagne opgaver, klargøring af test miljøer, oprettelse af test data og naturligvis også test automatisering kan være gode eksempler på situationer hvor det kan betale sig at kunne kode en smule. Imens andre koder features..

Men skal vi under enhver pris kunne kode for at være agile testere? Måske ikke.

7. At kunne tilpasse sig teamet og deres behov

Alle teams er forskellige, men specielt i de agile teams er der mindre fokus på roller. Opgavens art kan variere, nogle gange kan der være rigtigt meget test og alle skal hjælpe til med at teste. Andre gange er der for lidt og man må begå sig ud i andre typer af opgaver hvis ikke man vil sidde på sine hænder og vente på test opgaver.

Kompetencer - Team

Det kan resultere i at man selv lærer at producere sine egne test data, snakker selv med brugere for at bedre kan forstå deres adfærd eller skriver et selenium script til at teste den skrøbelige test case som altid bliver glemt eller ofte fejler. Vi kan blive mere effektive som et team når vi er mindre afhængige af bestemte personer til at løse en bestemt type af opgaver. Vi behøver ikke alle at være generalister, men chancen for at bidrage positivt er større når man kan andet end en bestemt kompetence!

Kigger man på teamets omgivelser, miljø / organisation og netværk af eksterne kontakter, finder man andre muligheder for at hjælpe teamet med at fungere mere effektivt.

8. Tættere og oftere samarbejde med forskellige roller og aktører

Ud over det daglige samarbejde på teamet omkring produktudvikling opstår der ofte behov for at arbejde tættere sammen med andre aktører udenfor teamet. Det kan både være nogle, som hjælper med en bedre forståelse af brugerbehov og adfærd. Det kan også være eksperter i forskellige former for test, eksterne leverandører og testere der understøtter den samlede leverance.

Indsigt - Samarbejde

Tættere samarbejde indebærer tillid, både i og udenfor teamet. Tilliden kommer som bekendt ikke på en dag, og organisatorisk ballast som mistillid mellem afdelinger, tidligere rivaler og erfaringer med kunder kan gør det sværere at få opbygget den mængde af tillid som reducerer behov for forhandling, kontrol og andre sikkerhedsforanstaltninger som følge deraf.

Vi bør som minimum være indstillet på, og have viljen til at investere i den gode samarbejde. Blame-game er nemt at falde i når man ikke ser sin andel i en verserende konflikt. Selv om mange af disse udfordringer ikke kan løses af enkelte personer alene, så er det lige som med MJ og Ghandi: start med sig selv og vær den forandring du gerne vil se hos andre.

Konflikter og dårligt samarbejde er uundgåeligt en af de større former for spild af tid, kræfter og ikke mindst ressourcer.

9. At minimere spild

Der findes flere måder at identificere og håndtere spild, lige fra Lean til Design Thinking og andre mainstream koncepter. Som en agil tester bliver man helt sikkert mærket af den større fokus på feedback og forretningsværdi i agile projekter, og det giver anledning til at kigge indad og revurdere de processer vi følger med kritiske øjne. F.eks. bruger vi for meget tid på de typer af test som ikke hænger sammen med risikoprofilen? Eller: Er niveauet for den dokumentation vi producerer den rette?

Dokumentation - Spild

Når vi ikke bruger vores tid rigtigt får vi mindre tid til andre ting og måder at støtte de opgaver som kunne været vigtigere at løse. Imens forretnings-impact er givet af backloggens prioritering, er det dog stadig op til vores analytiske evner og tidligere erfaringer at vurdere hvor er der størst sandsynlighed for at introducere defekter. Risikohåndtering i det hele taget er noget af den mest gennemgående aktivitet som man have berøring med som en agil tester.

10. Holde øje med risici på projektet

Klassisk risikoanalyse forud for, eller i projektets opstartsfase, er ikke tilstrækkelig på de agile projekter. I starten ved vi mindre om hvad vi ikke ved, og når vi bliver klogere dukker der som regel nye risici op som har betydning for mængden og typen af den kvalitetssikring som teamet kommer til at udføre.

Her er vi så tilbage til starten — QA som fælles ansvar. For selv om man som tester er klar over risici, er det da ikke sikkert man har mulighed for at få gjort noget ved dem alene, og man blot kan stå og se på korthuset vælte.

card-tower-fun-game

Kommunikation, samarbejde og fælles indsats, komplementeret af indsigt i produkt og projektrisici, giver teamet netop mulighed for at være agile – at kunne navigere i den komplekse virkelighed sammen og forsøge at gøre det mest rigtige på det rigtige tidspunkt.


Dette var de 10 udfordringer man kan møde som en tester på agile projekter. Har du kommentarer eller bidrag til ovenstående er du meget velkommen til at kontakte mig.

Udvikling med A/B og eksperimenter: det er mere end test af det grafiske

I sidste uge gav jeg et oplæg om A/B test og eksperimenter, som bruges af organisationer, der arbejder fokuseret med ideudvikling og modning. Det gav overraskende meget feedback og en god diskussion efterfølgende. Emnet er en del af det arbejde jeg har lavet med tidlig test (shift-left til dem,  der er vilde med buzz-words). Her kommer et uddrag af mine tanker om dette

Det er jo ikke noget nyt at ideen skal være god, før der skal satses mange kroner og ører i implementering. Forretningsudviklere, produkt-ejere/managere og lignende har netop fokus på at sikre gode ideer i backloggen. Alligevel, når man kigger på mange projekter, ikke mindst de offentlige, er der en del som går galt, da man ikke kan finde ud af at lave det rigtige produkt (eller kravspecifikation, om man vil). Der tales forbi, misforståelser og antagelser bliver til krav,  som bliver tolket forskelligt eller viser sig at være umulige at opfylde. Der er eksempler som Skats EFI, Rejsekortet i sin spæde start og ikke mindst politiets udskældte sagssystem, der siges at være fejlet af disse årsager. Så hvorfor skal det være så svært? 

Jeg tænkte primært på 2 ting, da jeg forberedt oplægget:

  • Det er ofte svært at definere de egentlige problemer, man gerne vil løse. Det er nemmere at kaste sig ud i den løsning, der allerede tegner sig i hovedet. 
  • Det er almindeligt at tolke en formulering på flere måder, alt efter hvem man er. “En funktion til indberetning af svindel” kan tolkes både som en Web Service og som et kontor med personale til kundeservice.

Så det at have en idé i sig selv er ikke nok, for det skal også være en god løsning. At finde frem til en god løsning er jo det man beskæftiger sig med i projekt-teams. Disse kan arbejde på hvidt forskellige måder og dette indlæg handler om dem, der ikke antager de har løsningen fra dag et. Det handler også om at man kan teste andet end software op imod et sæt af specifikationer.

Ideudvikling med eksperimenter

Når projektet starter, så er der oftest meget lidt indsigt i og forståelse af krav. I BDD litteraturen kan man læse om “Level of ignorance”, som er ret høj i begyndelsen. Man ved endnu ikke hvad man ikke ved.

Så måske er det ret naivt at tro ideerne til den rigtige løsning viser sig der. Det er kernen i den agile tankegang at man itererer, og bruger feedback loop til at vurdere om de  løsninger (baseret på ideer) har væsentlig forretningsmæssige værdi. Men hvad hvis vi ikke var i stand til at få den rette feedback lige med det samme? Sprint demo til 1 eller nogle få personer er jo ikke nogen garanti for at løsningen vil virke i praksis – under antagelsen om at en eller få personer kan nemmere tage fejl end mange. Ideudvikling er modning af ideer igennem feedback. Og siden brugere oftest ikke selv ved hvad de har brug for, er der andre måder at få feedback på end at spørge dem direkte. Et af dem er eksperimenter som A/B test.

what-ab-test

Generelt er ideen med eksperimenter er at konstruere en situation som skulle lede til et bestemt udfald (conversion, som det hedder i fagsproget). Et godt eksempel fra marketingsindustrien: hvis produktet ser nyere, friskere i farver og måske fremstår mere skarpt i designet er der flere som vil købe det. Dette er faktisk en tese – et postulat. Eksperimentet går ud på at bevise tesen er sand eller falsk ved at føre det ud i livet: man producerer en test-variant, og halvdelen af butikker sælger den nye variant så man kan følge med hvor godt den klarer sig.

På samme måde kan A/B test bruges til at teste produkter og features, og ikke kun farven på knapper og afstanden mellem inputfelter. Har man et produkt i forvejen, kan man eksperimentere med nye eller alternative funktioner, og måske også nye måder at arbejde på og interagere med systemet. Det kan der være rigtigt gode penge i!

Der findes flere værktøjer som lover fantastiske produkter og store besparelser, ved kun at udvikle de features, som rent faktisk fungerer hos brugeren. Dette kan være en sandhed med nogle forbehold – eksperimentet bør ikke være misvisende eller for dyr at konstruere.

Validiteten af eksperimenter

Når jeg skriver misvisende eksperiment, så tænker jeg primært på en situation hvor eksperimentets hypotese er opstillet forkert, ufuldstændigt eller hvor målingen af forventede resultater er meget upræcis. For eksempel kan måling være påvirket af andre faktorer end dem man havde udtænkt i sin hypotese.

Forestil dig en Web shop som farver alle knapperne gule op til jul. Man måler trafikken og der viser sig at være en stigning i køb på over 200%. Er det på grund af julegaveræs eller den gule knap flere købte mere?

I andre situationer kan der være faktorer som vi ikke opdager lige som nemt som juletiden og for at håndtere dette bruges der kontrol grupper. Netop dette er grundlaget for en A/B test, som ville jo fange tendensen i begge variationer og derfor kunne siges at være en mere gennemskuelig måde at eksperimentere på.

Det bør ikke være dyrt

Lige som marketing-materialet fra A/B test tools siger, er det billige i længden at investere i god brugeroplevelse. Man kunne lige så sige at det er billige at investere i gode ideer – og på sigt kan kontinuerlig investering i innovation betyde at man kommer på forkant med sine konkurrenter. Det er lige som med Apple der var helt rolige dengang Microsofts pendant til iPod kom på gaden – det var et bedre produkt her og nu, men de havde troen på at deres satsning på innovation ville vinde i længden. Det er altså fremtidstænktende og innovationsfokuserede firmaer som typisk går all-in på eksperimenter. Kigger man på de større firmaer, er det ikke uden grund der er investeret en del i R&D afdelingen.

hqdefault

Det at bygge og gennemføre en række gode og valide eksperimenter kan tage tid, og måske en hel del ressourcer og måske være dyrere end at lave 1 version af produktet man kunne satse på.  Hele humlen er at have stadighed, nerver og måske indsigt at blive ved, selv om ikke alle ideer er lige gode. Det vigtigste er at få gode ideer kan være en million gange mere værd end 1000 dårlige. Dette i min verden er den bedste tidlige test man kan udføre.

Heldigvis er der også gode erfaringer med at eksperimentere med ideer uden at disse er meget omkostningsfulde. Det må være emnet til et af de kommende blogs..

Hej så længe 🙂

Jeg ville teste robotten, men den endte med at teste min tålmodighed 

Revolutionen kommer, og hellere være klar til den end at sove i timen med håret i postkassen. Robotterne har bare at gøre vores liv nemmere og forandringen syntes at rykke nærmere. Ikke kun i version2 artikler, linkedin-publikationer og lign men også vor eget hjem.

En lidt lørdag morgen ville gøre noget jeg har drømt om længe – at overlade støvsugningen til den selvvalgte julegave fra shoppen som firmaet valgte at samarbejde med i år (derfor var hverken mærket, modellen eller specifikationen mit valg – selve muligheden at få en robotstøvsuger resulterede i et eksperiment).

Dette er ikke et produkt anmeldelse, så mærket og modellen er ligegyldig. Rent funktionelt har apparatet en lille grænseflade og en række tilstande den kan være i afhængigt af omstændigheder: den kan køre i cirkler, zig-zagger og andre mønstre for at dække det valgte områder på den mest effektive måder. Dette kunne man udfordre fra test perspektivet! Tænk nu hvis man kunne påvise den ikke var effektiv… Men dette var ikke målet med testen.

Skulle det vise sig apparatet ikke var effektiv nok, ville det ikke gøre nogen forskel. Jeg ville ikke kunne bytte den, og så kunne vi nok også leve med det. Den første “udforskende” pilot test har dog vist en interessant tvist.

Som nævnt er der få triggers som kan kan interagere med.

  • Tænde/slukke
  • Sætte den til opladning
  • Sætte den i ugyldig tilstand (så den ikke kan køre), f.eks på hovedet.

Bagsiden afslører at man ydermere kan pille batteriet ud, men så er det lige som det. Manøvrering og køreegenskaber kan testes i uendeligt mange situationer (og jeg skulle hilse og sige det går ret hurtigt med at finde situationer hvor den går i stå). Men hvad nytter det, hvis der ikke er strøm nok?

Test fokus

Opladning. Naturligt nok kræver det nok strøm til at kunne arbejde effektivt i nogle timer. Efter at have støvsuget køkkenet og gangen på sin jomfru tur, tog den sig en velfortjent pause. Næste gang jeg sad klar med en bog og en kop hjemmebrygget latte, ville banditten ikke køre mere en et par sekunder! En fejl lyd og rød blinken indikeret der var tid til lidt power.. Jeg synes det var lidt tidligt, for den har jo næsten ikke kørt i en time!!

Manualen. Teksten som skulle forklare mig den korrekte fremgangsmåde (som dermed kunne testes) var formuleret mystisk. Specielt punkt nr.5

Altså, sådan som jeg forstår det så tager det sammenhængende 4 timer for at apparatet er opladet 100%. Dog, hvis strømmen afbrydes undervejs vil den “always timing from zero automatically” — altså timeren bliver nulstillet og det begynder at lyse blot senere end sluttidspunktet for opladning. Lad være med at afbryde strømmen undervejs, siger den mere eller mindre, for så ved du ikke hvornår du kan afkoble adapteren med mindre du bruger et stop ur. (Husk nu at strømforbrug er en del af effektiviteten).

Så der har vi et par test situationer mere!

  • Opladning fra 0 til 100%, uafbrudt
  • Opladning fra 0 til 100%, afbrudt undervejs x gange
  • Opladning fra x til 100%, uafbrudt
  • Opladning fra x til 100% afbrudt undervejs x gange

Min årskavalkade 2017

Mens året nærmer sig sin afslutning, vil jeg bruge lidt tid på at kigge tilbage.bestof2017sofar

Denne blog begyndte jeg at skrive for lidt over halvandet år siden og det er blevet til flere indlæg der både handlede om at være tester i en agil verden og så lidt mere til. Mange af mine læringer og erfaringer lander her og bliver til refleksioner, ideer og koncepter. Nogle af dem bliver til virkelighed og resulterer i større eller mindre forandringer. Blandt dem jeg vil fremhæve:

  • Jeg har kastet mig for alvor over BDD og lavede et oplæg til Sogeti Capgeminis Testing Tuesday i starten af 2017.
  • Året blev også slutningen på min karriere som agil tester hos eBay, da jeg har fået jobbet som Agil coach og underviser hos Testhuset. Her fortsatte jeg min fokus på BDD og i fællesskabet med andre dygtige og erfarne undervisere udviklede vi et decideret BDD kursus og fik gode tilbagemeldinger på det efter at have afholdt det flere steder.
  • Jeg gik også dybere ind i teorien med agil test. ISTQBs agile extension gav en klassisk teoretisk oplevelse, på samme måde som det var med Foundation. Senere tog jeg også CAT og er nu den 6 person i Danmark som kan og må undervise i det 😉

CAT

http://www.agile-teaming.org/trainer-of-cat-certified-agile-tester.html

  • 2017 blev også året hvor jeg har sat fokus på agilitet og dennes anvendelse i software udvikling. I min rolle som agil coach har jeg arbejdet med kunder og deres cases og har fået nogle spændende erfaringer: lige fra valg af test management tool til QA strategi på agile teams — emnet var interessant nok til at blive til en kort artikel skrevet som en opsummering af erfaringer og overvejelser omkring det.
  • Motivation og kontinuerlig udvikling har også fyldt mine tanker og blogs en del: jeg skrev om at finde sin vej og veje til success, inspireret af tanker fra Simon Sinek og Toyota Kata. Disse tanker fandt også anvendelse i mit arbejde som agil coach, hvor jeg har kigget på måder at skabe motivation hos agile teams. Motivationsteorien og ikke mindst praksis står øverst på todo-listen i 2018.
  • I flere måneder har jeg været en del af flere agile teams og fået lidt jord under neglene med både praktisk test, test automatisering med webdriver.io og test management. Disse erfaringer gav uundværlig empirisk baggrund for at kunne summe og fundere over det med at arbejde med QA i agile projekter. Erfaringer viser at tekniske kompetencer har en større efterspørgsel end manuel test, hvorfor jeg tror at vi kommer til at se færre dedikerede manuelle testere på agile projekter, hvor QA og test fungerer i praksis som et fælles ansvar.
  • I løbet af året talte jeg med flere som fungerer i det daglige som agile testere.  Jeg gravede dybere i at forstå hvad agilitet egentlig for en størrelse da test og QA eksisterer jo altid i en kontekst. Det gav mig bedre indsigt i hvilke kompetencer og evner bidrager bedst til den agile kontekst samt har ført mig til at fokusere mindre på værktøjer og metoder som Scrum og mere på det agile mindset.
  • Sidst på året lavede et oplæg om hvad agil tester er for en størrelse, set i kontekst af ovenstående. Det fortsætter jeg nok med at kigge på og blogge om i 2018 🙂

Poul-Sørensen

Ny artikel om QA strategi på agile teams

For noget tid siden skrev jeg en blog om, hvorvidt QA skal være en del af agile teams. De tanker var skrevet i kontekst af forberedelse til Certified Agile Tester kurset, og det er en sjov læsning for mig i dag.

Et par erfaringer klogere har jeg begået mig ud til at skrive en lille artikel, der tager emnet videre til et spørgsmål om strategi. Egentlig er det jo ikke et valg baseret på præferencer! Om teamet skal have en dedikeret tester/QA afhænger af QA strategi for projektet/produktet.

Man kan godt forestille sig projekter uden en QA strategi, og beslutningen om at få en dedikeret og erfaren QA person kunne være begrundet i et ønske om at få skabt sådan en strategi. Og endelig, en mangel på strategi kan også være en strategi i sig selv…

Ikke desto mindre, her er lidt læsning til alle interesserede: (PDF, 2 sider, på engelsk)

Strategy for agile development teams- with or without dedicated QA
Article screen Udgivet 02.12.2017

Om at slå kanoner med gråspurve

Denne blog handler ikke om test, eller noget som helst andet fagligt. Det handler om dig, og dit virke som person.

Har du egentligt nogensinde spurg dig selv om hvor meget forskel gør du i dit nuværende job? Det er sikkert mange der gør før eller siden, uden at det behøver at være helt eksestentielt.

Hvad med om, on hvor meget forskel er du egentligt i stand til at gøre? Og måske har du overvejet hvilken effekt kan valget af dine handlinger have, når disse vælges med omhu. Det er sådan at det er ikke altid synligt, hvilken betydning vores handlinger har. Som når du sagde noget dumt til en kammerat eller en lærer i skolen og bare gik videre uden at tænke over hvilke tanker og følelser det har medført. Eller når du hilste på en du ikke kender i nabolaget eller bare ude på gaden. Mennesker vælger langt fra altid at vise deres sande følelser, og af samme grund får vi ikke altid feedback for de gode eller mindre gode ting vi selv gør i hverdagen. Ting der med garanti berører andre, i større grad end vi kan forestille os!

Kan du da forestille dig hvilken effekt ville det have at have en kollega som anderkender og roser dig for dine bedrifter? Ikke blot de store ting, som når du har bestået din eksamen med udmærkelse eller er blevet forfremmet.. Udmærkelsen er et ros i sig selv, og måske udvandes de supplerende roser når de blandes og kommer til dig på en gang. Men den ros, der kommer uventet og fremstår enkelt og rammer din egen følelse af bedriftens omfang – det er den der fortjener den største opmærksomhed. Som f.eks når du har siddet og knoklet med en langtrukken og utaknemmelig opgave ingen andre ville have? Eller da du endeligt løst den opgave som viste sig at være ca 200% sværere, mens ingen andre omkring har bemærket det?

Eller hvad med effekten når nogen oprigtigt tilbyder at hjælpe dig med nogle af dine opgaver når du har så travlt at du ikke når at opdage det selv? Dette synes at være lidt svært at tage imod for nogle. Nutidens tendens er blevet at sætte et lighedstegn mellem os sev og vores arbejde, og det er som om det er blevet sværere at takke ja til hjælp — for sæt nu man kommer til at fremstå som en der ikke kan klare sine arbejdsopgaver…. I forlængelse af dette, vil jeg vove at påstå det er også blevet sværere at tilbyde hjælp. For hvis man oplvever at få “nej, ellers tak” gang på gang, så er der også risiko for at man opgiver denne strategi på et tidspunkt. Alligevel, tænk hvilken forskel kunne det gøre hvis nu det var en selv der tog imod når det gjaldt?

Og så ellers effekten af at være positiv og proaktiv i en situation, hvor alt og alle omkring præget af dårlig stemning? Når det virker ligefrem forkert at være “ikke lige som alle de andre” – hvor længe kan det vare ved, og hvem tør at være den første til at bryde muren? Det kræves ikke en førerhat for at være en pioner – og på samme måde kræves der ej heller store overarme for at kunne beskytte vores egne — de folk omkring os der indgår i samme fællesskab. For lad os indse det: om vi vil det eller ej, indgår vi konstant i et eller flere fællesskaber af folk med samme formål. Vores fællesskab i og omrking vores arbejde er unægteligt et af dem. Spørgsmålet er således: hvilken forskel kan du gøre for dit? Når du er en udvikler, er dit job virkeligt at skrive kode? Er du tester, handler din hverdag således kun om at finde fejl?

Måske handler denne blog alligevel lidt om test og faglighed. For siden faglighed trives og udvikles i godt fællesskab, kan vi ej heller forvente gode resultater med fokus på performance hos de enkelte. At gøre hinanden gode sker gennem at gøre hinanden godt. I den professionelle test bygger vi vores gode kompetencer på evner som nysgerrighed, opmærksomhed på detaljer og gode kommunikationsevner men disse kan uden videre bruges på andet end at finde fejl i koden – vi kan spotte uoverensstemmelser i de sammenhænge vi ingår i, og gør vores del for at fællesskabet kommer et bedre sted hen. Hvad med et af de projekter med “umulige” arbejdsbetingelser, hvor overarbejde var normen og alle havde det så og så travlt… Når alle fokuserer på traveltheden, og verden synes at bryde sammen,  kan det være svært at vende blikket udad. Men hvem ville ikke ønske at være i et fællesskab hvor dette var normalen?

To go fast, go alone. To go far, go together

 — African proverb

At gøre forskel på den måde behøver hverken at være betinget af noget filosofisk eller religiøst. Det kan blot være et valg, baseret på indsigt og ikke midst viljen til at have andre med på vejen.

ps: lidt inspiration: