succesfuld anvendelse af behavior driven development ... · præsentation af metoden behavior...

dfgfdhsjfgdghjghfkfhgkfhjsrt

Succesfuld anvendelse af Behavior Driven Development indenfor et komplekst domæne med ekstremt høje kvalitetskrav – fra hele teamets synsvinkel

Katja Einer-Jensen, Torben Muldvang Andersen og Marianne LarsenMaj 2017

Plan for præsentation

IntroduktionHvem er vi, vores produkter og kunder, projektets rammer

Præsentation af metoden Behavior Driven Development (BDD)

BDD i praksis- Fra udvikler perspektiv- Fra tester perspektiv- Fra product owner perspektiv

Konklusion

Introduktion af QIAGEN• Hovedsæde i Hilden, Tyskland

• Globalt > 4,600 medarbejdere fordelt på > 40 afdelinger

• > 500 kerneprodukter sælges i 80 lande: ”klar til brug kits”, laboratorieinstrumenter og software

• Anvendes indenfor sygdomsbekæmpelse og fødevareproduktion

3

QIAGEN Aarhus• QIAGEN Aarhus har knapt 100 ansatte

• Udvikler software til bioinformatiske analyser af store mængder af biologisk data

• Applikationer til karakterisering af f.eks cancer, arvelige sygdomme eller infektiøse organismer

4

Day 1 Day 2 Day 3 - 4 Day 3

5

• Mål: Give standardiserede og pålidelige analyseresultater så læger kan anbefale sygdomsbehandling

• Metode: Ud fra patientmateriale (f.eks. blod) at kunne afkode relevant genetisk variation

• Udfordring: Mange specialiserede delsystemer som udvikles på tværs af geografiske lokationer og ekspertiseområder

Fremtidigt produkt

Kvalitets og dokumentationskrav• Produktet skal certificeres som medicinsk udstyr

• Derfor opfylde myndighedskrav:▪ ”CE-mærkning”, EU-lovgivning▪ ”The U.S. Food and Drug Administration (FDA)”, USA

• Hvem har gavn af den omfattende dokumentation?▪ Eksterne interessenter (kunder, myndigheder og auditører)▪ Udviklingsteam▪ Fremtidige udviklingsteams (udvidelser, nye releases, fejlretning)

6

7

Standards and regulations• 21 CFR Part 820 (Design Controls)• ISO 13485 (Quality system)• ISO 14971 (Risk management)• ISO 62366 (Usability engineering)

Software development• FDA: Off the shelf software in Medical devices (1999)• FDA: General principles of SW Validation (2002)• FDA: Cybersecurity for Networked Med. Devices Containing OTS SW (2005)• FDA: Content of Premarket Submission for SW in Medical Devices (2005)• FDA: Premarket Submissions for Cybersecurity in Medical Devices (2014)• IEC 62304 (Software Life Cycle of Medical Devices)

Guidelines • IEC/TR 80002-1 (Application of ISO 14971 for medical device software)• FDA: MDx Instruments with combined functions (2014)

Oversigt - Dokumentationskrav

Hvad er det vi udvikler?

• Store datamængder

• Skal finde den rette ”nål i høstakken”

• Algoritmer: Komplekst input og høje krav til output

• Eksakte algoritmer og heuristikker

8





Konklusion

Behavior Driven Development

• Idéer fra bl.a. Test Driven Development og Domain Driven Design

• Delt proces mellem udviklere og management til udvikling af software

• Domænespecifikt sprog som bygger på naturlige sprogkonstruktioner

BDD scenarier

• Et test case kaldes et ”scenarie”

• Scenarier skrives i Gherkin-format

• De vigtigste keywords er: Given, When, Then

BDD scenarier

Automatisering

Scenarier

Gherkin

Steps

Java

Steps

@Given("^a file with a non-matching checksum$")

public void aFileWithNonMatchingChecksum() {

// Java code here //

}

