Att alla dessa värden av ett ”test” finns var inget nytt för mig, men jag hade faktiskt inte riktigt tänkt på den temporala aspekten tidigare, att funktionen varierar över tiden.

Presentationen innehöll en hel del matnyttiga tips på hur man gör sina artefakter så bra som möjligt, så att de faktiskt funkar i alla tre rollerna. (Detta inlägg kommer halta en del eftersom jag inte kommer åt exemplen som han visade, men…) Även vanliga misstag, anti-patterns, illustrerades.

Anatomin för BDD-artefakter ser typiskt ut som att man först på en ganska hög nivå beskriver en feature. Detta är ganska exakt en user story, och brukar ofta skrivas på formen:

En bättre form (som jag tror att vi brukar använda på aftonbladet) är:

Dett är bättre dels för att det sätter det viktigast först: nyttan med funktionen. Det är även bra för man fokuserar på problemet innan man börjar diskutera lösningen. (Och här kommer det alltså igen, samma sak som jag tidigare hört både när man pratat UX och API-design tidigare på konferensen: Förstå problemet först, innan man diskuterar hur det ska lösas!)

Tips här:

• Slarva inte med de beskrivande delarna av artefakterna – man gör bdd för människor, inte för maskiner
• ”För att” steget ska typiskt innehålla att man ökar det relativa värdet av något (eller minskar om det är något som är dåligt). T ex kan syftet vara att minska antalet användare som avslutar en tjänst. Då kan det vara lättare att se alternativa lösning som verkar för samma mål, men som man inte tänkt på först. Den tänkta lösningen kanske vore bäst, men orimlig pga av tidsbrist el ekonomi, men den alternativa kan vara bättre än ingenting.
• Håll isär vad, varför och hur. Hur ska typiskt inte ens synas i detta ”lager” av testerna, utan delegerar ner till ett mer tekniskt automatiseringslager.

Några ”smells” som brukar dyka upp i feature beskrivningar är att

• ”systemet” dyker upp som stakeholder.
• produktägaren dyker upp som stakeholder. inte lika illa kanske, men normal är det ju en användare som ska dra nytta av en funktion
• Beskrivningen innehåller en halvfärdig lösning
• Beskrivningen är för specifik

Varje feature beskrivs mer i detalj med hjälp av scenarier. Dessa brukar skrivas på formen:

Tipstet här är att börja med ”happy-path”. Testare kan med sin speciella testar-gen snabbt komma på massvis med specialfall och krångliga situationer som bör testas. Börja inte med dessa, eftersom det snabbt blir väldigt mycket brus av detta.

Hur ser då en bra scenariobeskrivning ut?

Fokuserad: Vad är annorlunda? Vad är skillanden mot andra scenarier? Fokuserar det på precis den skillnad som ska lyftas? Skriv ”then”-delen (”Så ska”) först – resultattet viktigast  Ha ett nyckelord i testnamnet

Balanserad: Akta sig för fomuleringar som ”Så ska alla utskrifter bli korrekta”. Se upp för givna som inte påverkar resultatet (så att). Scenariet ska vara som ett timglas -”när” är midjan, enbart ett ”när” statemnet.  Behåll en och samma abstraktionsnivå i alla delar av testet.

Avgränsad: Om scenarier säger ”över 50” så är värdet 100 dåligt som test, använd 51. Tänk exempel och motexempel.