絶対にテストコードを書かないチームのテストルール

生活協同組合コープさっぽろ
ヒグ！（樋口修也）

Transcript

1. 絶対にテストコードを書かないチームのテストルール 生活協同組合コープさっぽろ ヒグ！（樋口修也）
2. 発表者 フロントエンド,認証認可 2015年 旭川→岩手大学へ入学 2019年 東京のIT企業に新卒入社 2020年 コープさっぽろへ転職し札幌へ ダブルダッチ、筋トレ、ダンス AWS CDK, Vue.js Youtubeはじめました! 樋口修也(24) 担当: 経歴: 趣味: 好み: 最近:
3. コープさっぽろDXとは？ 小売業界の巨大組織 • 180万人以上の組合員 • 約3000億円の年間売上 • 1万人以上の従業員 コープさっぽろがもっと 使いやすく、買い物しやすく、働きやすく デジタル集団 • 4人のAWS samurai認定者 • 16人の内製エンジニア • 20年以上付き合いがあるシ ステムベンダー デジタル(D)の力で巨大組織を変革(X)が昨年秋始動!
4. コープさっぽろ昔ばなし 昔って言っても半年ぐらい前まであった 怖い話 ※ごく一部のチームの話です
5. 昔ばなし むかーしむかし、 あるところにテストコードどころか、 テストケースすら作成しないでリリースしてい るチームがありました。 ※フロントエンドです テストケース作ってやる のはメジャーリリースだ けな！
6. 昔ばなし 理由はもちろんリソース不足のためです（笑）
7. 昔ばなし メジャーリリースだけテストケースは作るもの の、軽微な改修に関してはエンジニアと担当 したディレクションが確認してリリースというこ とに もちろんお互い何を確認したか把握できてい ません ヨシ！ ヨシ！ エンジニア ディレクション
8. 昔ばなし そして鳴り止まぬコールセンターとお 叱りの声をたくさんいただきました。
9. 昔ばなし 最終的に開発チームは更にふりかか るPJと問い合わせ対応、改修に追わ れて心が病みました。。 めでたしめでたし。
10. 昔ばなし という怖い話が２度と起きないように この教訓を広げれればいいなと思います
11. そもそもなんでこんなことになったか？ • 納期 ◦ ビジネスサイドがエンジニアが入協する前にリリース期日を先に決め ていた ▪ 正確なシステムの見積もりができていない ▪ テストを工数に組み込んでいない • 品質 ◦ 詳細な要件を固めないで制作に入っていた ▪ ファーストリリース分のみテストケースを作っていた ▪ リリース後に不具合を改修をすると決めていた ▪ リリース直前にIEを対応することになった
12. フォーカスポイント(他は今度たっぷり話します) • 納期 ◦ ビジネスサイドがエンジニアが入協する前にリリース期日を先に決め ていた ▪ 正確なシステムの見積もりができていない ▪ テストを工数に組み込んでいない • 品質 ◦ 詳細な要件を固めないで制作に入っていた ▪ ファーストリリース分のみテストケースを作っていた ▪ リリース後に不具合を改修をすると決めていた ▪ リリース直前にIEを対応することになった
13. リリース後の改修 お問い合わせ 改修内容選定 実装 テスト
14. テストどーする問題 • テストの形式は？(How) ◦ 運用テスト？結合テスト？単体テスト？ • 何をテストする？(What) • レビューは誰が行う？(Who) • いつ行う？(When) • 実施環境はどうするか？(Where) • なぜテストに工数をさかなくてはいけない？(Why) 一般IT企業ではルール化されているものが 立ち上げチームにはない＞＜
15. リリース後の終わらない改修 お問い合わせ 改修内容選定 実装 テスト 更なるバグ
16. リリース後の終わらない改修 お問い合わせ 改修内容選定 実装 テスト 各人で行うので担当し たディレクションエンジ ニアによってばらつき が出る 更なるバグ 随時問い合わせか ら原因究明なので 効率も下がる
17. 改善案 • テストの形式は？ ◦ フロントチームはユーザーストーリーテストのみ絞って行う • 何をテストする？ ◦ スプレッドシートをテンプレート化して使い回す • レビューは誰が行う？ ◦ コードレビューを行った人 • いつ行う？ ◦ コードレビューの際 • 実施環境はどうするか？ ◦ リリース直前の検証環境を必ず利用する • なぜテストに工数をさかなくてはいけない？(Why) ◦ 不具合を出して顧客の信頼不審やバグ改修による効率の低減を防ぐため (学び)
18. テストの形式 今までの中でIEによる不具合が 圧倒的に多かったので Chrome とIEのテストを絶対に実施する
19. テスト実施のタイミング バージョンインクリメント v1.3.4 main dev feature/.. feature/.. ・devへのPRでテスト ケース作成 ・マージ後検証環境でテ スト実施 ・これをfeatureごとに行 う
20. devへのPRのテンプレート化 • PRの概要説明 • アーキ図への変更の有無 • GoogleMeetでの共有の有無 • 相談事項などあれば • テスト項目のレビュー • webviewへの影響の有無 • IEでのテスト実施の有無
21. githubのPR作成時にテンプレ自動生成 プロジェクトフォルダのルートディレクトりに ./github フォルダを作って PULL_REQUEST_TEMPLATE.md ファイ ルを作ってマークダウン記法で書くと、PR 作成時に画像のような形でテンプレートが 生成されます。
22. こんな感じ
23. devからmainのマージのタイミング バージョンインクリメント v1.3.4 main dev feature/.. feature/..
24. devからmainへマージの時のテンプレート • マージしたPRのURL • IEとChromeでテストしたか否か？
25. 成果 フロー作成前： 月2,3件 フロー作成後 : 月0件 改修に伴うバグ報告 ※ざっくり調べ
26. ちなみに featureからdevへのマージのテンプレート文章も devからmainへのマージのテンプレート文章も 同じPULL_REQUEST_TEMPLATE.mdに記載して必要に応じて削除しています
27. 一応CI/CDのフローを真似て作りました main dev feature/.. feature/.. ・PRでテストのレビュー ・マージ後すぐにdevでテスト の実施 ・PRでlintの実施 ・マージのタイミングで自動テス トの実施 今回のテスト運用フロー 一般的なCI/CD ※このフローはコープさっぽろ のエンジニア、岡部さん、和泉 さん、伊藤さんと共に考えまし た
28. そもそもテストとは コードの品質を担保するための仕組み 自動化も手動テストも仕組み次第
29. 手動テストに絞ることでできること エンジニアがテストケースを作って 実行をお願いする
30. エンジニアがテストケースを作って実行をお願いする エンジニア 顧客体験 その他 負担 5 : 5 テストケース洗い出し テストケース作成 テストの実施 ユーザー体験の確認
31. 無理にテストコードを書いた場合 エンジニア 顧客体験 その他 負担 10 : 0 テストケース洗い出し テストコード作成 テストコードのPRと修正...など
32. テストコードのいいところ テストを自動化して効率化 単体テストを入れることでコードの品質を評価 修正して再テストが容易
33. 前職の時と比較して実感するメリット・デメリット • テストの工数を分担できる • テストケースも直しやすい • テストで不具合があった時の出戻 りが大きい • 利用規約の同意やユーザーの表 示など必ず間違えてはいけない場 所を毎回テストできる • こまめに走らせることでコアな部分 の不具合を早めに見つけられる • テスタビリティの観点からコードの 品質を確認できる • 実装コストが大きい • 全てのテストは自動化できない 手動テスト 自動テスト やっぱテストコード欲しい。。
34. 最後に 自動テストデータの扱いやすさ 手動テストの柔軟性 双方の長所を活かして生産性の向上に繋げていきたい
35. 本当に最後・・・ 「コープさっぽろDX」で検 索！ Flutter大学KBOYさんと のマッチアップの話も！