@When("^the analysis is started$")public void anAnalysisIsStarted() {

// Java code here //}

@Then("^the analysis gets status failed$")

public void theAnalysisGetsStatusFailed() {

// Java code here //

}

”3-amigos” - proces

Product Owner Tester Udvikler+ =+ BDD

Scenarier

Product Owner: Beskrivelse af overordnede designspecifikationer. Indhenter og nedbryder de overordnede produktkrav.

Tester: Dedikeret test

Softwareudvikler: Implementation af algoritmer og unit testing

”3-amigos” - proces

I princippet er scenarierne færdige, når de 3 amigos har siddet sammen

Udvikleren kan nu gå i gang med at skrive produktionskoden

I princippet kan tester/udvikler starte på selve test automatiseringen





Konklusion

Kommunikationsværktøj med product owner

• Initielt software design skrives af én af de tre amigos

• Scenarier bidrager med

– afklaring

– konkretisering

– specificering

– begrænsninger Product Owner

Udvikler

BDDScenarie

?

Kommunikationsværktøj med product owner

Alternativer

• Snak – manglende konkretisering

• Mockups – passer ikke til algoritmeudvikling

• Udvidelse af design med eksempler – ingen automatisk test

• Iterativ implementation med hyppig feedback – typisk ikke mulig

Eksempel

AAAAGTTTT

AAAAGTTTT

ACCATTTT

AAAATTTT

AAAATTTT

AAAAGTTTT

AAAAGTTTT

ACCA TTTT

AAAA TTTT

AAAA TTTT

AAAAGTTTT

AAAAGTTTT

ACCA-TTTT

AAAA-TTTT

AAAA-TTTT

AAAATTTT

AAAAAAA-TTTT

Product Owner

National Human Genome Research Institute's Talking Glossary (http://www.genome.gov/glossary/).

Kommunikation mellem udviklere

• Udvikling af detaljeret design

• Afdækning af svagheder ved et design

• Nedsat risiko for at skrive kode som slettes igen

Udvikler

BDDScenarie

?Udvikler

JUnit vs. Cucumber

Test Driven Development

• Alt kode er dækket af test

• Mere modulariseret og fleksibel kode

• Regressionstest

Skriv test

Skriv kode

Refaktorér

BDD som supplement til TDD

• TDD på et højere niveau

• En komponent kan genimplementeres

• Større fokus på integrationstest undervejs

Skriv scenarier

Automatisérscenarier

Skriv kode Skriv

test

Skriv kode

Refaktorér





Konklusion

Overblik over løsningen

Modul Trimmer

Modul Read

Mapper

Modul Variant Caller

Analyse workflow

Analyse resultat Input data

Vores ”produkt” er et fast workflow kaldet en analyse.I workflowet afvikles en række moduler

Udfordringer ved test af et modul

Modulet er ofte bygget op omkring en kompleks algoritme. Algoritmen bygger på en række statistiske modeller og matematiske principper.

Modul Variant Caller

?????Input data 𝒙𝟐 𝒙 + 𝒂 𝒏 =

𝒌=𝟎

𝒏𝒏

𝒌𝒙𝒌𝒂𝒏−𝒌

”3 amigos” alternativ 1

PO T U Test

U U Test

Grundmodel:

Alternativ, hvor test skrives parallelt med udvikling:

PO T

U

Test


PO T U Test

U Test

Grundmodel:

Alternativ, hvor forarbejde og første forslag til test skrives af udvikler:

Test TestT

T

U

PO

PO


PO UT Test

T Test

Grundmodel:

Alternativ, hvor forarbejde og første forslag til test skrives af tester:

TestU

U

T

Test

Langsigtet planlægning

Sprint 1 Sprint 2

Udarbejde BDD’er

Udvikle funktionalitet

Test automatisere

Udarbejde BDD’er

Udvikle funktionalitet

Test automatisereLangtids

planlægningLangtids

planlægning

Traditionel V-model

End-2-end Test spec

Krav/ designs

DetailedDesigns

Modul Test spec

Designs

Unittests

”3-amigos” V-model

End-2-end Test spec

Krav/ designs

Modul Test spec

Designs

UnittestsDetailedDesigns

Traceability

Modul ”Variant Caller”

Feature file:

@SD:1904Feature: Quality Noise filter

Scenario: <title1>Given ….When ….Then …

Scenario: <title2>Given ….

Software Design: 1904 Quality Noise Filter

<design tekst>

Synkroniseringsværktøj

Test CaseTC <title1>Given ….When ….Then …

Test CaseTC <title2>Given ….When ….Then …

Fritekst felt i scenariet

Ved at benytte fritekstfelter i filen med scenarier, øger vi læsbarheden markant.

Brug af background

Ved at benytte background kan vi sætte fælles startbetingelser for alle scenarier i en feature fil. Der kan være fritekst i background.

Udfordringer (tester / test manager)

Manglende overblik under udarbejdelse af feature filer: i forhold til featurefile, f.eks.indholdsfortegnelse ville være godt.

Konsistensproblemer på tværs af feature-filer

Product owner retter ikke direkte i featurefil, men i en kopi. Tester indfører POs ændringer i featurefil og ændrer i testautomatiseringskoden, hvis nødvendigt.





Konklusion

Organisering og bemanding

Scrum Kanban

2-3 udviklere 4-5 udviklere 4-5 udviklere

1 tester & 1 PO

Projektet ændrede sig løbende. Med få udviklere var det nemmere at holde fast i ”3 amigos” princippet. Med flere udviklere fungerer det bedre med Kanban. Men der en øvre grænse.

> 5 udviklere

Erfaringer

Med BDD, får vi, hvad vi ønsker

Når vi ikke bruger BDD går det galtBDD er ekstra godt, når udviklere har begrænset viden om bioinformatik

Det tager tid. Ikke realistisk for mindre virksomheder/projekter

BDD kan ikke drive software arkitektur

Kultur & nye vaner

Langsigtet investering –kræver ledelsesopbakning





Konklusion

Hvorfor er det er godt?

Fordi det sikrer kommunikationen på tværs i projektet

Fordi det giver kvalitet i det udviklede produkt

Fordi det giver grundig dokumentation af det udviklede produkt

Fordi det danner grundlaget for en solid, automatiseret regressionstest

dfgfdhsjfgdghjghfkfhgkfhjsrt

Succesfuld anvendelse af Behavior Driven Development indenfor et komplekst domæne med ekstremt høje kvalitetskrav – fra hele teamets synsvinkel

Katja Einer-Jensen: [email protected] Muldvang Andersen: [email protected] Larsen: [email protected]

succesfuld anvendelse af behavior driven development ... · præsentation af metoden behavior...

Documents