テストコード文化を0から作り、変化し続けた組織

2024/12/07 ソフトウェアテスト自動化カンファレンス2024

Transcript

1. テストコード文化を0から作り、変 化し続けた組織 2024/12/07 ソフトウェアテスト自動化カンファレンス2024 @zosokh
2. ヒエイカザト 株式会社ウエディングパーク エグゼクティブエンジニア +Creation本部 TECH戦略室 　 @zosokh　#野球観戦 #ちなヤク #二児の父
3. 運営メディア 結婚の各領域に特化した専門メディアを運営。ITを活用し、カップルと 様々なウエディングサービスのベストマッチを実現します。 海外挙式の日本最大級クチコミ& フォトサイト ドレス選びがもっと楽しくなるクチコミ サイト フォトウエディングの決め手が見つか るクチコミサイト 指輪選びの決め手が見つかるクチ コミサイト 経営理念：「結婚を、もっと幸せにしよう。」 ビジョン：「21世紀を代表するブライダル会社を創る」
4. 運営メディア ノーコードツール デジタル広告 オンラインスクール DX推進 結婚式費用試算サービス
5. 今日の話 組織にテストコード設置を根付かせたい方に、自チームや全社組織にテ ストコード導入のナレッジを話します チームとテストコード 全社推進に向けた テストコード効果検証 全社推進へのアクション とその後
6. チームとテストコード まずは1チームにテストコードを書く文化醸成 チームとテストコード 全社推進に向けた テストコード効果検証 全社推進へのアクション とその後
7. チームとテストコード｜ 導入編
8. 以前所属していた開発チームの話 • 当時はテストコードを書く文化は無かった • アプリケーション内に、僅かなテストコードが設置 ◦ 動いているか分からない状態 • 障害時に人的フロー対策体制を敷く。自動テストなど人的に頼 らない仕組みで防御する対応を行えていない 一つのチームにテストコード文化醸成
9. • チーム内にテストコードを書く習慣がない ◦ 書く方法がわからない・テスト実行環境もない • 書いて何が良くなるのかわからない なんとなく書かれているテストコードがある チームにテストコード導入を検討したいが
10. • テストコードを書くための環境づくり • 目標を決めたテストコード拡張 の行動を始める テストコードを書く体制を模索
11. テストコードを書くための環境づくり ┗ローカル環境 Dockerでテスト環境を用意 • テスト用ローカルDB • 1コマンドでDockerコン テナ上でのPHPUnitを実 行 • 他アプリケーションに依 存させない設計
12. テストコードを書くための環境づくり ┗CI環境
13. テストコードを書くための環境づくり ┗CI環境 レビュー時のテスト状態とカバレッジ値表示 Readmeにメインブランチのカバレッジ数値表示と カバレッジレポートを閲覧できる環境を用意
14. coverage: 2% まぁそんなもんか・・・ そして当時のカバレッジは・・
15. • 書きやすいところから書いていこうというラフなルール感を設定 • とにかくテストの量を増やす事を目的 👉 カバレッジ値をチームの目標におく 初回は、「カバレッジ10%まで上げよう」を活動目標に掲げる ここで辛さを感じる・・ ではテストを書いていきましょう。目標設定編
16. どんなに頑張っても1%を上げるのに苦労 ┗テストを書いていない箇所が多すぎて、数メソッドテストを書い てもカバレッジに変化が起きない ┗テストコード書ける設計になっていない 範囲を指定してカバレッジを計測する目標にすれば良かった 既存のPJ（テスト無し） にテストを書く難しさ
17. テストになっていない・・ チームとしても、テストコード実装の熱量に差がある 👉 書き方がわからないメンバーを救済できていない 目標に追われてこんなテストコードが量産 public function test_selectRecords() { $response = $this->model->getAll(); $this->assertIsArray($response->records); }
18. • 新規実装部分にだけ、テストを設けていこう（既存機能にテス トを設けるのは辛い） • ペアプロを用いてテストコードの書き方をレクチャー。コード レビューで議論を多く行う事も ここでやり方を変える
19. • カバレッジ数値が微妙に上がってくる • 不具合発見時に、テストコードへ恒久的な対策を施せる事例が 出る 👉 テスト自動化の効果を実感 変化①
20. 中途で新入社員が入社 • テストコード状況への課題感に共感してくれる • 2人（私・新入社員）で背中を見せる行動が増える。チームのテ ストコードへの意識変化が加速 • テストコードのためのリファクタリング、チーム全体でテスト コードを拡張する時間が増える 変化②
21. テストコードへの角度が高いメンバー数が増えたことで • 2人が行う実装はテストコードを混ぜたPRをガンガン出しまく る • コードレビューでは、2人でテストコード実装面のノウハウを他 メンバーにも布教やサポートを行う • テストコード実装の意思1人に近かった状態から、あっという間 にチームに蔓延する 変化② | ここで良かったこと深掘り
22. チームとテストコード｜ ぜんぶ書く編
23. アプリケーションリプレイスの話がやってくる このタイミングでテストコードを全て網羅したアプリケーションを 立ち上げようと決意 「テストコードぜんぶ書く」を始める
24. テストコード全部書く 個人的には、テストを全て設置したアプリケーションを作成するの は初めて 初回は工数感が予定より遅れながらも、実装の仕方を掴んでいき、 徐々に進捗が進む（慣れ）
25. そしてリプレイス完了。リリースへ その時のカバレッジは 92%！！ フロントのReactコンポーネントにもテストを都度実装 やった〜！！！！
26. この時のCI環境 アプリケーション複数のカバレッジ値を GitHub上でoctcovsを利用して管理 https://engineers.weddingpark.co.jp/github_actio ns_octocov/
27. 開発中の話 常時composer（PHPのパッケージ管理システム）の内容をアップ デート。テストが通る安心感からスピード感高くマージができる 👉毎日最新アプリケーションに更新 ┗これはリリース後も継続
28. • 毎日composer アップデート • PHP・フレームワークアップデートが簡単にできるようになる 👉この後詳細を話します • 「人的に頼らない仕組みで防御」の形が一つ環境が築けた リリース後の変化
29. チームとテストコード｜ まとめ
30. テストコードを書かなかったチームが、今では、テストコードの設 置が当たり前になる 👉 現在私はチームから離れているが、チームとしてはテストコード 拡張が完全に自己組織化 チームとテストコード（まとめ）
31. 全社推進に向けた テストコード効果検証 全社水準へ変化 チームとテストコード 全社推進に向けた テストコード効果検証 全社推進へのアクション とその後
32. 全社推進に向けたテストコード効果検証｜ 社内施策の実施編
33. 「TECH PASS」という社内施策がある。技術研究期間を与えられ、事業 ・組織に貢献を目指した開発期間を与えられる事に 👉 チームから全社へ、テストコードを導入する手法を模索するミッ ションを持った 半年間、技術検証や開発のリソースを割ける事に https://www.wantedly.com/companies/weddingpark/post_articles/455459 社内施策の実施
34. なにをやろうか検討する 　　　　　　　　　　　　　　　　 　に着目 👉 テストコード整備による効果を示せる用になれば、導入への強い 判断材料となるのではと考える 全社テストコード推進のため
35. 弊社にはQAテストというスプレッドシートにまとめたテスト項目 （以降テスト仕様書）をブラウザテストしていくフローがある ※リリース前の必須フロー 👉このテスト仕様書が、テストコードでどれぐらいカバーできるか 検証する。定量的にカバー率を出し、QAテスト削減へ恩恵があるこ とを証明したい テストコード効果を立証してみよう
36. リリースしたリプレイスアプリケーションのテストコードが、どれ ぐらいテスト仕様書を網羅されているが調べる テスト仕様書とテストコードのカバー率
37. リプレイス案件リリース時にQAテストを行った時の、テスト仕様書 項目数 合計　6928 のテスト項目 テスト仕様書項目数
38. テスト仕様書のテストコード網羅状態 リリースフェーズ テスト項目行数 カバー済み 一部カバー済み 未カバー 1 24 15 7 2 2 674 143 318 213 3 3735 2866 160 709 4 2206 1817 122 267 5 289 35 20 234 6928 4876 627 1425
39. リリースフェーズ テスト項目行数 カバー済み 一部カバー済み 未カバー 1 24 15 7 2 2 674 143 318 213 3 3735 2866 160 709 4 2206 1817 122 267 5 289 35 20 234 6928 4876 627 1425 テスト仕様書のテストコード網羅状態 テストコードでテストできている 項目 データ内容のテストはできている けれど、表示面のテストはできて いない テストコードでテストできていな い
40. リリースフェーズ テスト項目行数 カバー済み 一部カバー済み 未カバー 1 24 15 7 2 2 674 143 318 213 3 3735 2866 160 709 4 2206 1817 122 267 5 289 35 20 234 6928 4876 627 1425 テスト仕様書のテストコード網羅状態 ・データが保存される ・バリデーションにかかる ・◦件表示されている ・データのアサインのテストはできているが、表示面（ボ タンをプッシュ、文字やボタンの色）も指定されたテスト は網羅できていない ・ボタンを押したら公開ステータスが非公開となる。該当 の公開ステータスもグレーとなる。 　　→更新について、サーバーサイド側の更新やデータ整 合性のテストはできているが、フロント表示面をカバーで きていない ・チェックボックスのONOFFができる ・〇〇の項目（文字列・ボタン・リンク ・・）が表示されている ・フロントでの出し分け表示テスト →テストコード元々無い →テストコード実装漏れ・範囲漏れ →テストコードが実装に苦戦した項目
41. リリースフェーズ テスト項目行数 カバー済み 一部カバー済み 未カバー 1 24 15 7 2 2 674 143 318 213 3 3735 2866 160 709 4 2206 1817 122 267 5 289 35 20 234 6928 4876 627 1425 テスト仕様書のテストコード網羅状態 テストコードで完全整備され、テスト 仕様書項目を削減できる
42. リリースフェーズ テスト項目行数 カバー済み 一部カバー済み 未カバー 1 24 15 7 2 2 674 143 318 213 3 3735 2866 160 709 4 2206 1817 122 267 5 289 35 20 234 6928 4876 627 1425 テスト仕様書のテストコード網羅状態 一部テスト項目漏れがあるが、テスト コードによるカバーができている。 しかし同範囲をリリース時はテストデ バッグが必要。
43. リリースフェーズ テスト項目行数 カバー済み 一部カバー済み 未カバー 1 24 15 7 2 2 674 143 318 213 3 3735 2866 160 709 4 2206 1817 122 267 5 289 35 20 234 6928 4876 627 1425 テスト仕様書のテストコード網羅状態 全くテストコードが整備されていない
44. テスト仕様書のテストコード網羅状態 70.38% 79.43% 20.57% リリースフェーズ テスト項目行数 カバー済み 一部カバー済み 未カバー 1 24 15 7 2 2 674 143 318 213 3 3735 2866 160 709 4 2206 1817 122 267 5 289 35 20 234 6928 4876 627 1425
45. テスト工数 リリースフェーズ テスト仕様書作成（人日） テスト工数（人日） 1 0.2 0.4 2 1.5 14 3・4 3 18 5 2 16 合計 6.7人日 48.4人日
46. テスト工数を省けるか リリースフェーズ テスト仕様書作成（人日） テスト工数（人日） 1 0.2 0.4 2 1.5 14 3・4 3 18 5 2 16 6.7 ×　　　　　　　　　 48.4 ×　　　　　　　　　 テストコード未カバー 20.57% テストコード未カバー 20.57%
47. テストコードで、テスト工数を省けるか リリースフェーズ テスト仕様書作成（人日） テスト工数（人日） 1 0.2 0.4 2 1.5 14 3・4 3 18 5 2 16 6.7 ×　　　　　　　　　 48.4 ×　　　　　　　　　 0.25人日 9.95人日 40人日以上削減できる事になる ※単純計算なので実際はそこまで極端では ないと思います テストコード未カバー 20.57% テストコード未カバー 20.57%
48. テストコード作成の工数がかかった事も忘れてはならない 以下の方法で算出 • テストコード含めた PRを洗い出し、初回commit時間〜最後のcommit時間 をテストコード作成工数と捉える 開発全体にかかった工数も割り出す • リプレイス開発期間中の給料明細から、稼働時間などを算出 テストコード作成工数計算
49. スクリプト実行 テストコード作成工数計算
50. テストコード作成にかかった割合 テストコード工数合算（人日） スクリプトから作成 開発完了までの人日 給料明細の稼働時間から作成 全開発の中でテストコード作成 の割合 **.2 ***.815 34.52%
51. テストコード作成にかかった割合 テストコード工数合算（人日） スクリプトから作成 開発完了までの人日 給料明細の稼働時間から作成 全開発の中でテストコード作成 の割合 **.2 ***.815 34.52% 開発期間（9ヶ月）の中、 単純計算で　3.1ヶ月をテストコード作成に充てていた
52. ローンチ後3ヶ月のリリース 案件 回数 開発工数 テスト工数 composer update 15 0 0 Github移行 1 7 0 フレームワークVer Up 1 6 2 リリース後の施策 1 4 1
53. ローンチ後3ヶ月のリリース 案件 回数 開発工数 テスト工数 テストコードが無かった時 のテスト工数 composer update 15 0 0 ？？？ Github移行 1 7 0 0 フレームワークVer Up 1 6 2 40 リリース後の施策 1 4 1 4
54. ローンチ後3ヶ月のリリース 案件 回数 開発工数 テスト工数 テストコードが無かった時 のテスト工数 composer update 15 0 0 ？？？ Github移行 1 7 0 0 フレームワークVer Up 1 6 2 40 リリース後の施策 1 4 1 4 計り知れない。テストコードが無 かったら定期的なアップデートは 出来ないかもしれない 他のPJのアップデート時を参考
55. 全社推進に向けたテストコード効果検証｜ テストコードの効果定量化、結論編
56. 工数面の恩恵 • リプレイスアプリケーションでは、テストコード作成工数を差 し引いても、リリース時のQAテスト工数やバージョンアップな どの保守運用工数の削減ができる計算だった テストコードの効果・恩恵 テストコード作成工数 テストコードで削減でき たQAテスト工数 テストコードで削減でき たバージョンアップ工数 効果 1ヶ月20人日 × 3.1ヶ月 = 62人日 -40人日 -38人日 -16人日 ※効果の数値は運用していく時間が増えるほど増えていく
57. リリース数の恩恵 • 定期的なライブラリのバージョンアップと、工数をかけない バージョンアップ対応が可能 リプレイスアプリケーションは、バージョンアップを工数をかけず に行えている テストコードの効果・恩恵
58. 疑問
59. それは・・・・ 確かにそうかもですが、この検証の機会があった事に感謝していま す 定量的な効果を示す活動に時間を割けた事は、エンジニア人生の中 でも貴重な調査期間 この検証をする時間で、テスト書けたのでは？
60. 全社推進に向けたテストコード効果検証｜ まとめ
61. 推進のための提案材料が整ってきた • テストコードの運用面の有効さは証明できた • テストコードを設置したいと思っているエンジニアも多い（ヒアリ ング） • もちろんテストコードは、リリース物のクオリティアップにつなが る 👉 じゃあ是非テストコード体制設置を！の話に持っていきたい 全社推進に向けたテストコード効果検証（まとめ）
62. 全社推進へのアクションと その後 全社にテストコード取り組みへ チームとテストコード 全社推進に向けた テストコード効果検証 全社推進へのアクション とその後
63. 全社推進へのアクションとその後｜ 方針模索編
64. 課題：エンジニアがテストを書く意思決定ができない • スキルがない ◦ テストコードを書けない・書き方が分からない • 工数がない ◦ テスト作成の工数が分からない。工数の取り方が分からない 👉 経験が無いのでエンジニア個人から、事業インパクトと有効性の説 明を事業メンバーにできる人が少ない 効果証明だけでは足らない
65. 前提：テストコードを書かなくても、今までやってきたQAテストで バグを検知はできる QAテストでの不便な点や、テストコード有効さは分かっていても、 テスト作成のスキル獲得へコストがネックになり、 QAテスト実行 を選択してしまうという声もあった ※テストコードとQAテストは、互いにテストを設けやすい項目や特化したテスト範囲が違うので、良いところを使い分けていく のがベター QAテストについて
66. 書かない事が必ずしも悪い事ではない テストコードを書く≠ 正義 テストコードを書かない ≠ 悪 例： 事業フェーズや事業都合による、テストコードを書かないという意思決定自 体は尊重されるべき • 新規事業立ち上げ時など、高速サイクルでプロトタイピングを行いたい そもそもテストコードを書く事について
67. QAテストだけに頼る課題は無視できない じゃあ書かなくても良いわけでも無い
68. 目標を変えた 事業やプロダクトの状態を見て、適切な判断でテストコード導入を 検討できる状態にしたい > 中長期な運用面効率化をしていきたい > 現状のテスト負荷増加の課題を軽減したい > リリースサイクルをさらに早めていきたい > 恒久的なバグ対策を仕込みたい 上記のために戦術として、テストコードを設ける手法を選択できる 組織を作る
69. 課題： エンジニアから、事業インパクトと有効性の説明をできる人が少な い テストコードを戦術として採用するには、プレイヤーのスキルと経 験が足らない 適切な判断でテストコード導入検討できるか
70. 戦略： • テストコードを書ける • 自分のPJでテストコードを書く経験をさせる 👉 テストコードを書ける前提で、テストコードの戦術を選択ができる状態にする 上記に向けて、社内エンジニアがテストコードを書くために全面サ ポートするべきと考えた 今やるべき事
71. テストコードの研修とコンサルティングを行う 結論
72. 他部署のエンジニアに対し、テストコードの研修とコンサルティン グを行う • PHPUnitテストの設け方の研修を行う • 担当のPJコードから設けられるテストコードの提案とレク チャーを行う • テストコードの入ったPRを全面的にレビューを行う 方針
73. 他部署のエンジニアに対し、テストコードの研修とコンサルティン グを行う • PHPUnitテストの設け方の研修を行う • 担当のPJコードから設けられるテストコードの提案とレク チャーを行う • テストコードの入ったPRを全面的にレビューを行う 方針 この取り組みから、上記の事例を作っていく取り組み
74. 全社推進へのアクションとその後｜ 実行編
75. 研修カリキュラムとフローを実行 カリキュラムカテゴリ 内容 目的 PHPUnitテストの設け方の講義と基本ワーク ・テストコードの効果とプロジェクトの実例・扱 い方を紹介 ・PHPUnit基本講座とワーク 基本的な扱い方を学び、実際に手を動かし PHPUnitを知る 既存のPJコードから設けられるテストコードを 提案とレクチャー ・自プロジェクトからどんなテストコードを作れ るか知る ・自プロジェクトでPHPUnit環境を立ち上げる ・自プロジェクトでテストコードを書く 今後自身でテストコード拡張を作れるよう にする テストコードの入ったPRを全面的にレビュー ・継続的なテストコード作成とレビュー 拡張したテストコードのレビュー体制を経 験し、テストコードを書き続ける
76. • 研修実行するエンジニアチームを決め、研修実行 • カリキュラム外にも、担当PJの環境作成の整備サポートに入っ た 👉基礎研修などを通しても、結局は担当PJでのテストコード実装と レビューが一番理解度が上がることを知る やったこと
77. 良い点 • テストコードを組み込むチームが増える • スキルアップ観点でテストコード実装を目標に入れる人が出る ◦ 個人の目標からチームミッションに昇華する事例も出てきた 課題点 • 定着にはまだ遠い。現状もテストコード実装が、「追加タスク」で あり「優先度が低」の認識状態がある 結果
78. まとめ
79. 一番最初は1チームでテスト コード実装文化醸成の事例がで きた テストコード全面実装事例を出 し、テストコードがある効果を 実感できる状態も作った まとめ テストコードの有益性を立証す るため、定量的な効果をまとめ る 効果証明だけでは組織は動かせず、エン ジニア個人のスキル向上を狙っていく ┗事業やプロダクトの状態を見て、適切 な判断でテストコード導入を検討できる 状態を目指す テストコード研修実施。まだ定着率は低 いが、自発的なテストスキル確立や方針 にテスト設置を置くチームが出てくる チームとテストコード 全社推進に向けた テストコード効果検証 全社推進へのアクション とその後
80. 🌱が見えてきた形だが、組織全体がテストコードを書いていくため にはまだまだ障壁がある 「テストコード実装は追加工数ではない」 当たり前にテストコード設置を模索できる組織を目指していく 結論
81. 会社として、「小さく・早く」をモットーにしている 企業カルチャーの精神を取り組みに。個人に収めず、組織全体の力にしていく行動 　「チームウエディングパークでいく。チームでしかいけないところがある。」 　小さな人数でプロトタイピングを繰り返し、成果事例を作り、取り組みを拡大していく 　取り組みに全員で協力し、同じ未来へ全員でいく 結論 チームとテストコード 全社推進に向けた テストコード効果検証 全社推進へのアクション とその後 https://speakerdeck.com/weddingpark/weddingpark-culture-book
82. ご清聴ありがとうございました