Succesfuld anvendelse af Behavior Driven

Succesfuld anvendelse af Behavior Driven Development indenfor dfgfdhsjfgdghjghfkfhgkfhjsrt et komplekst domæne med ekstremt høje kvalitetskrav fra hele teamets synsvinkel Katja Einer-Jensen, Torben Muldvang Andersen og Marianne Larsen Maj 2017

Plan for præsentation Introduktion Hvem 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

Hovedsæde i Hilden, Tyskland Introduktion af QIAGEN 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

Fremtidigt produkt 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 Day 1 Day 2 Day 3 Day 3-4 5

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

Oversigt - Dokumentationskrav 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) 7

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

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

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 BDD Scenarie

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 AAAA-TTTT AAAATTTT 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? Udvikler BDD Scenarie

JUnit vs. Cucumber

Test Driven Development Skriv test Skriv kode Refaktorér Alt kode er dækket af test Mere modulariseret og fleksibel kode Regressionstest

BDD som supplement til TDD Skriv scenarier Automatisér scenarier Skriv kode Skriv test TDD på et højere niveau En komponent kan genimplementeres Større fokus på integrationstest undervejs Refaktorér Skriv kode

Overblik over løsningen Vores produkt er et fast workflow kaldet en analyse. I workflowet afvikles en række moduler Analyse workflow Input data Modul Trimmer Modul Read Mapper Modul Variant Caller Analyse resultat

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 x 2 x + a n = n k=0 n k xk a n k?????

3 amigos alternativ 1 Grundmodel: PO T U Test Alternativ, hvor test skrives parallelt med udvikling: U U Test PO Test U T

3 amigos alternativ 2 Grundmodel: PO T U Test Alternativ, hvor forarbejde og første forslag til test skrives af udvikler: U Test PO Test T Test T U

3 amigos alternativ 3 Grundmodel: PO T U Test Alternativ, hvor forarbejde og første forslag til test skrives af tester: T Test PO Test T Test U U

Langsigtet planlægning Sprint 1 Sprint 2 Udarbejde BDD er Udvikle funktionalitet Udarbejde BDD er Udvikle funktionalitet Langtids planlægning Test automatisere Langtids planlægning Test automatisere

Traditionel V-model Krav/ designs End-2-end Test spec Designs Modul Test spec Detailed Designs Unittests

3-amigos V-model Krav/ designs End-2-end Test spec Designs Modul Test spec Detailed Designs Unittests

Traceability Modul Variant Caller Feature file: @SD:1904 Feature: Quality Noise filter Scenario: <title1> Given. When. Then Scenario: <title2> Given. Synkroniseringsværktøj Software Design: 1904 Quality Noise Filter <design tekst> Test Case TC <title1> Test Case Given. TC <title2> When. Given Then. 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.

Organisering og bemanding 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. Scrum Kanban 2-3 udviklere 4-5 udviklere 4-5 udviklere > 5 udviklere 1 tester & 1 PO

Erfaringer BDD er ekstra godt, når udviklere har begrænset viden om bioinformatik Langsigtet investering kræver ledelsesopbakning Når vi ikke bruger BDD går det galt Med BDD, får vi, hvad vi ønsker Kultur & nye vaner Det tager tid. Ikke realistisk for mindre virksomheder/projekter BDD kan ikke drive software arkitektur

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

Succesfuld anvendelse af Behavior Driven Development indenfor dfgfdhsjfgdghjghfkfhgkfhjsrt et komplekst domæne med ekstremt høje kvalitetskrav fra hele teamets synsvinkel Katja Einer-Jensen: katja.einer@qiagen.com Torben Muldvang Andersen: Torben.Andersen@qiagen.com Marianne Larsen: Marianne.Larsen@qiagen.com