$30 off During Our Annual Pro Sale. View Details »

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

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

生活協同組合コープさっぽろ
ヒグ!(樋口修也)

CO-OP Sapporo

August 25, 2021
Tweet

More Decks by CO-OP Sapporo

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  6. 昔ばなし
    理由はもちろんリソース不足のためです(笑)

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  22. こんな感じ

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide