Testing in weekly release

024ce2681fa10ce9c1d8aa707d376d72?s=47 ksfee684
April 18, 2019

Testing in weekly release



April 18, 2019


  1. Testing in weekly release Cookpad Inc. Tech dept, Quality Improvement

    Group Kyohei Kato 1 週次リリースにおけるテストとは
  2. Introduction • Kyohei Kato (Cookpad Inc.) • Quality Improvement Group

    (Tech department) • Software Engineer in Quality • e.g. Implementing automated UI tests, QA, building test environment in mobile apps 2
  3. Agenda • What is Cookpad • Weekly release in mobile

    apps development • What is testing in weekly release • Problems in testing through weekly release • Ideal image of testing 3
  4. What is Cookpad • Recipe service originally web-only • Posting

    and searching recipes • Released apps in Android and iOS • Have been doing weekly releases for half a year 4
  5. Weekly release 5

  6. The concept is “Human adjusts to machine” • Release following

    a fixed schedule • Release tasks are run automatically • This automatic scheduling is set every Friday at 2 AM ◦ Week is the best so far 6 クックパッドアプリはみんなが寝ている間にサブミットされる( https://techlife.cookpad.com/entry/2018/09/14/090000)
 1 1
  7. 7

  8. • Changes merged until Friday will be target for release

    of next week • Then the app containing changes will progress to just before release • Necessary tasks for release are automated ◦ Automate tasks such as submitting reviews to Apple on iOS ◦ Progress to the condition that the app is released just by pushing a release button • People decide whether to release or skip ◦ The department responsible for service development takes the lead in making decisions • Develop apps back from the release time when you develop Main development flow 8
  9. None
  10. Whether to release or skip • App review by Apple

    (iOS only) • Checking changes by each developers ◦ Check their own changes • Pre-release testing by Quality Improvement Group ◦ It takes a few days 10
  11. None
  12. What is pre-release testing 12

  13. Quality Improvement Group • Group focusing on quality • In

    relation with all departments contributing to the Cookpad mobile apps • Mainly responsible for Cookpad mobile apps ◦ Background and other movement will be omitted • Implementing automated UI tests, QA, building test environment 13
  14. 14 Quality Improvement Group • Implement automated UI tests •

    QA • Build testing environment
  15. What we do in pre-release testing • Combination of automated

    UI testing and manual testing a. Regression tests to check the function by automated UI test b. Tests difficult to automate are done manually c. Manual exploratory testing against changes for each changes 15
  16. a. Automated UI tests • Automated UI tests using Appium

    • Appium is a test automation tool based on Selenium widely used for mobile apps or PCs ◦ Both emulator (simulator) and real device can be used • Regression test to check existing features ◦ e.g. login, recipe search, recipe browsing 16
  17. Check UI difference with image comparison • Take screenshots in

    automated UI tests • Compare with past ones with human eyes 17
  18. 18

  19. b.Tests that cannot be covered by automated test • Manually

    cover technically difficult tests that are difficult to automate ◦ Payment flow due to complex status of user status or device account ▪ In-app purchase, carrier payments… ▪ Difficult to automate 19
  20. c. Exploratory testing against changes • Of course each development

    team is testing ◦ Assuming that each team tests normal use cases • Exploratory testing against changes ◦ Confirm specifications of changes from issues and developers ◦ Check abnormal use cases and the impact on related features 20
  21. Summary up to here • Weekly releases improve release frequency

    ◦ It became possible to turn service development quickly with short cycles • Pre-release testing by Quality Improvement Group ◦ Pre-release testing is one of the release decision materials ◦ Combination of automatic and manual ◦ Need to be done weekly for weekly release 21
  22. Problems of current testing 22

  23. Quality Improvement Group approach • Get information about development from

    issue or directly from developers ◦ Both current changes and future developments • That information is used for pre-release testing ◦ What does regression testing cover with automated UI testing? ◦ What are unintended UI changes? ◦ What should I focus on in exploratory testing? 23
  24. None
  25. Problems that could have been avoided • Failure to understand

    the background of specifications • It leads to omit to consider of complex user status • Aware problems in the specification after implementation ◦ It was a problem that could be understood from the viewpoint of conducting the test ◦ It was finally discovered in the test stage 25
  26. Problems emerging due to weekly release schedule • A lot

    of problems presented here are not limited to weekly releases ◦ They will occur if the locations responsible for development and testing are separated • Improvement of development speed with weekly release raises the difficulty to keep up • The speed of development was not enough for problems to emerge until now ◦ Release once a month -> once a week 26
  27. 27 Four times the number of releases in the same

    period (about 3 months)
  28. Why does these problems come up? 28

  29. Testing is a part of service development • We cannot

    know the truth of service development unless we participate in it ◦ Service development is not only the following flow: (specification -> implementation -> test -> release) ▪ How to analyze user issues ▪ How to solve the problem ▪ How to find the solution ▪ How is the solution realized (here) ▪ etc… • We cannot understand service development just by being involved in only a part of this flow 29
  30. Limit of communication • We cannot understand service development only

    by issues and occasional communication • Especially in fast development speed such as weekly release schedule • Getting closed to limit of communication 30
  31. Ideal image of testing 31

  32. Testing in service development • To keep up, you should

    run together • Image that members of Quality Improvement Group are part of service development 32
  33. Change testing and also service development • Make service development

    think about quality and testing ◦ What affects the quality of the release, what are defects? ◦ What quality do you want to guarantee in service development? ◦ Awaken implicit expectations sleeping inside service development ▪ I don’t want a to put out a bug which make recipe sharing impossible!!! ▪ I want to protect the target user range for measures!! 33
  34. None
  35. None
  36. Required moves • People who think about quality as part

    of service development ◦ Think of quality as a member of service development rather than a different team ◦ Always think about what points of quality to focus on testing in service development ◦ Raise issues that are likely to be barriers to specification and implementation ◦ Ability to propose flexible testing • Close to my idea of an “agile tester” 36
  37. System to promote service development • We need people who

    are responsible for quality and testing as members of service development • Break through the limits of communication between service development and Quality Improvement Groups • Improve service development speed!!! 37
  38. Summary • Weekly releasing has been carried out in Cookpad

    mobile apps development • There is pre-release testing by Quality Improvement Group • Limitations of communication between service development and Quality Improvement Group through weekly releasing • As a member of service development, we need to think about the quality of service and testing against it • To a world where service development that thinks about quality, and a testing team can run side by side 38