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

by CO-OP Sapporo

Slide 1

Slide 1 text

絶対にテストコードを書かないチームのテストルール生活協同組合コープさっぽろヒグ！（樋口修也）

Slide 2

Slide 2 text

発表者フロントエンド,認証認可 2015年旭川→岩手大学へ入学 2019年東京のIT企業に新卒入社 2020年コープさっぽろへ転職し札幌へダブルダッチ、筋トレ、ダンス AWS CDK, Vue.js Youtubeはじめました! 樋口修也(24) 担当: 経歴: 趣味: 好み: 最近:

Slide 3

Slide 3 text

コープさっぽろDXとは？小売業界の巨大組織 ● 180万人以上の組合員 ● 約3000億円の年間売上 ● 1万人以上の従業員コープさっぽろがもっと使いやすく、買い物しやすく、働きやすくデジタル集団 ● 4人のAWS samurai認定者 ● 16人の内製エンジニア ● 20年以上付き合いがあるシステムベンダーデジタル(D)の力で巨大組織を変革(X)が昨年秋始動!

Slide 4

Slide 4 text

コープさっぽろ昔ばなし昔って言っても半年ぐらい前まであった怖い話 ※ごく一部のチームの話です

Slide 5

Slide 5 text

昔ばなしむかーしむかし、あるところにテストコードどころか、テストケースすら作成しないでリリースしているチームがありました。 ※フロントエンドですテストケース作ってやるのはメジャーリリースだけな！

Slide 6

Slide 6 text

昔ばなし理由はもちろんリソース不足のためです（笑）

Slide 7

Slide 7 text

昔ばなしメジャーリリースだけテストケースは作るものの、軽微な改修に関してはエンジニアと担当したディレクションが確認してリリースということにもちろんお互い何を確認したか把握できていませんヨシ！ヨシ！エンジニアディレクション

Slide 8

Slide 8 text

昔ばなしそして鳴り止まぬコールセンターとお叱りの声をたくさんいただきました。

Slide 9

Slide 9 text

昔ばなし最終的に開発チームは更にふりかかるPJと問い合わせ対応、改修に追われて心が病みました。。めでたしめでたし。

Slide 10

Slide 10 text

昔ばなしという怖い話が２度と起きないようにこの教訓を広げれればいいなと思います

Slide 11

Slide 11 text

そもそもなんでこんなことになったか？ ● 納期 ○ ビジネスサイドがエンジニアが入協する前にリリース期日を先に決めていた ■ 正確なシステムの見積もりができていない ■ テストを工数に組み込んでいない ● 品質 ○ 詳細な要件を固めないで制作に入っていた ■ ファーストリリース分のみテストケースを作っていた ■ リリース後に不具合を改修をすると決めていた ■ リリース直前にIEを対応することになった

Slide 12

Slide 12 text

フォーカスポイント(他は今度たっぷり話します) ● 納期 ○ ビジネスサイドがエンジニアが入協する前にリリース期日を先に決めていた ■ 正確なシステムの見積もりができていない ■ テストを工数に組み込んでいない ● 品質 ○ 詳細な要件を固めないで制作に入っていた ■ ファーストリリース分のみテストケースを作っていた ■ リリース後に不具合を改修をすると決めていた ■ リリース直前にIEを対応することになった

Slide 13

Slide 13 text

リリース後の改修お問い合わせ改修内容選定実装テスト

Slide 14

Slide 14 text

テストどーする問題 ● テストの形式は？(How) ○ 運用テスト？結合テスト？単体テスト？ ● 何をテストする？(What) ● レビューは誰が行う？(Who) ● いつ行う？(When) ● 実施環境はどうするか？(Where) ● なぜテストに工数をさかなくてはいけない？(Why) 一般IT企業ではルール化されているものが立ち上げチームにはない＞＜

Slide 15

Slide 15 text

リリース後の終わらない改修お問い合わせ改修内容選定実装テスト更なるバグ

Slide 16

Slide 16 text

リリース後の終わらない改修お問い合わせ改修内容選定実装テスト各人で行うので担当したディレクションエンジニアによってばらつきが出る更なるバグ随時問い合わせから原因究明なので効率も下がる

Slide 17

Slide 17 text

改善案 ● テストの形式は？ ○ フロントチームはユーザーストーリーテストのみ絞って行う ● 何をテストする？ ○ スプレッドシートをテンプレート化して使い回す ● レビューは誰が行う？ ○ コードレビューを行った人 ● いつ行う？ ○ コードレビューの際 ● 実施環境はどうするか？ ○ リリース直前の検証環境を必ず利用する ● なぜテストに工数をさかなくてはいけない？(Why) ○ 不具合を出して顧客の信頼不審やバグ改修による効率の低減を防ぐため (学び)

Slide 18

Slide 18 text

テストの形式今までの中でIEによる不具合が圧倒的に多かったので Chrome とIEのテストを絶対に実施する

Slide 19

Slide 19 text

テスト実施のタイミングバージョンインクリメント v1.3.4 main dev feature/.. feature/.. ・devへのPRでテストケース作成・マージ後検証環境でテスト実施・これをfeatureごとに行う

Slide 20

Slide 20 text

devへのPRのテンプレート化 ● PRの概要説明 ● アーキ図への変更の有無 ● GoogleMeetでの共有の有無 ● 相談事項などあれば ● テスト項目のレビュー ● webviewへの影響の有無 ● IEでのテスト実施の有無

Slide 21

Slide 21 text

githubのPR作成時にテンプレ自動生成プロジェクトフォルダのルートディレクトりに ./github フォルダを作って PULL_REQUEST_TEMPLATE.md ファイルを作ってマークダウン記法で書くと、PR 作成時に画像のような形でテンプレートが生成されます。

Slide 22

Slide 22 text

こんな感じ

Slide 23

Slide 23 text

devからmainのマージのタイミングバージョンインクリメント v1.3.4 main dev feature/.. feature/..

Slide 24

Slide 24 text

devからmainへマージの時のテンプレート ● マージしたPRのURL ● IEとChromeでテストしたか否か？

Slide 25

Slide 25 text

成果フロー作成前：月2,3件フロー作成後 : 月0件改修に伴うバグ報告 ※ざっくり調べ

Slide 26

Slide 26 text

ちなみに featureからdevへのマージのテンプレート文章も devからmainへのマージのテンプレート文章も同じPULL_REQUEST_TEMPLATE.mdに記載して必要に応じて削除しています

Slide 27

Slide 27 text

一応CI/CDのフローを真似て作りました main dev feature/.. feature/.. ・PRでテストのレビュー・マージ後すぐにdevでテストの実施・PRでlintの実施・マージのタイミングで自動テストの実施今回のテスト運用フロー一般的なCI/CD ※このフローはコープさっぽろのエンジニア、岡部さん、和泉さん、伊藤さんと共に考えました

Slide 28

Slide 28 text

そもそもテストとはコードの品質を担保するための仕組み自動化も手動テストも仕組み次第

Slide 29

Slide 29 text

手動テストに絞ることでできることエンジニアがテストケースを作って実行をお願いする

Slide 30

Slide 30 text

エンジニアがテストケースを作って実行をお願いするエンジニア顧客体験その他負担 5 : 5 テストケース洗い出しテストケース作成テストの実施ユーザー体験の確認

Slide 31

Slide 31 text

無理にテストコードを書いた場合エンジニア顧客体験その他負担 10 : 0 テストケース洗い出しテストコード作成テストコードのPRと修正...など

Slide 32

Slide 32 text

テストコードのいいところテストを自動化して効率化単体テストを入れることでコードの品質を評価修正して再テストが容易

Slide 33

Slide 33 text

前職の時と比較して実感するメリット・デメリット ● テストの工数を分担できる ● テストケースも直しやすい ● テストで不具合があった時の出戻りが大きい ● 利用規約の同意やユーザーの表示など必ず間違えてはいけない場所を毎回テストできる ● こまめに走らせることでコアな部分の不具合を早めに見つけられる ● テスタビリティの観点からコードの品質を確認できる ● 実装コストが大きい ● 全てのテストは自動化できない手動テスト自動テストやっぱテストコード欲しい。。

Slide 34

Slide 34 text

最後に自動テストデータの扱いやすさ手動テストの柔軟性双方の長所を活かして生産性の向上に繋げていきたい

Slide 35

Slide 35 text

本当に最後・・・「コープさっぽろDX」で検索！ Flutter大学KBOYさんとのマッチアップの話も！