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