Misforståelser omkring Behavior Driven Development

I denne blog vil jeg fortælle om de typiske misforståelser som ses i brug af Behavior Driven Development (BDD) og veje til at komme udenom disse.

Lidt baggrund og historisk perspektiv

Måske har du hørt om Specflow [1], Cucumber [2] og “Given ..When .. Then ” scenarier, men synes BDD konceptet er for abstrakt. En del materiale på nettet handler om at komme i gang med BDD værktøjer, og derfor er det ret naturligt at de fleste nye udøvere fokuserer på dette. Men der er mange flere fordele at hente, hvis man fokuserer på de primære gevinster og ikke hjælpemidlerne!

Inden vi kan komme derhen, er det en god ide at kigge tilbage og se på den måde, som konceptet omkring har foldet sig ud. BDD har vundet sin popularitet inden for softwareudvikling igennem 00’erne, og denne tidslinje over publikationer viser et godt overblik over forskellige forfattere i relation til emnet:

Billedresultat for bdd example picture
Tidlinjen fra en blog “Specification By Example and Product Quality” [3],
som viser udgivelser omkringer BDD og relaterede emner.

Oprindelige tanker om tættere kundeinvolvering manifisterede sig i begreber som Specification By Example, BDD og ATDD, der senere viste sig at have den samme essens. “Bridging the communication gap” er måske det bedste udtryk, der beskriver fællesnævneren for alle disse teknikker; at bringe en bedre forståelse af kundebehov der, hvor udvikling foregår. Krav og accepttest smelter sammen, fordi begge repræsenterer en og samme model af kundebehov og løsningen. Der findes flere gode eksempler i den nævnte litteratur på, hvordan dette kan se ud.

Det handler om at forstå mennesker (kunden)

Ideen med at skrive BDD-scenarier i stedet for lange kravdokumenter kan tolkes forskelligt og i nogle tilfælde tages for bogstaveligt. Det kan resultere i fokus på at få skrevet mange scenarier, og ellers i synet på BDD tooling som endnu et “test framework”, man tilføjer til projektet:

“The Given/When/Then convention is central to the notion of BDD”

en fortolkning fra “The Truth about BDD” [4], hvilket er efter min bedste overbevisning forkert

Faren er at de mange tests og tooling ikke er lig med god forståelse af det problem man har sat sig for at løse. Misforstået fokus på test og værktøjer viser sig især i form af specifikationer/eksempler, der minutiøst gennemgår samtlige elementer i brugergrænsefladen, og kunne derfor lige så godt været et script til automatiseret eksekvering. Men hvis BDD ikke er blot nogle Given, When, Then scenarier, hvad er det så?

Ved at bruge BDD får man en ramme for dialog med sammenhængende spørgsmål, svar og et sprog til kommunikation med flere involverede aktører. Dette illustreres ret simpelt på denne måde:

BDD in a Nutshell (Rachel Davies)
Davies, R. (2012). BDD in a Nutshell. Agile Coach.
PO = Product Owner,
BA = Business Analyst,
QA = Quality Assurance (specialist)
SE = Software Engineer
Alle begreber er typiske roller man benytter i nutidens software teams.

Vi stiller spørgsmål for at belyse de mange aspekter som et problem kan have; flere vinkler og perspektiver sammen giver bedre løsninger (på samme måde som flere hoveder er bedre end et).

Men det er ikke kun spørgsmål, som fremmer kommunikationen. Man får bedre løsninger ved at starte med forståelsen af de forretningsmæssige behov og ikke kun den tiltænkte løsningsforslag! Det kaldes “outside-in” princippet [5]. Når problemet er forstået, kan User Stories bruges til at beskrive/dokumentere behovet, imens kan BDD scenarierne forklare tilgangen til løsningen og fungerer samtidigt som eksempler på brug af den givne løsning (dokumentation). Eksempler kan tage mange former – billeder, scenarier og endda fortællinger som hjælper med at forstå situationen omkring problemstillingen bag [6].

Fordele ved denne tilgang til problemløsning er følgende:

  • Bedre vidensdeling og gensidig forståelse af behov
  • Mere robuste og gennemtænkte forslag til løsninger findes
  • Misforståelser undgås tidligt
  • Struktureret dokumentation af endelige virkemåde igennem letforståelige eksempler

Alting har en bagside, og disse fordele hænger unægteligt sammen med investering af tid, ressourcer og nye måder at arbejde og kommunikere sammen på.

Fra dialog til gevinst

