Succesfuld anvendelse af Behavior Driven

Transkript

1 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

2 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

3 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

4 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

5 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

6 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 Oversigt - Dokumentationskrav Standards and regulations 21 CFR Part 820 (Design Controls) ISO (Quality system) ISO (Risk management) ISO (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 (Software Life Cycle of Medical Devices) Guidelines IEC/TR (Application of ISO for medical device software) FDA: MDx Instruments with combined functions (2014) 7

8 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

9 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

10 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

11 BDD scenarier Et test case kaldes et scenarie Scenarier skrives i Gherkin-format De vigtigste keywords er: Given, When, Then

12 BDD scenarier

13 Automatisering Scenarier Gherkin Steps Java

14 file with a non-matching checksum$") } public void afilewithnonmatchingchecksum() { // Java code here analysis is started$") public void ananalysisisstarted() { // Java code here // analysis gets status failed$") public void theanalysisgetsstatusfailed() { } // Java code here //

15 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

16 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

17 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

18 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

19 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

20 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 (

21 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

22 JUnit vs. Cucumber

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

24 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

25 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

26 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

27 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?????

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

29 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

30 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

31 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

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

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

34 Traceability Modul Variant Caller Feature 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

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

36 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.

37 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.

38 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

39 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

40 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

41 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

42 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

43 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: Marianne Larsen: