Hvad er en Job Story?

Hvad er en Job Story?


En Job Story er et alternativ til en User Story.

User stories skriver vi ofte skrevet ud fra en brugers synspunkt, som ønsker en eller anden ny funktionalitet fra et givent IT-system.

En Job Story har mindre fokus på hvilken handling, men mere fokus på hvilket job, story’en skal udføre.

Job Stories består af tre dele (fuldstændig som User stories):

Når <en given situation opstår>
vil jeg <motivationen>
så jeg kan <forventet resultat>

Eksempel på en Job Story:

Når der bliver registreret en ansøgning om et lån
vil jeg have en opgave i min opgaveliste
så jeg kan godkende lånet

Situationen – Når…

Den første linje i en Job Story er beskrivelsen af situationen – hvad trigger story’en:

Når <en given situation opstår>
Når der bliver registreret en ansøgning om et lån

Motivationen – vil jeg…

Den anden linje beskriver motivationen for story’en – hvad er jeg gerne vil have – mit mål:

vil jeg <motivationen>
vil jeg have en opgave i min opgaveliste

Forventet resultat – så jeg kan…

Den tredje linje beskriver det forventet resultat af story’en – hvad løser story’en:

så jeg kan <forventet resultat>
så jeg kan godkende lånet

Hvornår skal jeg bruge Job Stories?

Hvornår giver det mere mening af bruge Job Stories end User Stories?

Testpyramiden

Testautomatisering gennem brugergrænsefladen (UI) er ofte meget langsomt og skrøbeligt. En lille ændring i systemet/applikationen kan meget nemt ødelægge disse test, og vedligeholdelsen bliver meget omfattende og dyr. Skrøbeligheden gør også, at tilliden til testresultaterne kan blive undermineret.

Testpyramiden argumenterer for at vi skal lave meget mere automatiseret test gennem unittest end gennem brugergrænsefladetest.

Testpyramiden - Mike Cohn

Testpyramiden – Mike Cohn

Det var Mike Cohn, der “opfandt” testpyramide-koncept i hans bog “Succeeding with Agile”.

Mike Cohn’s originale testpyramide indeholder tre lag, som vores testsuite skal/bør indeholde:

1. Unittest
2. Servicetest
3. Brugergrænsefladetest (User Interface Tests)

Disse tre lag skal tages som en tommelfingerregel for hvor vi skal lægge vores testindsats:

Jo højre i lagene vi når, des færre test skal vi have.

Fordelene ved at automatisere på unit-niveau er, at vi kan skrive testene meget tidligt i udviklingsforløbet.

Når vi tester på brugergrænsefladen (toppen af pyramiden) er det ofte længere flow, vi tester, og det gør, at vi får meget redundant test.

Den Agile Testers Mindset – 2

I et traditionelt projekt hører vi ofte, at:

  • test er bagud
  • og testautomatiseringen er endnu mere bagud
  • vi kan ikke begynde at test inden koden er udviklet
  • testen bliver altid presset til sidst i udviklingsforløbet
  • der er altid pegende fingre omkring fejl – hvem er skyld i fejlen

Tænk hvis nu vi kunne forhindre fejl i at opstå INDEN koden bliver skrevet!

 

Traditionelt tænker vi på test som en fase, der ligger til sidst i et udviklingsforløb/projektforløb.

I et agilt udviklingssetup er test en aktivitet, der sker sideløbende med refinement, kodning o.s.v.

Hvad er en User Story?

Hvad er en User Story?


En User story er en kort og simpel beskrivelse i et naturligt sprog af en feature.

User stories skriver vi ofte skrevet ud fra en brugers synspunkt, som ønsker en eller anden ny funktionalitet fra et givent IT-system.

User stories følger ofte notationen:

 

Som <rolle>
ønsker jeg at <ønske>
med det formål at <formål>

 

Vi skriver user stories i 1. person (jeg), da vi nemmere sympatisere med fortælleren (rollen) i denne skrive form.

Den viste notation, giver os vigtig information:

Hvem er ønsker det (rollen)
Hvad er det han/hun ønsker (ønske)
Hvorfor (formål)

