Hvis du er tester eller testmanager i softwareudviklingsprojekter, så har du helt sikkert ligesom jeg stiftet bekendskab med begrebet “Definition of Done” og kender til værdien af, at bruge denne definition aktivt i projekt- eller teamarbejde.
Desværre oplever jeg stadig ledere, som siger “koden er færdig, så I kan bare teste løs”. Så gælder det om at være diplomatisk i sit svar til pågældende, for selvfølgelig er koden ikke færdig, når testen ikke er gennemført med et accepteret resultat. Eller hvad? I virkeligheden kender lederen måske ikke til Definition of Done for lige netop den del af produktet eller også er der slet ikke defineret noget.
Så her er min forklaring på begrebet “Definition of Done”:
- ”Definition of Done” forkortes som ”DoD”.
- DoD er en tjekliste over værdiskabende aktiviteter, der kræves for at producere software.
- DoD er den primære rapporteringsmekanisme for teammedlemmer.
- DoD er en kontrollerbar tjekliste.
- DoD er ikke en statisk størrelse.
- DoD er ikke produktkrav.
DoD er formet af virkeligheden eller den kontekst, hvor den indgår, f.eks.:
- DoD for en feature (User Story eller Product Backlog Item eller lignende)
- DoD for en iteration (sprint i Scrum sprog) (En samling af features udviklet indenfor en iteration)
- DoD for en release (potentielt mulig at sætte releasen i produktion)
Når jeg skal afgøre, hvor i udviklingsforløbet at en aktivitet til DoD hører til, stiller jeg følgende spørgsmål:
- Kan vi udføre denne aktivitet for hver feature? Hvis ikke, så
- Kan vi udføre denne aktivitet for hver iteration? Hvis ikke, så
- Vi skal udføre denne aktivitet før vores release!
Lad os kigge på nogle eksempler på en User Story med Acceptkriterier og Definition of Done:
User Story:
Som bruger ønsker jeg at kunne resette mit password, så jeg kan komme ind på min konto, når jeg har glemt mit password.
Acceptkriterier:
Når en bruger fejler sit log-in gives der mulighed for at opdatere password.
Når password resettes med en ukendt e-mail-adresse, skal der ikke sendes en e-mail og der skal gives besked om at e-mail-adressen er ukendt.
Når password resettes skal det nye password bekræftes.
Definition of Done:
- Unittest gennemført
- Koden er refaktoreret
- Koden er kommenteret
- Unittesten er automatiseret med en kodedækning på min 70%
- Feature’en er testet af teamet i samarbejde med PO
- Dokumenteret (just enough)
- Dokumentationen er reviewed
- Ikke-funktionelle test er gennemført
- Regressionstest gennemført som afsluttende test
Blot for at slå det helt fast: I dette eksempel er den pågældende User Story først helt færdig, når alle aktiviteter på DoD er gennemført!
I eksemplet har jeg brugt en User Story, men jeg kunne også have betragtet et sprint eller en release, hvilket vil indeholde andre aktiviteter, som i den sammenhæng skaber værdi at gennemføre.
Det er vigtigt at have Definition of Ready på plads inden man overhovedet begynder på arbejdet. Jeg ved godt, at det her er i omvendt rækkefølge, Definition of Ready er først, og jeg vil ikke gå i detaljer med ovenstående eksempel. Jeg vil blot dele den tjekliste, jeg ofte anvender, når jeg arbejder med Definition of Ready:
Definition of Ready:
- Indeholder alle tre felter (hvem, hvad og hvorfor)
- Forstås af udviklingsteamet
- Har et målbart udbytte
- Beskriver en funktion som ikke indeholder en løsning
- Opfylder INVEST-kriteriet (Independent, Negotiable,
- Valuable to Customer, Estimatable, Small, Testable)
- Har acceptkriterier som teamet forstår
- Definerer brugeren som en rolle
- Identificerer ethvert support-dokument som er relevant
