Testing rules for teams that do not write test code

Old title is "Team rules that never write test code".
Presenter is Shuya Higuchi.

Transcript

1. Team rules that never write test code Coop Sapporo Higu! (Shuya Higuchi)
2. Presenter Frontend 2015 Iwate University 2019 IT Company in Tokyo 2020 Coop Sapporo as engineer Double Dutch, Dancing AWS, Vue.js, OAuth2.0 English presentations Shuya Higuchi(24) role: career: hobby: favorite: new to:
3. What is coop sapporo DX? Retail industry giant • Over 1.8 million users • Annual sales of about 300 billion yen • Over 10,000 employees Coop sapporo DX vision Easy to use, Easy to shop, Easy to work Engineers • 4 AWS samurai • 24 Permanent employee engineer • System vendor with a relationship of over 20 years We are trying digital transformation !
4. Our history I will introduce the failure story
5. A long time ago.. A team released without even creating test cases. Make a test case only when carrying out a major release Our history
6. The reason is lack of resources! Our history
7. Minor repairs were released after confirmation by engineers and directors. Of course we don't know what we've confirmed each other. OK！ OK！ engineer director Our history Release rules
8. And the call center was receiving a lot of scolding. Our history
9. Eventually, the development team was overwhelmed with more projects, responding to inquiries, and revamping the existing system. Our history
10. I hope to spread this lesson to other teams to prevent this kind of mistake will never happen again. Our history
11. How did we get into this mess? • Delivery ◦ The director had decided on the release date before the engineers joined the project. ▪ We didn't have an accurate estimate of the project. ▪ Testing was not incorporated into the man-hours. • Quality ◦ We started production without determining the detailed requirements. ▪ I had made test cases only for the first release. ▪ We decided to fix the bugs after the release. ▪ Just before the launch, we had to support IE.
12. How did we get into this mess? • Delivery ◦ The director had decided on the release date before the engineers joined the project. ▪ We didn't have an accurate estimate of the project. ▪ Testing was not incorporated into the man-hours. • Quality ◦ We started production without determining the detailed requirements. ▪ I had made test cases only for the first release. ▪ We decided to fix the bugs after the release. ▪ Just before the launch, we had to support IE.
13. After release improvement flow Inquiries select Implementation test
14. After release improvement flow Inquiries select Implementation test important
15. How do I test it? • How to test?(How) ◦ Operations test？Interface test？unit test？ • What is the test object?(What) • Who will do the review?(Who) • When is it done?(When) • Where is the test environment?(Where) • Why are we running the test?(Why) A start-up team does not have the rules that exist in a typical team.
16. Never-ending task after release test bug Inquiries select Implementation
17. Since each person does it individually, there will be variations in the test. The efficiency of the system is also reduced because the cause of the problem is determined from the inquiries made at any time. Never-ending task after release Inquiries select Implementation test bug
18. Solution of "How do you test it?" • How to test?(How) ◦ Focus only on user story testing. • What is the test object?(What) ◦ Create and use spreadsheets as templates. • Who will do the review test?(Who) ◦ People who reviewed code. • When is it done?(When) ◦ During code review. • Where is the test environment?(Where) ◦ We must use the staging environment before release. • Why are we running the test?(Why) ◦ To prevent customer distrust due to defects and loss of efficiency due to fixing bugs.
19. Test format Since IE has been the most common cause of problems, we will definitely test Chrome and IE.
20. Timing of test execution version increment v1.3.4 main dev feature/.. feature/.. ・Create test cases for dev when creating PR ・Test execution in the staging environment after merging ・Perform testing for each feature
21. Template PR for dev merge • description of PR • Are there any changes to the architecture diagram? • Will you share changed by GoogleMeet? • Do you want to advices? • Have the testing case ever gotten reviewed by member? • Is there affected to webview?
22. Automatic template generation when creating a github PR First you create the . /github folder in the root directory of the project folder in the root directory of the project folder. Secound, create a PULL_REQUEST_TEMPLATE.md file and write it in markdown notation. Then, when you create the PR, the template will be generated as shown in the image.
23. Like this.
24. When to merge from dev to main main dev feature/.. feature/.. this!
25. The template when to merge from dev to main • URL of the merged PR • Did you finish the testing by IE and Google Chrome?
26. Results Before： 2,3 times/month After： 0 times/month Bug reports due to release update ※Results for April and May
27. Supplementary information The template text for merging from feature to dev, The template text for merging from dev to main, I put both in the same PULL_REQUEST_TEMPLATE.md and delete unnecessary text as needed.
28. Last message・・・ Please search 「コープさっぽろDX」!