söndag 6 februari 2022

Gherkin - det gemensamma "språket" från produktägare till utvecklare

Gherkin

Jag har nu haft möjligheten att använda Gherkin på jobbet, ett språk, eller kanske mer en mall, som används för att skriva systemtest så att de ska bli läsbara och förståeliga hela vägen från produktägare till utvecklare. Vi är bara i början av resan, men det verkar mycket lovande och intressant! Rekommenderar!

Om du är som jag och undrar varför saker heter som de heter så kan jag avslöja att gherkin betyder "liten picklad gurka". Och språket Gherkin används i testramverket Cucumber, vilket frun till skaparen fick namnge:

My wife suggested I call it Cucumber (for no particular reason), so that's how it got its name. I also decided to give the Given-When-Then syntax a name, to separate it from the tool. That's why it's called Gherkin (a small, pickled Cucumber).


Cucumber är ett Ruby-ramverk, sitter du med .net så är det SpecFlow som gäller om du vill skriva test med Gherkin.

För att du ska få en känsla för hur språket ser ut så kommer här ett exempel, där de fetkursiva orden, samt möjligheten till den korta beskrivningen på raden under scenario, tillhör Gherkin:

Scenario: Duplicate email

Where someone tries to create an account for an email address that already exists.

Given I have chosen to sign up

But I enter an email address that has already registered

Then I should be told that the email is already registered

And I should be offered the option to recover my password


plant, fruit, food, green, produce, vegetable, fresh, kitchen, gourd, eating, vegetables, cucumber, cucurbita, cucumbers, gherkin, preparations, flowering plant, pickled cucumber, ensiling cucumbers, mizeria, land plant, cucumber gourd and melon family, summer squash, Free Images In PxHere


Godbitar jag hittat

För att komma in i testskrivandet lite snabbare så läste jag The Cucumber Book - Behaviour-Driven Development for Testers and Developers. Här nedan kommer de partier jag markerat som "kom ihåg" under läsning.




Readability

When you're writing Cucumber features, make readability your main goal. Otherwise, a reader can easily feel more like they're reading a computer program than a specification document, which is something we want you to try to avoid at all costs. After all, if your features aren't easy for nonprogrammers to read, you might as well just be writing your tests in plain old Ruby code. The real key to expressive scenarios is having a healthy vocabulary of domain language to use to express your requirements. That said, using only the basic set of Gherkin keywords can often make your features repetitive, making them cluttered and awkward to read. By the end of this chapter you'll know everything there is to know about Gherkin's syntax, giving you all the tools you need to write clear, readable Cubumber acceptance tests.

System tests Vs unit tests

It's also worth thinking about whether some of the behavior you've specified in Cucumber scenarios could be pushed down and expressed in fast unit tests instead. Teams that enthusiastically embrace Cucumber sometimes forget to write unit tests as well and rely too much on slow integration tests for feedback. Try to think of your Cucumber scenarios as broad brush strokes that communicate the general behavior of the code to the business, but still try to get as good a coverage as you can from fast unit tests. Help make this happen by having testers and programmers work in pairs when implementing Cucumber scenarios. This pair can make good decisions about whether a piece of behavior necessarily needs to be implemented in a slow end-to-end Cucumber scenario and drive out the behavior using a fast unit test instead.

Överflödiga detaljer

Nedanstående test tas upp som ett exempel på ett test som innehåller alldeles för mycket detaljer på fel nivå.

Ett scenario för en e-postklient på webben:

Scenario: Check inbox
Given a User "Dave" with password "password"
And a User "Sue" with password "secret"
And an email to "Dave" from "Sue"
When I sign in as "Dave" with password "password"
Then I should see 1 email from "Sue" in my inbox

Användarnamnen är användbara, eftersom de är viktiga beståndsdelar i scenariot, men lösenorden är bara brus, de har inget att göra med det som testas och gör testet svårare att läsa. Till exempel så har Sue ett annat lösenord än Dave, vilket kan leda till att du som läsare av testet börjar fundera över om den delen är relevant och tappar då fokus från scenariots huvudsakliga mening, dvs: att testa att Dave kan se Sues email.

Lösenorden är alltså överflödiga detaljer (incidental details), detaljer som nämns i scenariot, men som saknar relevans för scenariots uppgift. 

Här är testet utan lösenord:

Scenario: Check inbox
Given a User "Dave"
And a User "Sue"
And an email to "Dave" from "Sue"
When I sign in as "Dave"
Then I should see 1 email from "Sue" in my inbox

En klar förbättring, mer lättläst och testets betydelse framträder tydligare. Ännu mer brus kan tas bort:

Scenario: Check inbox
Given I have received an email from "Sue"
When I sign in
Then I should see 1 email from "Sue" in my inbox

Nu är det ett koncist trestegs-scenario, som också är lättare att underhålla. Om användarautentiseringen måste ändras, så påverkar det inte själva testet utan bara koden bakom. 

When Cucumbers Go Bad: Imperative Steps

In computer programming, there are two contrasting styles for expressing the instructions you give to a computer to make it do something for you. These styles are called imperative programming and declarative programming.

Imperative programming means using a sequence of commands for the computer to perform in a particular order. Ruby is an example of an imperative language: you write a program as a series of statements that Ruby runs one at a time. 
A declarative program tells the computer what it should do without prescribing precisely how to do it. CSS is an example of a declarative language: you tell the computer what the various elements on a web page should look like, and you leave it to take care of the rest.

Exempel i imperativ stil:

Scenario: Redirect user to originally requested page after logging in
Given a User "dave" exists with password "secret"
And I am not logged in
When I navigate to the home page
Then I am redirected to the login form
When I fill in "Username" with "dave"
And I fill in "Password" with "secret"
And I press "Login"
Then I should be on the home page

Enligt författaren så kan man argumentera att ovanstående testexempel har en del fördelar. Men han menar på att man snart kommer drabbas av problem med test som lätt går sönder och uttråkade intressenter, t ex produktägaren. Test som skrivs på den stilen blir brusiga, långa, tråkiga att läsa och går lätt sönder. Till exempel en så liten ändring som en omdöpning av knappen från "Login" till "Log in" får testet att gå sönder.

Men det värsta är att språket inte tillhör den egentliga problemdomänen, utan blir mer lågnivå-språk med ord som "fill in" och "press", vilka tillhör gui-domänen.

Exemplet i deklarativ stil:

Scenario: Redirect user to originally requested page after logging in
Given I am an unauthenticated User
When I attempt to view som restriced content
Then I am shown a login form
When I authenticate with valid credentials
Then I should be shown the restricted content

Författaren skriver att det snygga med detta är att testet inte kopplas till en specifik implementation av användargränssnittet. Samma scenario kan användas för en desktop-app som en mobil-app.
Orden som används (unauthenticated, restricted, credentials) är förståeliga för en intressent som håller på med säkerhet.

It's true that using declarative style will mean you have to write more step definitions, but you can keep the code in those step definitions short and easy to maintain by pushing the actual work off into helper methods in your support code.

onsdag 5 januari 2022

DevOps i 40-talets kolgruvor

Grundtankarna i DevOps inget nytt
Boken DevOps Paradox - The truth about DevOps by the people on the front line av Viktor Farcic är en samling intervjuer med framträdande personer inom DevOps-rörelsen, där de får möjlighet att beskriva hur de definierar DevOps och deras tankar runt det, eftersom DevOps inte är en väldefinierad process enligt Victor:

The thing is, if there's anything that my years of working in the field have taught me, it's that DevOps is not a well-defined process. There is no set of rules that must be followed. As I discovered in my journey, and as you'll read in these pages, it's even questionable whether there is such a thing as a "DevOps department" or a "DevOps engineer". This ambiguity is exactly why DevOps is so fascinating to me, and I hope to you, the reader, as well.
En av personerna som intervjuas är Kevin Behr, som i sin intervju lyfter att DevOps-tänket med gemensamt mål, samarbete över gränser, kontinuerligt experimenterande och lärande användes naturligt som en "överlevnadsinstinkt" dolt nere i kolgruvorna på 40-talet. Nedan är en översättning av exemplet han tar upp i intervjun ihopbakat med lite av det han tar upp i sin dragning First In Last Out - devops roots in coal mining - Kevin Behr - devopsdays Pittsburgh 2014


Sociologer till kolgruvorna
Efter andra världskriget behövde kolproduktionen i Storbritannien öka som ett led i att snabba på återuppbyggandet av landet efter all förstörelse från kriget. Det låg alltså i nationens intresse att kolgruvornas produktion maximerades. För att uppnå detta anställde regeringen två sociologer, Eric Trist och Elliott Jacques, för att de skulle undersöka gruvorna som ett led i att se vilka som var mest produktiva och vad som gjorde att de var det.

