Testing in weekly release

Transcript

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