Hvem skriver eksempler og hvem automatiserer disse? Vi får en fælles forståelse, hvis det er en eller få personer har rollen som BDD ekspert? Det er ofte sådan at når eksperten er væk, ved ingen hvad var meningen med det skrevne og en ny tolkning af den udviklede løsning skal findes.

  • BDD metoden handler mere om at få fælles forståelse igennem brug af eksempler
  • Se BDD/Cucumber værktøjer som en hjælp til at fastholde forståelsen af en tænkt løsning. Lige som User Stories, kan BDD scenarierne ses som en påmindelse om den dialog, der fandt sted ved udgangspunktet
  • Bedre forståelse og design bør resultere i højere opfattelse af systemkvaliteten. På den måde sker realisering af gevinsten igennem indsigtsfuld udvikling af værdifuld software

Får vi større gevinst af at finde løsninger igennem dialog og illustrere vores hensigter med eksempler? I mange tilfælde er svaret ja, da vi som mennesker har det jo med at misforstå hinanden 🙂

Referencer

[1] Specflow tool website: https://specflow.org/

[2] Cucumber tool website: https://cucumber.io/

[3] Specification By Example and Product QualitySamanta Cicilia

[4] The truth about BDD by Clean Code Project w/UncleBob Consulting LLC

[5] What’s in a story by Dan North

[6] Specification By Example by Gojko Adzic

Reklamer

TestExpo: med fantasi og visioner mod innovation og fremskridt

Den eneste obligatoriske konference for QA & softwaretest professionelle i Danmark er TestExpo. Den forunderlige forhold i mellem kvalitet og pris lader ikke megen tvivl stå tilbage, og der kommer flere og flere deltagere med for hvert år (i år nåede de vist på 800). Men hvad var der at tage med hjem i år?

Formål

Konferencens klare budskab var rettet mod innovation og fremskridt, hvilket er både tidsløst og fængende på en ganske opløftende måde. Personligt synes jeg rammen matcher de fleste andre konferencer, men temaet løftede budskabene til noget mere ambitiøst (som forventet). Forestil dig, ingen restriktioner og fantasien får frie tøjler.. Jeg var solgt.

Screenshot af konferrencens key takeaways

Programmet

I år faldt mine valg på disse udvalgte præsentationer:

  • Imagine Your Customers med Isabel Evans
  • Testledelse set fra kundesiden (Nationalbanken)
  • The Unified Model of Regression (Capgemini)
  • Live demo af en test professionels hverdag anno 2020 (Micro Focus)
  • Test i en skaleret udviklingsmodel (Capgemini)
  • Imagine Digital Happiness med Michiel Boreel

Jeg har i øvrigt glædet mig til at høre Sara Stürup Willers præsentation om test under rammerne med SAFe, og var rigtig ærgerlig at erfare den blev aflyst.

Test ledelse

Personligt var dette et af de mest inspirerende præsentationer grundet min nuværende fokus på test ledelse (dog fra leverandørsiden). Jeg ville så gerne inspireres til at støtte test ledelsen på den anden side af kontrakten og det lykkedes. Leas opråb var: “hjælp mig med at vide hvad jeg har skal bestemme, men husk at udfordre mig i mine beslutninger”. Eksemplet på leverandørens blind godkendelse af noget, som slet ikke gav mening, var måske en god måde at teste, hvor meget reel sparring man egentligt får fra sin leverandør. En leverandør er både en medspiller og modspiller på mange måder, som ideelt komplementerer kundens beslutningsevne med sine kompetencer og erfaringer.

Hver gang en leverandør kommer med et udspil, bør dette indeholde “hvad betyder det for mig som modtager af budskabet?”

Min refleksion over dette fald på introduktion af et test management værktøj for kunden: licens omkostninger, tilgængelighed, oplæring og ikke mindst kundens måde at tænke test cases på (som kan afvige fra værktøjens model).

Og så var det en (noget så) overraskende pointe: leverandøren behøver ikke at forstå altid forstå kundens forretning (nok nærmere alle aspekter af det). leverandørens sekundære mål efter leverancen er at udvise tålmod og respekt – de lever sandsynligvis under andre betingelser.

Skaleret test

Skalering af udviklingsmetoder synes være det nye sort, og fylder måske lidt for meget for dem, der ikke er direkte præget af disse rammer. Dog kan erfaringer fra disse horisonter fortælle en hel del om udfordringer, som også gælder i en simplere kontekst. Gittes oplæg var som altid sammenhængende, informativ og velkommunikeret. Der var også en kant af det, som gør det spændende at være en tilskuer. Man kunne godt sige, jeg vidste hvad jeg gik ind til.

Med hovedpointen om at test kompetencer og roller var oftest stærk nødvendige men glemte i SAFe verden, ledt Gitte os kyndigt igennem modellens komponenter. Der var udmærkede oplæg til måden test og testrollerne kan komplementere og støtte de overordnere mål i den skalerede model.

Jeg kom unægteligt til at tænke på oplægget om test i SAFe fra DSTB 2018, hvor budskabet var: “first rule of scaling: don’t scale”. Reelle behov bør komme før metodernes glimter og spredning baseret på popularitet. I get it, det sagde man også om Scrum, og nu ser man det nærmest er et obligatorisk ord på CV og i kontrakter. Alligevel synes jeg nogle gange er det bedst at lade være.

Inspiration til Test managers rolle i SAFe gav disse begreber:

  • Master
  • Servant leader
  • Tester & coach

Denne definition synes at have stadig større overlap med tilgangen i agil coaching og scrum facilitering, dog med fokus på kvalitet. Jeg har tidligere mødt Scrum Mastere, som havde lige så meget fokus på kvalitet, som en test manager kunne have i denne konstruktion. Jeg har også været en QA med lige så meget fokus på at være servant leader på teamet som en Scrum Master. Det er dejligt med de flydende roller, som opstår i postmoderne agil udviklingssamfund 🙂

Det med testen bliver glemt og nedprioriteret i SAFevar som sådan ikke overraskende. Flere erfaringer fra ligesindede tyder på at udviklingsmetoder sjældent tager direkte hensyn til test strategi og eksekvering.. Min tanke er at testens udbredelse må i så fald være opgaven for testerne selv (lidt løst inspireret af K. Marx).

Oplægget og test i SAFe var udbytterigt ift. in hvordan QA og Test management kan bidrage i skalerede udviklingsprocesser, og jeg er overbevidst om at mange fik noget med hjem at tænke over.

Digital lykke og den syntetiske æra

Den sidste keynote med Michiel Boreel var en spændende fortælling om den syntetiske generation, der ikke kender verden uden Internet. Det er generationen af fakes, som paradoksalt søger mere og mere det oprigtige, ægte og formålbaseret virkelighed. Det er firmaer som udbetaler dig en forsikringspræmier, baseret på ansigtsudtryk i dine videoindberetning. Det er etikken, større formål og IT løsninger som ikke giver dig lysten til at begå selvmord (talerens eksempel var nok et sjælden skræmmetilfælde).

Vi vil alle være lykkeligere i fremtiden, og det stiller andre krav til software som skal understøtte fremdriften mod dette end dem vi ser i nutidens udvikling. Min perspektivering ledte mig på mindet om en user story fra tidligere erfaringer i IT branchen:

“As a team, I want a database design, so it is documented”

Ja, lykken må vente lidt endnu.

Local Rockstars 2018, Test automatisering og trends!

Vores moderne og stadig mere foranderlige samfund stiller efterhånden større krav til hvad vi skal kunne præstere ved hjælp af ny viden. At skulle lære mere, hurtigere og mere målrettet er nutidens budskaber. De gevinster som loves til gængæld er mere rigtige produkter og større værdi man selv får ud af sin tid. Men har hvilke konsekvenser har det fortsat voksende fokus på strategisk læring for os der arbejder med QA, er spørgsmålet som jeg synes man ikke kan gå foruden.

Spørgsmålet jeg stiller har taget sin form under Local Rockstars konferencen i Aarhus, hvor jeg også selv holdt et oplæg om fejl og strategier inden for test automatisering. Jeg var ikke den eneste taler med fokus på automatisering og problemløsning generelt, og det var rigtigt spændende at høre andres bud på tackling af de komplekse problemstillinger som Test Automatisering (TA).

Mine bedste takeaways fra konferencen var følgende:

  • At læring er ultimativt det vigtigste evne vi er nødt til at beherske på morgendagens IT scene.
  • At finde de rigtige løsninger og svar er ikke nemt, men det handler om at øve sig på at stille de rigtige spørgsmål.
  • Enighed om processen er forudsætning for dennes succesfulde virke. Det er de levende processer hvor alle er enige om indholdet der vil virke i praksis. Uden enighed vil der altid være friktioner.

Om at stille de rigtige spørgsmål

Oven på konferencen, så det ud til at være nogenlunde enighed om at det er bedre at gøre noget og fejle hurtigt, end at bruge måneder på aktiviteter uden at kunne levere nogle synlige resultater. Det kunne jeg se både i den måde UX’erne arbejder med deres design, og til dels også i den måde udviklere sætter fokus på smart teknologi til at opnå hurtigt leverance af kode til produktion.