Typisk bliver user stories skrevet på et kort eller store Post-ITs. Efterfølgende prioriterer og arrangerer vi dem på en tavle med henblik på at facilitere en diskussion.

Diskussionen er mere vigtig, end det der skrevet i user story’en.

Forskellen på User Story og Use Case

Den største forskel på User Story og Use Case er:

User Story er et “letvægts”-dokument, som kan være skrevet på et simpelt kort: Som…, vil jeg…, med det formål at…
En User Story indeholder ikke alle detaljerne eller varianter. Den er en definition på højniveau af et krav, og indeholder kun den allermest nødvendige information til at et team kan estimere hvor meget det vil koste at implementere funktionen. En User Story er ment som et oplæg til diskussion for at fremme forståelse af hvad et givent krav indeholder.

Use Case er et “heavyweight”-dokument – langt mere beskrivende end User Story. En Use Case beskriver et normal forløb gennem en sekvens af handlinger. Derudover beskriver en Use Case også alternative handlinger – også kaldet varianter. En Use Case indeholder alle detaljer om funktionaliteten. En Use Case er en formelt specifikation af kravet.

Den Agile Testers Mindset

testersmindsetTæt samarbejde med alle team-medlemmerne og forretning er nøglen til succes for en tester i et agilt team. Graden af kommunikation er en vigtig faktor, så fokus ligger mere på den bløde side.

 

Vi kan opsummere den agile testers mindset til:

 

  • Quality Assistance over Quality Assurance
  • Building the Best Software over Breaking the Software
  • Early Involvement over Late Involvement
  • Continuous Testing over Testing at the End
  • Preventing Defects over Finding Defects
  • Short Feedback Loop over Delayed Feedback
  • User Stories and Customer Needs over Requirement Specifications
  • Whole Team Approach over Testing Departments
  • Team Responsibility for Quality over Tester’s Responsibility
  • Technical and API Testing over Just GUI Testing
  • Exploratory Testing over Scripted Testing
  • Automated Checking over Manual Regression Testing

Derudover skal en agile tester også have:

  • Domænekendskab til det system der skal testes
  • Forståelse af den teknologi der anvendes
  • Et niveau af teknisk kompetence til at kunne interagere effektivt med udviklingsteamet

Manifest for agil softwareudvikling

Vi afdækker bedre måder at udvikle software på ved at gøre det og ved at hjælpe andre med at gøre det. Gennem dette arbejde har vi lært at værdsætte:

 

Individer og samarbejde frem for processer og værktøjer
Velfungerende software frem for omfattende dokumentation
Samarbejde med kunden frem for kontraktforhandling
Håndtering af forandringer frem for fastholdelse af en plan

 

Der er værdi i punkterne til højre, men vi værdsætter punkterne til venstre højere.

Principperne bag manifestet for agil software udvikling

Ud fra de fire udsagn i det agile manifesto, er der lavet 12 principper, som vi følger:

 

  • Vores højeste prioritet er at stille kunden tilfreds gennem tidlige og løbende afleveringer af værdifuld software
  • Vi imødekommer ændringer i krav, også selvom de fremkommer sent i udviklingen. De agile processer sikrer at ændringer er til kundens fordel.
  • Løbende levering af velfungerende software, jo hyppigere des bedre.
  • Forretningsrepræsentanter og udviklere skal samarbejde dagligt gennem hele projektet.
  • Opbyg projekterne omkring motiverede personer. Giv dem de rette omgivelser og den nødvendige støtte, og stol på at de kan klare opgaven.
  • Den mest effektive kommunikationsform er samtale ansigt til ansigt.
  • Fungerende software er den primære måde at måle fremdrift på.
  • Agile processer fremmer bæredygtig udvikling. Systemejere, udviklere og brugere bør til enhver tid kunne opretholde et fast udviklingstempo.
  • Fokus på teknisk ekspertise og godt design fremmer den agile udvikling.
  • Enkelhed, defineret som kunsten at maksimere mængden af ikke udført arbejde, er essentiel.
  • De bedste arkitekturer, krav og designs stammer fra selvorganiserende teams.
  • Med jævne mellemrum reflekterer gruppen over, hvordan den kan blive mere effektiv, og tilpasser sin adfærd derefter.

 

Alle agile metoder bygger på disse 12 principper.