Rune Birkemose Jakobsen Senior Development Manager MobilePay

Transcription

1 dfgfdhsjfgdghjghfkfhgkfhjsrt Automatiseret test en nøglekomponent i hyppige releases (MobilePay) Rune Birkemose Jakobsen Senior Development Manager MobilePay

2 Agenda The MobilePay history Quality Assuarance Automation Components Automation of the pipeline Application Architecture Application Insights Culture Feature toggles Automated Testing of Frontend Questions

3 Pope John Paul II

4 Pope Francis

5 MobilePay Anno

6 The digitalization of banking An average customer has an advisory meeting at a branch every 5 th year An average customer calls the bank twice every year An average ebanking user logs on 64 times per year An average Mobile Banking user logs on 161 times per year Danske Bank DK numbers 6

7 Increasing number of payment solutions

8 CLASSICAL BANK DISRUPTIVE MOVES A DUAL TRACK STRATEGY 8

9 The point of departure is rooted in traditional challenges from large organisations Legacy IT Building a tank Silo organisation... 0-mistake culture

10 Agility is pivotal to navigate in a constantly moving environment REGULATION FINTECH CUSTOMER BEHAVIOR 10

11 Start from scratch

12 QA Automation Components Automated testing is not just testing Automation of the whole pipeline incl. testing Aka. Continuous Integration and Delivery Software Architecture Application insights Culture Feature toggles 12

13 Automation strategy To support the agile development process and to support business agility we must focus on automation in the complete pipeline to: Minimize lead time to positive business impact Minimize negative business impact Small incremental changes makes it easier to fix should a problem appear 13

14 Automation of the pipeline Regular, Reliable, Repeatable Deployments 1. DEVELOPMENT 3. CONTINUOUS DEPLOYMENT Repository management Deployment 5. END-USER RELEASE IDE Commit Source control management V1.01 Testing Staging Platform Feature toggle management Monitoring Activate Feedback CI server Build Package DevOps Monitoring Production Platform Test 2. CONTINUOUS INTEGRATION 4. PRODUCTION DEPLOYMENT 14

15 Automation of the pipeline Build, test and deploy automatically with GoCD 15

16 Automated Accept Test

17 Application Architecture 17

18 Application Insights Continuous application health measurements Realtime graphical visulization Extensive error logs Preemptive actions on monitoring information 18

19 Application Insights 19

20 Culture Self organizing teams that takes the E2E reponsibility You build it You run it Werner Wogels, Amazon, 2006 Test Driven Development If you have done it twice, then automate Adam Stone, CEO, D-Tools DevOps Developers does the testing must understand the use cases 20

21 Feature Toggles 21

22 Feature toggle categories Release Toggles Canary Release Toggle (aka Scalable Roll Outs) Experiment Toggles (aka A/B testing) Ops Toggles / Kill Switches Permissioning Toggles (aka Early Access aka Dog Food aka Champagne Brunch) Used to enable trunk-based development. Continuous Delivery principle of separating release from deployment. A Canary Released feature is consistently exposed to a given percentage of a randomly selected cohort of users. The behavior is measured / tracked and the percentage is de- or increased accordingly. Each user of the system is placed into a cohort and at runtime send down one codepath or the other. The behavior is measured / tracked. Used to make data-driven optimizations / decisions. Used to control operational aspects of our system's behavior. Used when rolling out a new feature which has unclear performance implications so that system operators can disable or degrade that feature quickly in production if needed. Used to change the features that certain users receive. E.g. a set of "alpha" features which are only available to internal users and another set of "beta" features which are only available to internal users plus beta users. Similar to a Canary Release but exposed to a specific set of users. 22

23 Other automation/quality initiatives Load Producer Static & Dynamic Code Analysis, incl. Security Failure Injection 23

24 Automated Testing of the Frontend Selenium Midway in the journey APPIUM Just started 24

25 Automated Testing of the Frontend Critical paths approved by PO, e.g.: - Existing user logins to Business Admin. - Existing user is able to navigate through already developed screens like sales, transfers, payments points list, etc. Testing in cycles. Scheduled execution 4 times during working days Full test suite (Smoke+Sunshine scenarios), e.g.: - Onboard new merchant. - Add new account. Testing in cycles. Scheduled execution each night during working days General: Negative test scenarios such as incorrect inputs are performed manually. 25

26 Automated testing of the frontend Dedicated automation/qa team Developers & QA need to work together All bugs that fail E2E tests are blockers. Agreed to fix blockers as soon as developer has finished current task in the sprint; 26

27 Summary on automated frontend testing Pros Provides application health check with great coverage (sunshine scenarios) & increase confidence of product quality Increase bug detection speed & rate Reduces time running repetitive tests Brings more satisfaction in QAs daily work. Con Maintenance fixing failing tests full time 2 FTE (including escalating bugs to other teams) Backend teams (lack of changes coordination) & test environment (QA/SYST) failures Tests sometimes are flaky (due to different browsers, platforms, environments, connection) Developers extra help (add relevant Ids, explain solution) for QA is needed in each Sprint. 27

28 WOOHOO!! I made it 28

29 Automatiseret test en nøglekomponent i hyppige releases (MobilePay) Tak for din opmærksomhed Rune Birkemose Jakobsen Senior Development Manager ruja@danskebank.dk

30 Fun Facts 30