Om at finde sin vej

En af de mest inspirerende samtaler jeg har haft i nyere tid handlede om det med at komme til succes og opnå mere i sit liv. Det råd jeg fik, handlede slet ikke om at sætte mål og finde måder at komme derhen (som jeg f.eks skrev om i min tidligere blog om succes og udfordringer). Det gik ud på at lave det man elsker at lave, finde sine værdier og det større formål man brænder for, og det var hele opskriften. Det var ikke nødvendigt at lave en større plan med langsigtede mål. Der også noget fedt, grænseoverskridende og ud-af-min-komfort-zone ved at slippe styring efter mål, sætte efter det man brænder for og stole på at det vil bringe en et godt sted hen.

I den relation synes jeg at det minder en del om Connecting the dots historien fra Steve Jobs utrolig inspirerende Standford Commencement speech (2005):

You can’t connect the dots looking forward. You can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something — your gut, destiny, life, karma, whatever. Because believing that the dots will connect down the road will give you the confidence to follow your heart even when it leads you off the well-worn path and that will make all the difference.

Vi lever tit med en forestilling om hvad vi og vores liv burde være. Nogle af disse forestillinger hænger godt sammen med hvem vi er; andre har sine rødder i vores syn på forventninger og den anerkendelse vi modtager fra vores omgivelser. Steve siger noget om dogma; om ikke at være fanget i forestillinger og rammer, som ikke er vores egne. Det synes jeg egentlig er en god pointe, som hænger godt sammen med det råd jeg fik. Nogle gange bliver man nødt til at afvige fra en vej, som ikke viser sig at være ens eget.

Success er ikke kun resultater på papiret, eller noget som kan sættes i udmærkelser-sektion på ens CV. Success er også at være tilfreds med og at kunne stå inde for det man laver – og det kan også være grunde til at afvige fra den lagte rute.

Og måske behøver det ikke være et valg – enten at være metodisk og planlægge sin vej til den success, eller bare at slippe det hele løs og kun være i nuet. Måske kan man være tilpas fleksibel navigation efter mål baseret på ens værdier, som man udforsker løbende. En styring der tillader at være interesseret for andre ting end det der hænger sammen med målet. At bryde rammerne ned fra tid til anden betyder også at give sig selv plads til at få noget nyt under huden – som at tage kursus i kalligrafi eller noget andet, blot fordi man finder det spændende! Der er ligesom at tage en ny udfordring op, blot fordi udfordringen i sig selv er spændende, uden at det nødvendigvis ser ud til at bringe en et sted hen.

En god ven til mig har lige taget uddannelsen som coach, og ville derfor coach’e mig som en del af forløbet. Jeg havde selv taget noget lignede kursus om coaching principperne, og kunne derfor forudse nogle af spørgsmålene. Alligevel blev jeg mindet om det med “Hvorfor er det vigtigt for dig?“, “Hvad giver det dig?” som er nogle af de ting man bliver spurgt om når man begynde at beskrive hvad man vil i sit liv. Det får en virkelig til at tænke over sine værdier!

At vove sig ud i og at lære noget nyt er værdi i sig selv, efter min mening. Læring giver en større perspektiv, mental udfordring til hjernen og vejen til nye erfaringer (når man nu også husker at bruge sin viden til noget).

PISTOL

Why, then the world’s mine oyster.
Which I with sword will open.

Reklamer

Jeres app virker ikke

Det er faktisk irriterende når ens liv bliver forstyrret af software fejl. Det er nu ok, hvis Netflix ikke vil stream’e i aften – jeg kan læse en bog. Noget andet er de ting som bare skal virke. F.eks indkøb!

Herhjemme holder vi meget af at bruge mindre tid på indkøb og mere tid på familielivet. Derfor bruger vi en af de tjenester der leverer dagligvarer hjem. Deres app er på flere måder genialt, da den indeholder opskrifter til inspiration, og under disse finder man så varerne man kan passende bestille til opskriften. En anden god funktion jeg er ret glad for er ens top 200, som listen over de ting man bestiller oftest. Mælk, pålæg og grøntsager skal vi have hver uge, og derfor er det ret nyttigt man kan klikke de ting man plejer af, uden at skulle navigere rundt i varekataloget. Men sådan skulle det ikke gå denne gang.. Bang! Hvor end jeg prøver, kan jeg ikke se min top 200!!! (ked-af-det-smiley-med-krydser-i-stedet-for-øjne)img_1134Det er nu selvfølgelig svært at få medfølelse over luksusproblemer som denne, set ud fra situationen for mig som individ (jeg kom videre, jeg bestilte mine varer trods hjælpefunktionen ikke virkede). Var det et kritisk fejl for firmaet bag app’en? Faldt omsætningen? Det vides ikke.

Men jeg kom til at mindes min mentale tjekliste over releases for mobile app’s som blev gradvist opbygget gennem flere år.

QA’ens guide til gode App releases

  • Først, og altid først: definér release strategi! En app rulles typisk ud til alle brugere igennem opdateringsmekanismen. Dog kan vi i nogle tilfælde release til en vis procentdel af brugere for at se om der opstår kritiske fejl, som kun fåtal når at opleve inden disse bliver hurtigt fikset i en ny release.
    • Android har en funktion hvor man bestemmer hvor mange % af brugere får den nye release.
    • På iOS kan man det ikke, mig bekendt.
    • Når vi introducerer nye features, kan disse afprøves ved hjælp af Feature Toggles, som også kan kodes til at blive aktiveret procentvis
    • Release strategien er med til at bestemme QA indsatsen

Forudsat features, der er med i releasen er blevet grundigt og ordentligt testet, og vi har gode unit-, integrations- og regressionstest på systemniveau, har vi ikke så meget at bekymre os. Virkeligheden er ofte noget andet – ikke fordi man sløser, men fordi forudsætninger for god kvalitetssikring ikke altid er til stede.

Hvis der er alligevel bekymring kunne det give mening at benytte følgende strategi: identificér områder i koden, konfiguration og infrastrukturen, som blev ændret siden sidste app release, og lav en strategi for at sikre der ikke er opstået nye fejl på grund af disse. Dette kræver:

  • Overblikket over kodeændringer der fremtrylles som en diff mellem live og den kommende version. Review er ikke kun noget softwareudviklere gør for hinanden. Som en QA, får man mange hints om hvor det kunne være relevant at teste (QA perspektivet er også værdifuld i at spotte eventuelle problemer her, tidligt i udviklingen)
  • Konfiguration (også lokalt på devices) tjekkes på samme vis. Udfordringen her kan være transformation (altså en proces hvor en version bruges lokalt eller på et test miljø, mens en anden i produktion). Det kan være rigtigt svært at teste produktionskonfiguration hvis forudsætninger er ikke på plads. Et par ekstra øjne i form af review er at foretrække i dette tilfælde.
  • Teamet har typisk styr på hvad de har ændret i infrastrukturen (det skader aldrig at spørger en ekstra gang.

Berørte områder er ikke kun filer som er blevet rettet i. Hvis man retter i delte filer (programkode biblioteker) bliver den berørte flade meget hurtigt bredere.

Det bringer os frem til en af de vigtigste våben i kampen mod domino-effekten: regressionstest! Få status på CI: har vi automatiseret test på de berørte områder, og kører det godt. Sandsynligvis kender du dækningen allerede, hvis du har testet på platformen i noget tid 🙂

  • God regressionstest dækker alle funktioner med høj impact – forudsætningen softwaren overhovedet har en værdi for forretningen. Hvis jeg ikke kunne bestille varer ville det være skidt.
  • God regressionstest duplikerer ikke test cases, og slet ikke på samme lag. Et produkt af en betydelig størrelse kan have mange test scenarier i sin regressionstestsuite, hvorfor overblikket er essentielt her. Vi vil ikke spilde tid vi kan have brugt på at få feedback fra brugerne.
  • En god regressionstest forudsætter at brugeren kan have forskellige konfigurationer af hardware og software. Er der risiko for at automatiske test ikke tester på alle konfigurationer?

Efter disse overvejelser, burde der nu være et overblik over automatiseret del af regressionstesten. Det som vi ikke har dækket, kunne vi overveje at teste manuelt. Såfremt vi har tid (man kan passende spørge sig selv, kan vi leve med fejl i et af de områder som er ikke blevet regressionstestet?). Svaret er også ligetil, når man har en test- og produktstrategi som fortæller noget om fejltolerancen. Meget apropos:

quote-what-is-tolerance-it-is-the-consequence-of-humanity-we-are-all-formed-of-frailty-and-voltaire-30-37-37.jpg

QA mindset’et er en finurlig ting, og frembringer ofte flere spørgsmål end teamet når at forholde sig til, eller håndtere i løbet af release-forberedelserne. En god ting at huske sig selv på, er at jo tidligere man stiller de spørgsmål, desto større sandsynlighed for en god kvalitets release.

p.s. varerne er bestilt og kommer på søndag, det bliver dejligt at få tid til at lave mad og måske teste lidt mere på ting rundt omkring

 

Success afhænger (også) af udfordringen

Da jeg læste på universitetet fik jeg noget af et komplement fra en af mine bedste venner. Han var fascineret af min evne til at “forudse”  ting forud for de sker. Sådan så han mig, da jeg overvejede de mulige scenarier i jagten på muligheder og mål. På den måde så jeg forhindringer som kunne opstå på vejen, og måske var det med til at lede mig ind i QA for 5 år siden.

Den dag i dag kan jeg stadig ikke forudsige fremtiden, men det at følge sin intuition, fornuft og logisk tænkning kan også være en måde at lægge en strategi for at opnå noget. Intuition er en sjov ting: en QA-kollega til mig har ry for at være en som “kan få tingene til at gå i stykker”. Ikke blot som et resultat af dybdegående risikoanalyser og erfaring med netop de ting hun rørte ved, men blot ved at have det i sine hænder. En sjælden evne – eller måske den kvindelige 6. sans? Jeg ville ønske jeg havde den særlige evne, men endte i stedet at forsøge at finde vejen igennem læringens veje.

Continuous improvement i teorien og hos Toyota

Uanset om man bevæger sig inden for den ene eller anden branche, kan man godt have en ambition om at blive bedre. Det ses jo inden for sport, kunst eller folk med nogle særlige evner, at talent, uanset størrelse, udvikles med øvelse. Tanken om at selvudvikling kan og bør ske oftere, end de få gange man er på kursus eller til konference, havde da også strejfet mig mere end et par gange i løbet af min karriere.

I øjeblikket læser jeg bogen Toyota Kata, som handler om begrebet kontinuerlig forbedring (continuous improvement) inden for bilproduktion. Samlebånd og leveringstid har meget lidt at gøre med den intellektuelle process i det med at designe, kode og teste software. Alligevel synes jeg at man kan drage paralleller, både i forhold til test, organisationen, og sig selv som person.

Ideen med Toyota Kata er at man kan forbedre sin virkelighed ved at sætte en ambitiøs vision, der ligger langt ude i horisonten. Visionen fungerer som en ledestjerne, som man forsøger at nå, uden at kende hele vejen derhen. Kontinuerlig forbedring er arbejdsmetoden, snarere end tilføjelsen til det (som når man tager på kursus en gang om året). Forbedringen ligger så i at opdage nye og bedre måder at komme tættere på målet og det sker konstant: hver dag prøver man noget nyt!

Allerede nu kan man tænke, det har jeg ikke tid til – jeg har et arbejde jeg skal passe. Eller så kan man måske tænke: hvorfor skal jeg prøve noget nyt hvis jeg allerede er god til det jeg laver…? Lad os tage et par eksempler. Hvis jeg skal have gæster, og gerne vil servere en kage, er det nemt at konstruere planen: kør hen til den nærmeste bager og køb en. Jeg kunne også bage en kage, og dertil skal jeg bruge en opskrift og ingredienser – stadig en forholdsvis veldefineret plan, som kun kan gå galt hvis de lokale supermarkeder er lukket. Men hvis nu jeg i stedet definere mit mål som en karriereskifte: lad os sige jeg gerne vil blive en bager. Måske endda vil jeg gerne sigte efter at være den bedste og den mest efterspurgte bager i hele Danmark. Hvad vil planen så være? Og hvis andre er samtidigt i gang med at arbejde efter den samme mål, hvordan påvirker det så min plan..?

Der kan være forskel på mål, konkurrence og ikke mindst midler i forskellige industrier. Alligevel, det som altid er sikkert er, at ingen kender fremtiden, og da virkeligheden er i konstant forandring, kan vi som sådan ikke altid regne med at kunne lave en plan hen imod de mål vi sætter os. Vi kan selvfølgelig også altid bare hente kagen..

Kata er en måde at finde vejen til målet, når vejen er ikke kendt. Meget kort sagt, går det ud på at have en vision (1), forstå virkeligheden som den er nu (2), og så arbejde hen imod den næste mulige delmål (3) igennem en række små eksperimenter (4), som illustreret her: (tak til internettet for lån af billedet)

kata

Alt mellem 2 og 1 antages for at være “den grå zone” – et ukendt område, som vi ikke kan navigere med sikkerhed igennem. Eksperimenter er de små skridt vi kan tage hen imod målet. Fejler vi, så lærer vi også noget – men for at det gavner på længere sigt kræver det at vi ved om vi går i den rigtige retning. Derfor har vi også delmål med på vejen (de kaldes Next Target Condition), som tager udgangspunkt i og er en forbedring af virkeligheden som den er nu (Current condition).

Hvis jeg tror jeg kan synge, men det lyder kun godt i mit hoved, så er der altså en lang vej til at blive en sanger. Derfor er forståelsen af min nuværende situation er lige så vigtig som retning, i forhold til det med at vælge de næste skridt.

Continuous improvement inden for softwaretest

Produktionsvirksomheder som Toyota sigter efter at forbedre effektiviteten af produktionsprocesser. Hvad kunne vi bruge det til inden for softwaretest? Hvis man vil kan man drage et par paralleller de to verdener i mellem:

  • Fagligt: software test er også en proces som kan forbedres hen over tiden. Som en softwaretester kan man blive bedre til sit fag. Som en organisation kan vi kan blive bedre til at arbejde sammen effektivt.
  • Netværk og domæne: viden om test og ens organisation lever ikke hos den enkelte, men udvikler sig gennem kontakt til fællesskabet. Det gælder i store træk ens domæne (f.eks test) og omgangskreds (dem man arbejder sammen med). Man kan lære hvem der kan hvad i virksomheden og danne relationer og partnerskaber, som styrker samarbejdet og på den måde hjælper med at opnå ønskemål hurtigere og bedre.
  • Karriere: Ens karrierevej kan også ses som en udvikling der består af en masse forbedringer til ens kompetencer, som ud over de faglige kunne f.eks indebære evner til at håndtere mere kompleksitet, se i større perspektiv, være en bedre kommunikator og leder. Disse afhænger i princippet af vejen, om det er op ad stigen eller hen til en anden rolle

Softwaretest er en disciplin som styrkes med en række kompetencer, der afhænger af den type test man udfører. De enkelte komponenter kan gavne en personligt, men  ikke nødvendigvis garantere at vi kan blive bedre til at løse de udfordringer vi står med her og nu. Hvorfor det? Det afhænger af konteksten. F.eks kunne man have en idé om at kunne forbedre test effektiviteten ved at kunne en række test teknikker eller værktøjer som kan udvide ens kompetencer. Antagelsen her ligger i at tro man bliver mere effektiv og nyttig, fordi man er i stand til at udføre et bredere spektrum af opgaver inden for test.

Men man kunne også blive bedre til at samarbejde og drage nytte af de kompetencer som ens kolleger allerede har. De “bløde” kompetencer kan være en anden vej til at blive bedre: ved at være stærkere sammen, og ved at komplementere de kompetencer som findes hos dem man arbejder sammen med. Og så kan kunne man stadig forfølge de kompetencet og teknikker der giver mening i kontekst af at man er flere der arbejder sammen. Forbedringer sker sjældent i ensomhed, selv om man vælger selv om man vil gå vejen alene. En anden glimrende bog “Together is better” af Simon Sinek har en passende illustration til lejligheden:

Uanset hvad man vil sigte efter, er der noget basalt i ikke at starte med antagelsen om at en bestemt løsning kan være vejen til en bedre virkelighed. Ved at vende det rundt vil man kunne forestille sig en ny virkelighed, som en vision af det: hvordan vil jeg gerne virkeligheden skal se ud. Det starter med et “jeg” da man skal have et sted at starte, og have det godt i maven med den retning man vælger at sigte efter. Man kunne overveje:

  • At kunne afsætte tid til at hjælpe og vejlede mine kollegaer
  • At kunne definere en test plan på det niveau som kræves for projektet
  • At tage mere ansvar for test i min organisation

Visionen afhænger af ambitioner – de udfordringer man tør at sætte sig selv.

For at arbejde derhen, kunne man lave en opstilling:

Det nuværende tilstand Vejen derhen Vision/Udfordring
En softwaretester med en basal viden inden for test og testdesignteknikker Det næste mulige skridt.

At kunne agere Test Manager, planlægge og styre test på alle udviklingsprojekter som virksomheden udfører.

Mit næste realiserbare mål

Når der er langt til målet, kan det være svært at tage et skridt hen imod det. Men det første skridt er faktisk det vigtigste. Hvordan ved man hvad er det næste rigtige skridt? Ofte, specielt når man bevæger sig i et ukendt område, ved  man det slet ikke. Det er ikke sikkert man ved hvad der skal til for at planlægge og styre softwaretest endnu. Men bare det at man tager et skridt, er en sejr i sig selv.

Det næste skridt kan gå i retning af ens vision – ved at løfte det nuværende tilstand en tand eller 2 op:

  • Jeg kan blive bedre til at tænke på forudsætninger for at jeg kan teste effektivt, forberede test data og skaffe den nødvendige information i god tid
  • Jeg kan notere risici jeg opdager undervejs, mens jeg lærer om nye projekter og tiltag
  • Jeg kan lære at planlægge og designe test som reducerer risici ud fra de givne betingelser

Et eksempel på det næste realiserbare mål kunne altså være at blive bedre til at løse nogle af de problemer og udfordringer, som ligger til grunden for en god planlægning og styring af test. Ved at forstå processen og efter at have haft fingrene i det, bliver jeg bedre til at gøre det igen og igen og måske på en mere overordnet niveau (f.eks i en test plan).

I forhold til samarbejde, kan både vision og arbejde med realiserbare delmål udføres i en kontekst af et team. Et QA team kan f.eks have en vision om at blive verdens klasse QA team.

Vi må og skal fejle

Vi ved det egentligt godt at det kan være nødvendigt at fejle før man lykkedes. Man fejler ofte ved at prøve noget man ikke er god til, fordi man endnu ikke er i stand til at løse de problemer som der kræves.we-fall-off

Mange er tilbøjelige til at give op der hvor det bliver for svært, fordi vi instinktivt følger de veje vi allerede kender. Disse kræver mindre indsats og er derfor nemmere for hjernen at håndtere. Men hvis ikke vi fejler, så lærer heller ikke noget om hvad vi kan gøre bedre! Et eksperiment fejler således hvis det lykkedes at gennemføre det i første forsøg – for så har vi ikke lært noget. Toyota Kata har et glimrende citat om det:

No problem = Problem

Med andre ord, vi er nødt til at opleve udfordringer / problemer for at vokse med dem. Hvis ønsketilstanden er realiserbart, vil vi, med rette portion af motivation og vedholdenhed når det en dag, igennem en række små eksperimenter som vi lærer noget af. Når vi lærer noget, bør vi fejre, men vi bør også sætte efter det næste ønsketilstand. Vejen til idealet kan være lang, og hvem ved – måske ændrer idealet sig undervejs imens man bliver klogere.

stocksnap_1m9boe7xdz

På den måde kan man altså sige at visionen i sig selv er ikke destinationen. Toyota ser ikke foreløbigt det muligt at opnå 0-defects i deres produktion. Idealer behøver ikke at være opnåelige, men den forbedring man opnår undervejs er det faktiske gevinst man høster. Vi har brug for et ambitiøst mål, både for at definere retningen men også for at nå langt. Der skal mod, dedikation og indsats til for at opnå gode resultater. Men hvor gode de bliver afhænger også af hvor højt man sætter baren (og at man tør at sætte den). Success depends on your challenge.

/Poul

Vi laver jo software til mennesker og ikke omvendt

Behavior Driven Development. Et koncept, en tankegang, en filosofi eller blot en metode. Der er sandsynligvis mange fortolkninger af bevægelsen, som opstod i de agile kredse i tidligere 00’erne (ifølge mine kilde, I må gerne rette mig). Så mens Britney Spears, N-Sync og Christina Aguilera toppede hitlisten på MTV, udsprang der en ide om at TDD (Test Driven Development) kunne gøres bedre ved at fokusere på adfærd. Test i sig selv giver mere værdi hvis udgangspunktet for den er kravene til software, og vi kan udtrykke beskrivelsen af test som krav til den adfærd som forventes af systemet og brugeren som benytter det.

Hvordan startede det? Til at begynde med, var det ideen at ens Unit Test navngives som sætninger der starter med ordet should:

void shouldCalculateAccountBalance()

Dernæst kom BDD frameworks som JBehave, Cucumber som gjorde det muligt at beskrive krav som læsbar tekst med bagvedliggende kode, som omsat skrevne ord til automatiserede handlinger der testede kravene:

Given I log on to the system as System User

When I open account management

Then I see a list of active accounts sorted by modification date, newest first

Vi kom tættere på samarbejdet mellem dem som beskriver behov og dem som realiserer disse ved at udvikle software. Historisk set har der været en opdeling i “forretning” og “IT afdeling” de steder som beskæftiger sig med softwareudvikling. Problemer i kommunikation imellem disse får tit skylden for fejlede IT projekter, men sådan skulle det jo ikke blive ved med at gå.

For det handler jo som sådan ikke om automatisering, når vi snakker BDD. Det handler om at forstå hvilke behov software brugere har under de givne betingelser, og hvordan vi kan understøtte disse ved at lave software som hjælper dem i at opnå deres mål. Det er altså ikke et sæt af features der i sig selv er vigtig. Det er om brugeren kommer i mål – ved at bruge vores software!

Dermed bør vi først og fremmest starte med historien bag scenarierne, vores user story (den famøse WHY)

6808f5b0-594d-0132-0b73-0eae5eefacd9

User Story Example:

In order to provide world class support to our users

As a system administrator

I need to be able to manage account list effectively

Lige præcis denne del af BDD er måske den sværeste del af BDD – langt ud over udfordringer som ustabil browser automatisering, test coverage etc. Definere, hvad prøver vi at opnå og hvorfor? Hvilket formål har aktøren, og hvordan kan dette understøttes med det software vi vil lave?

En masse automatisering uden et klart-defineret formål er som et skib uden en styrmand. For hvis ikke vi hjælper brugeren med at løse opgaven på den bedste måde vi kan, så kan det da være lige meget om testen er automatiseret!

Der er skrevet rigtigt meget om hvad BDD er. Måske kunne det også være relevant at sige noget om det hvad det ikke er:

  • IKKE et projekt der går ud på at automatisere de krav som forretning har stillet. BDD handler først og fremmest om at definere krav sammen med sin forretning og udvikle med udgangspunkt i disse.
  • IKKE en proces som udføres af en enkel person! BDD indebærer samarbejde omkring krav på tværs af roller; f.eks når treenigheden, i form af forretnings-, udviklings- og QA perspektiv, mødes for at beskrive og udvælge nøgle-eksempler på brug af den feature vi har tænkt os at lave. De eksempler hjælper os med at forstå hensigten, og viser hvad de 3 musketerer er enige om 🙂three-musketeers
  • IKKE: En metode til at udvikle software. BDD er en tankegang, der hjælper os med at fokusere på de behov og udfordringer som vores brugere har. Vi kan stadig køre Scrum-sprints eller have en Kanban-tavle. Vi kan stadig skrive test før vi udvikler applikationskode eller udøve pair-programming.
  • IKKE: Noget smart udviklere har fundet på for at få lov at bruge mere tid på teknologi. BDD handler også om overblik og kvalitetssikring; når tests automatiseres løbende giver dette os levende dokumentation af det som allerede er udviklet, indsigt i hvor langt er vi henne i processen med udvikling på de stories som er i vores scope. Dokumentationen giver testere mindre regressions-byrde og mere tid til udforskende test med udgangspunkt i de beskrevne scenarier.

Når det er sagt, så handler det jo først og fremmest om brug af eksempler til at opnå fælles forståelse af det vi ønsker at lave. Det handler om samarbejde.

Historien, og Monty Python har bevist at kommunikationen kan være svær:

/Poul