Examples of testable requirements

1 04 2014

In the last edition of  @TestingCircus I was yammering around testable requirements and the need for requirements people to get help from all you testers out there.  http://www.testingcircus.com/examples-of-testable-requirements/

Testing Circus is btw a great magazine! Even go back to old editions is well worth the time.

Annonser




Agile Quality and capoeira

3 12 2012

While not being very productive at the moment on this blog, I have got some thoughts down about Agile Quality at the company blog. What is Agile Quality? And what do you think it is? I’d love to hear!

http://blog.smartbear.com/software-quality/bid/242524/Understanding-the-Term-Agile-Quality-Through-Acrobatics

 

 





2 dagars agil coachning av 150+ proffs för 2000 spänn

24 04 2012

Tycker du det är dyrt med agil coachning? Missa inte konferensen Agila Sverige nästa år, som just gick av stapeln i Stockholm. Där får du 2 dagars professionell coachning av 150-200 erfarna ledare, utvecklare, designers, testledare, projektledare, verksamhetschefer, IT-ansvariga, filosofer,  pedagoger, samhällsvetare mfl

Insikten kom till mig på vägen hem. Denna återkommande konferens, ordnad i enkelhetens namn, innebär oavsett om du är proffs eller rookie i området att du får 2 dagars personlig coaching av väldigt många agila proffs och möjligheter till att ta del av erfarenheter, nya och gamla kontakter, roliga historier, personliga samtal, rådgivning, underhållning, praktiska tips och filosofiska resonemang om kommunikation, design, system, teknik, politik, religion, verksamhetsutveckling, organisation, teamutveckling och allt annat nödvändigt för att vi ska kunna leverera det våra organisationer är till för – att skapa en kund – må den vara medborgare, medlem eller konsument.

Det är nu 5:e (?) året jag deltar och utbytet ökar. Fiskdammen har mognat till ett event av direkt, praktisk och filosofisk coachning.

Några ämnen som var uppe som jag lyckades fånga

– Form och funktion – är samma sak. Varför skilja på design och utveckling?
– Inkludera människor i ditt team istället för envist försöka assimilera. Bjud in!
– Tänk nästa steg när du funderar på att byta riktning – vad kommer efter ditt val nu?
– Metodöverflöd. Det finns en enorm mängd fantastiskt användbara metoder idag för att leverera nytta – Innovationgames, Lean Startup, Real Options, UX (User Experience Design)-områdets stora skara av metoder, Stop-the-Line, Kanban, A3-förbättringar, Toyota Kator, Enkla checklistor, Programming Anarchy… listan kan göras oändlig. Välj en – prova på i 30 dagar, utvärdera, förbättra och/eller välj en annan nästa 30 dagar.
– Det finns goda exempel på hur verkligt självorganiserande organisationer kan fungera, se t.ex Valves handbok för nyanställda även Länsstyrelsen Karlskrona omnämndes i det sammanhanget. Hade velat höra mer om
– Kommunikationsskuld. Den skuld du bygger upp genom att avstå från nödvändig kommunikation. Ungefär som teknisk skuld. Det du inte gör något åt idag börjar du betala ränta på, skulden växer tills dess du tar i tag och börjar betala av skulden. Hur har du det med kommunikationen med dina leverantörer eller beställare egentligen..?

Agila Sverige är ett smörgåsbord av tillfällen till coachning och lärande.

Nya boktips från pedagogiska mästaren Tobias Fors – The Power of Learning och Thinking fast and slow

Om man upprepar något tillräckligt många gånger blir det sant. Några saker behöver upprepas och påminnas om många gånger, bl.a perceptuell blindness, testa själv på

Awareness Test: Basketball players

Har du verkligen koll på allt?

Och det ständiga upprepandet av mantrat:

”Be inte om tillåtelse, be om ursäkt efteråt”

kommer snart ge resultat i våra organisationer – förväntar mig större turbulens och större förbättringar på arbetsplatserna för kunskapsarbetare närmsta åren..

