Kend din kvalitet og prisen for den

Kend din kvalitet og prisen for den

Hvem jeg er og hvad jeg vil tale om - Kort om TIA Technology - Scoping og planlægning af releases - Testplanlægning og kvalitetsopfølgning - Omkostningsstyring Flemming Louw Reimer SVP Development, TIA Technology A/S Previously: Head of Software Product Development, EG A/S Chief Technology Officer, Scanjour Vice President, Development, TIA Technology Principal Group Program Manager, Microsoft Director of Program Management, Microsoft Product Unit Manager, Microsoft Product Unit Manager, Navision Director of Service, Damgaard Development Manager, Damgaard

Facts of TIA - Software company owned by EQT, headquarter in Denmark - Standard software for property and casualty insurance companies - 100 employees across four countries - 57 installations in 30 countries - Driving the market forward since 1996 - The global TIA partner network consists of more than 1000 implementation specialists with local knowledge TIA Technology 06-06-2016 4

Krav specifikation og design spiller en stor rolle for omkostningen forbundet med at kende kvaliteten

Scope structure Roadmap Jira (Product manager) Team Jira (Product Owners) TIA Jira (DevOps) Vision Themes (Marketing) Roadmap Features Epics User stories Tasks Enhancement Object page template Product configuration Multi object configuration Object slave TPC screen SVN COMMIT Object slave The digital enabler Claims processing FNOL Question wizard DOS impl ADF coding Milestones Automated real-time management Instant premium calculation Reinsurance on-line Test prep 24-7 Digital enablement Restful services REST services 06-06-2016 6

Release planlægning (release manager)

Produktions planlægning (VP & product owner) - 6 til 9 måneders horisont - Kapacitet estimeres pr. måned - Personer - Ferie - Fridage - Sygdom - Administration - Uddannelse - Etc. - Features (grov)estimeres ud fra roadmap plan (scope structure) pr. projekt - Support behov (defect resolution) estimeres Example Days Maj Jun Jul Aug Sep Okt Nov Dec Total days Available all 1451 1471 923 1324 1457 1456 1509 1334 10924 Sickness 44 44 28 40 44 44 45 40 328 Administration 73 74 46 66 73 73 75 67 546 Project A 49 49 33 47 51 51 53 47 380 Team 1 8 8 5 8 8 8 8 7 61 Team 2 12 12 7 10 11 11 11 10 83 Team 3 9 10 6 8 9 10 10 9 71 Team 4 11 11 8 11 12 12 13 11 90 Team 5 9 9 7 10 11 10 11 9 76 Project B 270 270 13 19 21 21 21 19 653 Team 1 30 30 2 3 3 3 3 3 78 Team 2 150 150 3 4 4 4 4 4 324 Team 3 30 30 2 3 4 4 4 4 81 Team 4 30 30 3 4 5 5 5 5 87 Team 5 30 30 3 4 4 4 4 4 83 Project C 654 669 608 872 957 955 987 874 6576 Team 1 125 118 96 141 155 152 153 137 1078 Team 2 72 69 128 187 207 202 207 184 1258 Team 3 133 154 108 154 171 182 190 167 1260 Team 4 185 182 145 207 224 232 237 211 1623 Team 5 138 145 130 182 200 187 199 174 1356 Project D 96 97 40 56 62 58 62 54 525 Team 5 96 97 40 56 62 58 62 54 525 Devops 77 85 60 81 89 81 89 77 638 All team 77 85 60 81 89 81 89 77 638 Project E 72 80 42 57 63 57 63 54 488 All team 72 80 42 57 63 57 63 54 488 Support & SE 90 80 56 76 84 76 84 72 618 All team 90 80 56 76 84 76 84 72 618 Management 126 140 98 133 147 133 147 126 1050 All team 126 140 98 133 147 133 147 126 1050 Planned work 1433 1471 949 1340 1475 1432 1506 1322 10928 Residual -98-117 -99-123 -134-93 -118-95 -877

Produktions planlægning (product owner) - 6 til 9 måneders horisont - Kapacitet estimeres pr. måned - Personer - Ferie - Fridage - Sygdom - Administration - Uddannelse - Etc. - Features (grov)estimeres ud fra roadmap plan (scope structure) - Support behov (defect resolution) estimeres Created and resolved defects forecast vs actual Actual resolved Actual created FC resolved FC created Days per defect forecast vs actual FC Days per defect Actual Days per defect

Sprint planlægning og retrospectives Sådan har vi valgt at køre SCRUM - Sprint længde er 2 uger - Alle teams sprints er aligned - Klare prioriteter er essentielle mellem support og nyudvikling - I hvert team afsættes kapacitet til support ud fra produktionsplan

Testplanlægning og kvalitetsopfølgning Optimal værdi skabes af en kombination af test typer, muligvis differentieret over tid. - Responsive test typer - Klassisk testning (en dygtig tester, der kan slippes løs og finde tonsvis af fejl ingen andre kan) - Eksplorative test typer - (f.eks. et område vi ved vi har få test cases bliver testet indenfor en tidsramme) - Lukning af Jira Issues baseret på repro, input fra dev og PO, kundens scenarie etc. - Strukturerede testyper er traditionelt test cases - Manuelle (f.eks. i ALM) - Automatiserede Værdien skal ses over tid både indenfor et release (sprints) og i regressions- og forandrings kontekst. - Risikovurdering (matrix) indebærer en risiko for at teste det samme hele tiden og misse nye problemer - Vores risikomatrix bruger flg. parametre (kan variere lidt per team) - Business impact - Frequence of use - Technical complexity - Product risk - Som vurderes low/medium/high konverteres til et tal og en vægtet værdi beregnes - Er inddelt efter funktionelle områder, så high risk områder kan til-vælges fra basen af struktureret test

Vores perspektiv på omkostninger i test Kr Manuel test Husk at tænke over: Hvad med vedligehold? Hvad med genbrug Hvad med tab af viden Automatisering Antal releases

Omkostninger ved forskellige typer af fix - Brug den rette type automatisering på et givent tids punkt - Manuel test skaber samarbejde og afklaring, undervurder det ikke - Automatisering skaber høj kode kvalitet både produkt og test kode Kr Anbefalinger: Release quality in Hotfix quality in Test quality in Build quality in Design quality in Forsøg at undgå det Triage defect fixes hårdt for at minimere risiko for regression Brug risikovurdering til testplanlægning Fokus på DevOps til automatisering af deployments Fokus på unit test samt tidlig automatisering Valider tidligt og ofte med kunder/brugere Efterstræb Minimal Viable Product Tid

Risk Matrix - eksempel Core Sub areas Functional area Business impact Frequence of use Technical complexity Product risk Product risk Automated Details Coinsurance Functional Areas Agreements management (Create and adjustments) 3 3 2 8 High N UI. Test hint: Create contra Coinsurance Functional Areas Algorithm (user function) 2 2 1 5 Medium N DB. Customization needed Coinsurance Functional Areas Premium calculation (leader) 3 3 3 9 High Y (case coverage) Coinsurance Functional Areas Premium- commission calculation (follower) 3 3 3 9 High N Coinsurance Functional Areas Commission calculation (Broker) 3 2 2 7 Medium Y (case coverage) Coinsurance Functional Areas Claims roles generation 1 3 1 5 Medium N Checkbox claims relations Coinsurance Functional Areas Coinsurance in the policy module 1 3 1 5 Medium N UI. Test hint: Check on pol Coinsurance Functional Areas Automatic claims recovery 3 3 2 8 High Y (case coverage) Coinsurance Functional Areas Automatic claims recovery maintenance 3 2 3 8 High Coinsurance Functional Areas Coinsurance GL transactions 2 2 2 6 Medium N DB. Expected to write scrip Coinsurance Functional Areas Coinsurance Cash Call 2 1 2 5 Medium Y (case coverage) Check REI-544 for function Coinsurance Functional Areas Hold until paid 1 2 1 4 Low Y (semi-auto) Follow automatic scripts (4 Coinsurance Functional Areas Coinsurace item overiview page 1 2 1 4 Low N UI. Test hint: Create contra Coinsurance Processes Coinsurance as Follower 2 2 2 6 Medium N Coinsurance Processes Coinsurance as Leader 3 3 2 8 High N {check service cat} 0 0 0 0 Low Coinsurance Services-Integrations

Ressource forhold og overvejelser - Det giver mindre og mindre mening at skelne skarpt mellem Dev og Test. - Engineering Managers leder derfor folk med begge roller - Udviklere har også ansvaret for unit tests - Ift. alle arbejdsopgaver udgør test (manuel, automatiseret o.s.v.) p.t. omtrent 1/3, men er stigende - Team størrelse er optimalt mindre end 10 - Vores scrum teams (po, sm, dev, test) producerer også dokumentation - Estimering og planlægning af sprints bør tage højde for alle roller og alle opgaver Role Count % Engineering manager 3 3% Software Engineer 47 54% Software Test Engineer 26 30% Product Owner 7 8% Support & SE Manager 1 1% VP R&D 1 1% Release Manager 1 1% Content Manager 1 1% Total 87 100%

Estimeringsmodel (illustrativ) Task Role Hours Weighted Talk to customer Product owner 10 0,01 Customer requirements Product owner 10 0,1 Customer Test cases Product owner 1 0,01 Handover from designer to development 20 0,05 Design specification Developer 10 0,1 Development Developer 100 Unit test Developer 10 0,1 Sparring Developer 1 0,01 Code-review Developer 2 0,02 Task test / functional test QA/Test 45 0 Regression test QA/Test 5 0,05 Release notes Writers 1 0,01 Online help Writers 2 0,02 Training material Writers 2 0,02 Marketing material Writers 2 0,02 Package DevOps 2 0,02 IT management DevOps 2 0,02 Project management Project Manager 0 0,05 Total 225 + 30% risk 293 1,3

Omkostningsstyring - Tidsregistrering er en nødvendig forudsætning - Overvej granulariteten - Vedligehold - Nyudvikling - Simplificer livet for udviklingsteamet ift. Registrering - Integrer tidsregistrering fra dev teamets primære tool til ERP system om muligt - TFS -> ERP - Jira -> ERP - Opfølgning per måned på omkostninger - Release niveau - Projekt niveau - Forholdet mellem vedligehold/nyudvikling/management A happy CFO

Opsummering og key take-aways - Gør meget ud af at strukturere og styre scope - Review ofte - Hav styr på vedligehold og tidsforbrug til andre ikke-nyudviklingsopgaver - Arbejd med risikovurdering ift. test planlægning - Følg op på test indsats kontra kvalitet (fundne fejl) - Udarbejd en planlægningshorisont der giver mening - Undgå at gå I for mange detaljer for tidligt - Vær stringent omkring produktionsplanlægning - Følg op på fremdrift v.h.a. agile metoder (sprint review, retrospectives) - Erkend at prisen for kvalitet stiger med kompleksiteten

Q & A