Trist och Jacques upptäckte att alla lågproducerande gruvor hade en hög grad av automatisering, men att automatiseringen inte uppnådde förväntad produktivitetshöjning.

Vad funkar bäst? Team work!
Bland de många olika typerna av gruvdrifter hittade de en design som verkligen särskiljde sig, en design som hade flera gånger högre kolproduktion än de andra. Utöver hög produktion så hade den även signifikant färre skador och en mycket stark lagkänsla!

En annan skillnad de upptäckte var att arbetarna kom till jobbet som de skulle, vilket var en aning udda, för i andra gruvor var som regel 30% av arbetsstyrkan borta. Att jobba i kolgruva var farligt och det fanns många andra jobb i efterkrigstidens Storbritannien.

För att få reda på orsaken till arbetarnas höga närvaro i de högproducerande gruvorna så pratade Trist och Jacques med arbetarna när de kom tillbaka efter sina skift, men det gav inga ledtrådar till vad som kunde vara annorlunda. Så de började följa med arbetarna ner i gruvorna.

Embed from Getty Images
circa 1955: Welsh miners at work in a coal mine.

Självorganisering
Ovan jord så samlade skiftledaren alla arbetarna och gick igenom vad de förväntades göra. Men sen, väl nere i gruvan så märkte de direkt en skillnad: gruppen demokratiserade arbetet. De fokuserade på hela uppgiften, vad de skulle åstadkomma som arbetslag, istället för "jag fokuserar på mitt så gör du ditt".

De pratade om vad som skulle göras och delade upp arbetet mellan sig på ett lämpligt sätt, t ex "Vem drack inte igår? Ok, du får hantera sprängmedlen idag." Vem håller koll på säkerheten? Vem kör borren? De var självorganiserade och självreglerade.

Samtidigt prioriterade de att lära varandra sina uppgifter. På så sätt påverkades arbetsgruppens insats mindre en dag då någon hade ont eller kanske var tankspridd på grund av nåt som hänt i familjen så att personen inte klarade av sina vanliga uppgifter. Det var heller inte helt lätt att ta sig upp ur gruvan om nån blev allvarligt skadad under arbetet, därför behövde flera känna till hur man manövrerade de fordon och maskiner som behövdes för att ta sig ut.

Pareto-principen vid kunskapsspridning
Wikipedia beskriver Paretoprincipen såhär:
Paretoprincipen är en matematisk fördelning enligt vilken 20 procent av orsakerna ofta står för 80 procent av verkan; den kallas ibland även 80/20-regeln. Vilfredo Pareto visade att 20 procent av den italienska befolkningen innehade 80 procent av egendomen och denna observation har av andra senare generaliserats.
Inom mjukvaruutveckling verkar nedanstående gälla:
  • 80% av koden kan skrivas på 20% av tiden
  • 20% av koden har 80% av buggarna
  • 20% av funktionaliteten i ett program används 80% av tiden
Kevin Behr teoretiserar att gruvarbetarna utnyttjade Paretoprincipen för sin kunskapsspridning, det vill säga "lär mig 20% av kunskapen som behövs för att utföra din upgift till 80%". 

Om att lära sig varandras uppgifter på det sättet säger han: "And that is what DevOps is!"

Sociotechnical systems (STS)
Utifrån sin forskning angående kolgruvornas effektivitet så var Eric Trist med och myntade begreppet sociotechnical systems, där sociotechnical refererar till kopplingen mellan de sociala och tekniska aspekterna av en organisation eller samhället som helhet. På grund av att de tekniska och de sociala bitarna kan gå in i varandra så mycket, så måste man vid en optimering av en process ta hänsyn till båda bitarna (teknisk utveckling och kvalitén på personernas arbetsliv). För optimerar man bara en del så riskerar oväntade effekter från den andra delen att motverka optimeringen.

I kolgruvornas fall var det att man automatiserade gruvorna, men automatiseringen ledde till mer ensamarbete och arbetarnas arbetslivskvalité sjönk, vilket ledde till sämre mående och sämre arbetsmoral. Detta tas upp i podcasten Talking About Organizations avsnitt 34 Sociotechnical Systems – Trist and Bamforth

Vad ta med sig från detta?
Ja, vad man ska dra för lärdom av detta? Kanske att om man är på gång att införa DevOps på arbetsplatsen inte stirra sig blind på processerna och verktygen för automatisering av kontinuerlig integration/installation och automatiserade tester utan även ha fokus på det sociala samarbetet?