De fleste kan se ideen med at arbejde iterativt og komme hurtigt i gang med at opdage den rigtige vej til en løsning. Hvorfor skulle vi ikke gøre det samme med TA? Det kan være en god ide at starte et hjemmebrygget kodeprojekt end at bruge måneder på at vælge det rigtige værktøj som kan gøre det samme. Det er dog usandsynligt svært at lave test test maskine der virker første gang fordi det kræver andet end den rigtige teknologi! En af mine favoritcitater omkring TA stammer fra “Lessons learned in Software Testing:”

“Automating without good test design may result in a lot of activity, but little value”

Et godt test design er betinget af en række rigtige valg men det er ikke på forhånd givet hvilke valg er vigtige og ikke mindst rigtige. Vi er tilbage til læring, og det handler om at stille de rigtige spørgsmål på rejsen mod den gode test design. På samme måde som når vi stiller de rigtige spørgsmål for at lave den rigtige produkt. De rigtige spørgsmål opstår ud fra forståelsen af problemet.

Trends i Test Automatisering 2018

TA har igen været i fokus for mig siden konsulentopgaven i 2017-2018. Det gav mig mulighed for at genbesøge området som stadig nyder en del hype i QA industrien. Til dels er det også på grund af de konkrete behov som accelereret udviklingsprocess forudsætter. Det går hurtigere med at få produceret noget kode i dag, og dette kan mærkes mange steder på testfronten. Det er ikke nok med at vi lærer (vores forretningsområde mm), vi skal stadig eksekvere QA og vi skal gøre det hurtigere. Dette få flere til at tale om TA som “noget vi skal”.

Men hvad tilbyder TA os i dag, og hvilke trends der rørte sig inden for det i 2018?

1. Større virksomheder med robuste budgetter tør stadig at begå sig ud i at udvikle software som tester software: dette er tilgangen når man skriver  kode til WebDriver som trykker på knapper og udfylder tekstfelter. Spøger man Michael Bolton, så hedder denne type af TA “Checking” – who need testers? Jeg synes han har en pointe i at vi ikke kan automatisere den analytiske test proces og slet ikke ved at bruge testere udelukkende til at skrive kode.

Jeg er på ingen måde imod at skrive test som kode – jeg synes dog det giver bedst mening at det foregår Test-Driven: den udvikler som skal til at skrive produktionskoden starter med at formulere dette som en test. 

2. Testautomatiseringsværktøjer som LeapWork og Ranorex nyder den voksende interesse (ikke mindst i konsulentbranchen) grundet løfter om at reducere tid på vedligeholdelse af sine automatiserede tests.

  • Basalt set genererer disse koden for dig, så man reducerer risikoen for banale kodefejl i sin test og samtidig får hjælp til at genkende UI elementer. 
  • Dog kan testen stadig gå i stykker ved mindste afvigelse og der SKAL stadig ændres noget hver gang man ændrer i funktionaliteten og/eller UI, hvilket før eller siden bliver glemt eller skåret fra af hensyn til “time-to-market”.

Lad os se det i øjnene- den forretning som ønsker at flytte sig hurtigt har ikke råd til at automatisere sit Work-in-progress. Og i dag er der større dele af applikationer, apps og andre IT artefakter er konstant under innovativ udvikling de steder hvor omgivelserne nærmest dikterer innovation…

3. ..netop derfor ser vi den tredje “trend” som stammer naturligt fra ønsket om at ride på den voksende teknologiske bølge inden for AI (som er slet ikke AI endnu, men ordet bruges alligevel flittigt). TA med elementer af Machine learning – som f.eks Jason Arbons test.ai startup:

“Our AI bots can figure out how to execute tests even when the user interface or certain flows in your app change”

Bots som lærer applikationens UI at kende under supervision af mennesker… Det er blot en af mulighederne i anvendelsen, og i videoerne nedenunder bloggen har jeg listet et par praktiske cases jeg har kunnet finde. Strategisk læring, som var udgangspunktet i starten af dette blog tager en helt ny form. Den er nu understøttet af teknologien, men spørgsmålet er, om den moden nok til alt det vi gerne ville bruge den til.

Garner forudså dette i 2017:

“by 2021, 50% of enterprises will leverage intelligent test automation driven by AI and machine learning.

Selv om der kun er 3 år til, har jeg endnu ikke haft fornøjelsen at prøve bruge “AI” til test. Måske burde jeg, og hvis jeg vil være parat så har jeg da travlt!

Men ud fra de demoer jeg har set, giver det super meget mening at bruge den teknologi vi har til afvikling af udforskende manuel test. Hermed giver jeg også mig selv et løfte at sætte mere fokus på dette trend i de kommende blogs.

 

“by 2021, 50% of enterprises will leverage intelligent test automation driven by AI and machine learning.”

Magic quadrant for software test automation

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.

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 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