Och sist men inte minst, den ständigt och självklara upprepandet på denna återkommande konferens – frågan

VARFÖR?

Det resonemanget tror och hoppas jag blir nästa års fördjupning.

Tack till arrangörernas idealistiska och aldrig svikande engagemang för att se till att vi har ett forum som utan att kosta skjortan kan ta oss ytterligare ett litet steg framåt i evolutionen av våra system.

Snygga bilder på några av dessa 150+ coacher finns här…  fotat av.. vem var det? Joakim S?

Foton Agila Sverige Dag 2
Foton Agila Sverige Dag 1





Tests aren’t about testing – Scandev 2012

21 04 2012

At Scandinavian Developers Conference April 2012 there were some rememberable messages about testing – what I heard tests aren’t anymore about testing, if it’s ever has been.

Kevlin Henney @KevlinHenney first mentioned the message on testing in his keynote which was really about architecture and good coding – such as economy, visibility, spacing, symmetry and emergence.

About testing he said,  the point of automated tests is NOT how many tests you have,  it is in the meaning of them. To explicitily state rules, to know exactly what we mean in a row of code – that’s the point of testing

Tests turns belief into knowledge.

Gojko Adzic, @gojkoadzic, test and requirement change agent, told us the story of a French team that threw away their automated tests as soon as they’ve passed.  They used automated tests as a

shared understanding of what to do very effectevily

rather than a tool for testing.

He busted a lot about myths of BDD (Behaviour Driven Development) and the challenges on understanding of it from business. He called it

Businessting – the belief business users could write acceptance tests

I’m happy he brought this challenge up. I’ve seen so many teams waiting for business to suddenly show up with very clear, ready to automate, covering test specifications at exactly the right level. Gojko reminded us of the importance of conversation with business people on the rules, on the examples, on the code that’s gonna be written.

The main benefit of Behaviour Driven Development is that is supporting us longterm with information on what the system does – therefore you don’t always need to keep them tightly integrated to the code when they have passed once (!)

We’re obsessed with wrong details.

Jeff Patton,  reminded us also of conversation with business, and of the thing many of us seem to have forgotten about user stories.

User stories, no matter in what written template, was in the beginning there for the purpose of making business people telling stories! Stories about what’s happening in the business, and what could be happening in the future. Now many asks about how to write correct user stories, rather than asking their business person to tell.. their story.

So whatever we do we need to find ways to include business people in our daily conversations 

This seems to be the greatest challenge when it comes to Agile.

Mary Poppendieck, always insightful, brought the subject up of the importance of whole product team. She said we need to let go of ”software development” and talk about what we’re actually doing – product (or service) development to get business on our team so we can do great products and services.

If we believe in whole product teams, which I guess we do if we want to deliver good stuff, software development teams need to start to talk about products (and services)

Go from programming language to design language.





Kvalitet och kommunicera lättrörliga krav – Sundsvall 42

20 10 2011

Under konferensen Sundsvall42, som pågick den 18-20 oktober 2011 höll jag ett seminarium på tema ”Att kommunicera lättrörliga krav” i spåret ”Kvalitet” med undertexten ”Ok, nu jobbar vi agilt – är det bättre eller inte”. Flera frågor att svara på alltså, hur gör man det på 40 minuter?

Dessutom var det skrivet att detta är ett seminarium, inte en föreläsning, och min tolkning av seminarium är att det innehåller interaktivitet. Hur gör man en workshop i en biosalong med 60 deltagare?  Det finns säkert bra svar på det, det sätt som dök upp i huvudet på mig inför konferensen var att låta deltagarna refklektera omkring begreppet ”Kvalitet” och hur det kan tillämpas på kravarbete i en alltmer snabbrörlig värld – och dessutom dokumentera on the fly i Prezi. Att servera färdiga svar när det sitter 60 erfarna testledare, kravare, förvaltningsledare i publiken känns på något sätt.. omodernt – det måste finnas bättre sätt. Färdiga svar är bara att googla på – som min nyfunne digitala kamrat @erkstam sa under sitt föredrag om digitalisering.  ”Googla på mig så kan vi skippa hela den där presentationsbiten.”

Googla på ”Agile requirements” så hittar du en del, eller varför inte skaffa ett Twitter-konto tillslut och fråga där! Twitter är en fantastisk yrkeskunskapsbank för tips om artiklar, bloggar, rapporter mm. Om du hittar mig där (@ulrikapark] kan jag hjälpa till lotsa till intressanta grupper där du kan ställa frågan, eller så retweetar jag din fråga. Några tips från mig på tekniker och annat finns lite längre ner.

Prezi-dokumentationen från seminariet  (via traditionell dator behövs inget login). Jag försöker också få ner resultatet här i en något mer fyrkantig form som kanske är lättare att skriva ut. Tack till Ulf Eriksson, Reijo Soréus, Azim Rezaei, adjunkten från Mittuniversitetet och alla andra mycket kloka personer i lokalen som bidrog till ett facit, ett av flera multipla sanningar, för HUR vi bör jobba med krav för att uppnå kvalitet i de system, produkter eller tjänster vi levererar.

Några associationer  deltagarna gjorde till begreppet ”Kvalitet”:
(alla 60 kommer redovisas i separat inlägg)

LEVERERAT ENLIGT BESTÄLLNING

Vad kan vi göra när vi arbetar med krav för att bli säkrare på att leverera enligt beställning (”det får kosta så här mycket, jag vill ha det här”)?

Deltagarnas svar:
Var TYDLIG! Hur blir vi tydliga? Genom DIALOG och MALLAR t.ex User Stories.

Detta brukar jag kalla ”Extreme Expliciteness”. Extrem tydlighet alltså. Att använda krav&test-tekniken ”Specification by example” (Gojko Adzic har skrivit bra böcker i området) i kombination med user stories (Mike Cohn) är mycket användbart för att uppnå extrem tydlighet.

INGA FEL

Vad kan vi göra när vi arbetar med krav för att bli säkrare på att det blir rätt – inga fel?

Deltagarnas svar:
Test & granskning i iterationer!
Demos!
Flera iterationer över ett och samma krav!
Användarmedverkan!
Utvecklarmedverkan!

Inte bara kravaren är med i kravställningen alltså! och involverade på riktigt – mitt tillägg. Det räcker inte med att göra en workshop en gång där man ”samlar in krav” utan utvecklare och användare behöver vara med och påverka kraven löpande under hela genomförandet. Bästa sättet att lära sig mer om detta är att börja pröva idag!  Vad hindrar dig, ditt team, din organisation från att iterera över ett krav flera gånger, eller att involvera utvecklare i processen? Vad kan DU göra för att påverka det i små steg? Sitta 1 dag i veckan hos IT-leverantören? Sitta 1 dag i veckan hos din kravställare?

TRYGGT

Hur gör vi för att uppnå trygghet med kraven?

Deltagarnas svar:
Prototyper
Verifiera kraven, genom demos
Prioritering!
Kommunikation!
Rätt människor med

Ramverket Scrum innehåller många verktyg för just detta – tvärfunktionella team, prioriterade product backlogs och kommunikation och synlighet genom regelbundna demos och tvärfunktionella planeringsmöten (sprintplanering).
Scrum på 5 minuter.
Confessions of a serial Product Owner

ANVÄNDBARHET

Kvalitet är användbarhet. Hur uppnår vi användbarhet när vi arbetar med krav?

Deltagarnas svar:
Prototyper
Användningstester

Mitt tillägg: Engagera en duktig UX-designer (användbarhetsexpert ibland kallad) i teamet – som arbetar med teamet löpande genom hela genomförandet, inte bara i början eller i slutet. Personliga tips: Anette Lovas – Connecta, Fredrik Lindersson  – Söderhavet, Johanna Särnå – Valtech,  Sigrun Tallungs – Frontit, och säkert en hel bunt till därute t.ex på Antrop och Transformator Design.

Intressanta artiklar om User Experience Mapping

HÅLLBAR

Hur uppnår vi krav som håller över tid, är aktuella mer än 3 månader?

Deltagarnas svar:
Tydliga mål!
Gå ner på djupet! Gå ner på domänen och förstå varför.

Mål håller ofta längre än detaljerade krav. Vi ändrar inte målen varje dag, däremot gärna detaljerna beroende på förändrade omvärldskrav eller förväntningar.
Informationsobjekt/domänobjekt håller också längre än detaljer i funktionalitet är min erfarenhet. En informationsentitet – eller domänobjekt – (beroende på vilken ”skola” man pratar med) ändras inte varje dag när man väl lyckas förstå och kommunicera vad det är för objekt ”begrepp” vi pratar om. Därför är domänobjekt t.ex utmärkt lämpliga för att strukturera krav- och testdokumentation omkring, eftersom dessa strukturer håller över tid – åtminstone bra mycket längre tid än en user story.

Dessutom så vid de tillfällen jag varit med vid begreppsmodelleringsworkshops ”med rätt människor med” så har betydligt djupare insikter kommit fram om kraven. Insikter som kan vara både besvärliga och kännas omöjliga, men som verkligen bidrar till en djupare dimension av kravförståelse och detta kan förhindra allvarliga misstag och belysa nödvändiga samband och förändringar. En teknik som används alldeles för lite – eller för stelbent gömt i någons kammare, i ett hemligt filarkiv som bara vissa personer får åtkomst till. Sprid denna teknik!

Tips: Använd SMARTA mål. Googla på SMART goals. Eller fundera på vilka dina klarkriterier är. Beskriv, definiera vad ni menar när ett krav är ”klart” så har du ett mål definierat.
Tips: Arbeta med Domain Driven Design eller Begrepps-/informations-/domänmodellering. Förstå er verksamhet genom modellering. Ta hjälp av duktiga modellerare, kanske finns en ensam arkitekt någonstans hos er som inget hellre vill än att bli inbjuden till teamet och kravställningen? Eller en utvecklare som brinner särskilt för domänförståelse och modellering?

PORSCHE

Hur kan vi arbeta med krav om vi vill skapa en produkt/tjänst som är av motsvarande kvalitet som en Porsche?

Deltagarnas svar:
Smakar det så kostar det!
Sätt rätt förväntningar! Det kanske är ok att det blir en Trabant, bara förväntningarna är satta och kommunicerade så.

Min kommentar: Om vi förväntas skapa de administrativa stödsystemens motsvarighet till en Porsche, eller the BMW of kundtjänstsystem – då behövs det resurser för krav. Vi behöver antagligen flera olika kompetenser – analytiker, arkitekter, ux-designers, exploratory testers.. i teamen. Det räcker inte med en verksamhetsrepresentant på 30%…  Vi behöver också acceptans för att det kostar tid av flera personer i verksamheten såsom affärs-/verksamhetsutvecklare, strateger, domänexperter, personal att delta i användningstest, workshops mm.

OM VI HAR MÅLET ATT GÖRA ALLT DETTA, disciplinerat och ett steg i taget, visst kommer kraven hålla högre kvalitet?

Tack för orden och berätta gärna nästa år på SU42 hur det går med kraven!

Om jag hade trotsat programmet och hållt ett föredrag i stället, hade det jag tagit upp varit just dessa saker. De exempel jag hade med mig handlade om – Tydliga mål, begreppsmodellering, prioritering (backlog), user stories, specification by example och experience mapping – enklare version. Hade inte haft en chans att få med allt – t.ex användningstester och iterationer, så tack till deltagarna för att vi fick med mycket mer än jag hunnit med ensam.

De exempel från verkligheten jag tänkt visa upp finns lite av dem i Prezin. Vid något tillfälle ska jag försöka producera en artikel här om ”exempel från verkligheten på lättrörliga krav”.

Happy development!