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

Slide 1

Slide 1 text

テストコード文化を0から作り、変化し続けた組織 2024/12/07 ソフトウェアテスト自動化カンファレンス2024 @zosokh

Slide 2

Slide 2 text

ヒエイカザト株式会社ウエディングパークエグゼクティブエンジニア +Creation本部 TECH戦略室　 @zosokh　#野球観戦 #ちなヤク #二児の父

Slide 3

Slide 3 text

運営メディア結婚の各領域に特化した専門メディアを運営。ITを活用し、カップルと様々なウエディングサービスのベストマッチを実現します。海外挙式の日本最大級クチコミ& フォトサイトドレス選びがもっと楽しくなるクチコミサイトフォトウエディングの決め手が見つかるクチコミサイト指輪選びの決め手が見つかるクチコミサイト経営理念：「結婚を、もっと幸せにしよう。」ビジョン：「21世紀を代表するブライダル会社を創る」

Slide 4

Slide 4 text

運営メディアノーコードツールデジタル広告オンラインスクール DX推進結婚式費用試算サービス

Slide 5

Slide 5 text

今日の話組織にテストコード設置を根付かせたい方に、自チームや全社組織にテストコード導入のナレッジを話しますチームとテストコード全社推進に向けたテストコード効果検証全社推進へのアクションとその後

Slide 6

Slide 6 text

チームとテストコードまずは1チームにテストコードを書く文化醸成チームとテストコード全社推進に向けたテストコード効果検証全社推進へのアクションとその後

Slide 7

Slide 7 text

チームとテストコード｜導入編

Slide 8

Slide 8 text

以前所属していた開発チームの話 ● 当時はテストコードを書く文化は無かった ● アプリケーション内に、僅かなテストコードが設置 ○ 動いているか分からない状態 ● 障害時に人的フロー対策体制を敷く。自動テストなど人的に頼らない仕組みで防御する対応を行えていない一つのチームにテストコード文化醸成

Slide 9

Slide 9 text

● チーム内にテストコードを書く習慣がない ○ 書く方法がわからない・テスト実行環境もない ● 書いて何が良くなるのかわからないなんとなく書かれているテストコードがあるチームにテストコード導入を検討したいが

Slide 10

Slide 10 text

● テストコードを書くための環境づくり ● 目標を決めたテストコード拡張の行動を始めるテストコードを書く体制を模索

Slide 11

Slide 11 text

テストコードを書くための環境づくり ┗ローカル環境 Dockerでテスト環境を用意 ● テスト用ローカルDB ● 1コマンドでDockerコンテナ上でのPHPUnitを実行 ● 他アプリケーションに依存させない設計

Slide 12

Slide 12 text

テストコードを書くための環境づくり ┗CI環境

Slide 13

Slide 13 text

テストコードを書くための環境づくり ┗CI環境レビュー時のテスト状態とカバレッジ値表示 Readmeにメインブランチのカバレッジ数値表示とカバレッジレポートを閲覧できる環境を用意

Slide 14

Slide 14 text

coverage: 2% まぁそんなもんか・・・そして当時のカバレッジは・・

Slide 15

Slide 15 text

● 書きやすいところから書いていこうというラフなルール感を設定 ● とにかくテストの量を増やす事を目的 👉 カバレッジ値をチームの目標におく初回は、「カバレッジ10%まで上げよう」を活動目標に掲げるここで辛さを感じる・・ではテストを書いていきましょう。目標設定編

Slide 16

Slide 16 text

どんなに頑張っても1%を上げるのに苦労 ┗テストを書いていない箇所が多すぎて、数メソッドテストを書いてもカバレッジに変化が起きない ┗テストコード書ける設計になっていない範囲を指定してカバレッジを計測する目標にすれば良かった既存のPJ（テスト無し）にテストを書く難しさ

Slide 17

Slide 17 text

テストになっていない・・チームとしても、テストコード実装の熱量に差がある 👉 書き方がわからないメンバーを救済できていない目標に追われてこんなテストコードが量産 public function test_selectRecords() { $response = $this->model->getAll(); $this->assertIsArray($response->records); }

Slide 18

Slide 18 text

● 新規実装部分にだけ、テストを設けていこう（既存機能にテストを設けるのは辛い） ● ペアプロを用いてテストコードの書き方をレクチャー。コードレビューで議論を多く行う事もここでやり方を変える

Slide 19

Slide 19 text

● カバレッジ数値が微妙に上がってくる ● 不具合発見時に、テストコードへ恒久的な対策を施せる事例が出る 👉 テスト自動化の効果を実感変化①

Slide 20

Slide 20 text

中途で新入社員が入社 ● テストコード状況への課題感に共感してくれる ● 2人（私・新入社員）で背中を見せる行動が増える。チームのテストコードへの意識変化が加速 ● テストコードのためのリファクタリング、チーム全体でテストコードを拡張する時間が増える変化②

Slide 21

Slide 21 text

テストコードへの角度が高いメンバー数が増えたことで ● 2人が行う実装はテストコードを混ぜたPRをガンガン出しまくる ● コードレビューでは、2人でテストコード実装面のノウハウを他メンバーにも布教やサポートを行う ● テストコード実装の意思1人に近かった状態から、あっという間にチームに蔓延する変化② | ここで良かったこと深掘り

Slide 22

Slide 22 text

チームとテストコード｜ぜんぶ書く編

Slide 23

Slide 23 text

アプリケーションリプレイスの話がやってくるこのタイミングでテストコードを全て網羅したアプリケーションを立ち上げようと決意「テストコードぜんぶ書く」を始める

Slide 24

Slide 24 text

テストコード全部書く個人的には、テストを全て設置したアプリケーションを作成するのは初めて初回は工数感が予定より遅れながらも、実装の仕方を掴んでいき、徐々に進捗が進む（慣れ）

Slide 25

Slide 25 text

そしてリプレイス完了。リリースへその時のカバレッジは 92%！！フロントのReactコンポーネントにもテストを都度実装やった〜！！！！

Slide 26

Slide 26 text

この時のCI環境アプリケーション複数のカバレッジ値を GitHub上でoctcovsを利用して管理 https://engineers.weddingpark.co.jp/github_actio ns_octocov/

Slide 27

Slide 27 text

開発中の話常時composer（PHPのパッケージ管理システム）の内容をアップデート。テストが通る安心感からスピード感高くマージができる 👉毎日最新アプリケーションに更新 ┗これはリリース後も継続

Slide 28

Slide 28 text

● 毎日composer アップデート ● PHP・フレームワークアップデートが簡単にできるようになる 👉この後詳細を話します ● 「人的に頼らない仕組みで防御」の形が一つ環境が築けたリリース後の変化

Slide 29

Slide 29 text

チームとテストコード｜まとめ

Slide 30

Slide 30 text

テストコードを書かなかったチームが、今では、テストコードの設置が当たり前になる 👉 現在私はチームから離れているが、チームとしてはテストコード拡張が完全に自己組織化チームとテストコード（まとめ）

Slide 31

Slide 31 text

全社推進に向けたテストコード効果検証全社水準へ変化チームとテストコード全社推進に向けたテストコード効果検証全社推進へのアクションとその後

Slide 32

Slide 32 text

全社推進に向けたテストコード効果検証｜社内施策の実施編

Slide 33

Slide 33 text

「TECH PASS」という社内施策がある。技術研究期間を与えられ、事業・組織に貢献を目指した開発期間を与えられる事に 👉 チームから全社へ、テストコードを導入する手法を模索するミッションを持った半年間、技術検証や開発のリソースを割ける事に https://www.wantedly.com/companies/weddingpark/post_articles/455459 社内施策の実施

Slide 34

Slide 34 text

なにをやろうか検討する　　　　　　　　　　　　　　　　　に着目 👉 テストコード整備による効果を示せる用になれば、導入への強い判断材料となるのではと考える全社テストコード推進のため

Slide 35

Slide 35 text

弊社にはQAテストというスプレッドシートにまとめたテスト項目（以降テスト仕様書）をブラウザテストしていくフローがある ※リリース前の必須フロー 👉このテスト仕様書が、テストコードでどれぐらいカバーできるか検証する。定量的にカバー率を出し、QAテスト削減へ恩恵があることを証明したいテストコード効果を立証してみよう

Slide 36

Slide 36 text

リリースしたリプレイスアプリケーションのテストコードが、どれぐらいテスト仕様書を網羅されているが調べるテスト仕様書とテストコードのカバー率

Slide 37

Slide 37 text

リプレイス案件リリース時にQAテストを行った時の、テスト仕様書項目数合計　6928 のテスト項目テスト仕様書項目数

Slide 38

Slide 38 text

テスト仕様書のテストコード網羅状態リリースフェーズテスト項目行数カバー済み一部カバー済み未カバー 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

Slide 39

Slide 39 text

リリースフェーズテスト項目行数カバー済み一部カバー済み未カバー 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 テスト仕様書のテストコード網羅状態テストコードでテストできている項目データ内容のテストはできているけれど、表示面のテストはできていないテストコードでテストできていない

Slide 40

Slide 40 text

リリースフェーズテスト項目行数カバー済み一部カバー済み未カバー 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ができる・〇〇の項目（文字列・ボタン・リンク・・）が表示されている・フロントでの出し分け表示テスト →テストコード元々無い →テストコード実装漏れ・範囲漏れ →テストコードが実装に苦戦した項目

Slide 41

Slide 41 text

リリースフェーズテスト項目行数カバー済み一部カバー済み未カバー 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 テスト仕様書のテストコード網羅状態テストコードで完全整備され、テスト仕様書項目を削減できる

Slide 42

Slide 42 text

リリースフェーズテスト項目行数カバー済み一部カバー済み未カバー 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 テスト仕様書のテストコード網羅状態一部テスト項目漏れがあるが、テストコードによるカバーができている。しかし同範囲をリリース時はテストデバッグが必要。

Slide 43

Slide 43 text

リリースフェーズテスト項目行数カバー済み一部カバー済み未カバー 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 テスト仕様書のテストコード網羅状態全くテストコードが整備されていない

Slide 44

Slide 44 text

テスト仕様書のテストコード網羅状態 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

Slide 45

Slide 45 text

テスト工数リリースフェーズテスト仕様書作成（人日）テスト工数（人日） 1 0.2 0.4 2 1.5 14 3・4 3 18 5 2 16 合計 6.7人日 48.4人日

Slide 46

Slide 46 text

テスト工数を省けるかリリースフェーズテスト仕様書作成（人日）テスト工数（人日） 1 0.2 0.4 2 1.5 14 3・4 3 18 5 2 16 6.7 ×　　　　　　　　　 48.4 ×　　　　　　　　　テストコード未カバー 20.57% テストコード未カバー 20.57%

Slide 47

Slide 47 text

テストコードで、テスト工数を省けるかリリースフェーズテスト仕様書作成（人日）テスト工数（人日） 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%

Slide 48

Slide 48 text

テストコード作成の工数がかかった事も忘れてはならない以下の方法で算出 ● テストコード含めた PRを洗い出し、初回commit時間〜最後のcommit時間をテストコード作成工数と捉える開発全体にかかった工数も割り出す ● リプレイス開発期間中の給料明細から、稼働時間などを算出テストコード作成工数計算

Slide 49

Slide 49 text

スクリプト実行テストコード作成工数計算

Slide 50

Slide 50 text

テストコード作成にかかった割合テストコード工数合算（人日）スクリプトから作成開発完了までの人日給料明細の稼働時間から作成全開発の中でテストコード作成の割合 **.2 ***.815 34.52%

Slide 51

Slide 51 text

テストコード作成にかかった割合テストコード工数合算（人日）スクリプトから作成開発完了までの人日給料明細の稼働時間から作成全開発の中でテストコード作成の割合 **.2 ***.815 34.52% 開発期間（9ヶ月）の中、単純計算で　3.1ヶ月をテストコード作成に充てていた

Slide 52

Slide 52 text

ローンチ後3ヶ月のリリース案件回数開発工数テスト工数 composer update 15 0 0 Github移行 1 7 0 フレームワークVer Up 1 6 2 リリース後の施策 1 4 1

Slide 53

Slide 53 text

ローンチ後3ヶ月のリリース案件回数開発工数テスト工数テストコードが無かった時のテスト工数 composer update 15 0 0 ？？？ Github移行 1 7 0 0 フレームワークVer Up 1 6 2 40 リリース後の施策 1 4 1 4

Slide 54

Slide 54 text

ローンチ後3ヶ月のリリース案件回数開発工数テスト工数テストコードが無かった時のテスト工数 composer update 15 0 0 ？？？ Github移行 1 7 0 0 フレームワークVer Up 1 6 2 40 リリース後の施策 1 4 1 4 計り知れない。テストコードが無かったら定期的なアップデートは出来ないかもしれない他のPJのアップデート時を参考

Slide 55

Slide 55 text

全社推進に向けたテストコード効果検証｜テストコードの効果定量化、結論編

Slide 56

Slide 56 text

工数面の恩恵 ● リプレイスアプリケーションでは、テストコード作成工数を差し引いても、リリース時のQAテスト工数やバージョンアップなどの保守運用工数の削減ができる計算だったテストコードの効果・恩恵テストコード作成工数テストコードで削減できたQAテスト工数テストコードで削減できたバージョンアップ工数効果 1ヶ月20人日 × 3.1ヶ月 = 62人日 -40人日 -38人日 -16人日 ※効果の数値は運用していく時間が増えるほど増えていく

Slide 57

Slide 57 text

リリース数の恩恵 ● 定期的なライブラリのバージョンアップと、工数をかけないバージョンアップ対応が可能リプレイスアプリケーションは、バージョンアップを工数をかけずに行えているテストコードの効果・恩恵

Slide 58

Slide 58 text

疑問

Slide 59

Slide 59 text

それは・・・・確かにそうかもですが、この検証の機会があった事に感謝しています定量的な効果を示す活動に時間を割けた事は、エンジニア人生の中でも貴重な調査期間この検証をする時間で、テスト書けたのでは？

Slide 60

Slide 60 text

全社推進に向けたテストコード効果検証｜まとめ

Slide 61

Slide 61 text

推進のための提案材料が整ってきた ● テストコードの運用面の有効さは証明できた ● テストコードを設置したいと思っているエンジニアも多い（ヒアリング） ● もちろんテストコードは、リリース物のクオリティアップにつながる 👉 じゃあ是非テストコード体制設置を！の話に持っていきたい全社推進に向けたテストコード効果検証（まとめ）

Slide 62

Slide 62 text

全社推進へのアクションとその後全社にテストコード取り組みへチームとテストコード全社推進に向けたテストコード効果検証全社推進へのアクションとその後

Slide 63

Slide 63 text

全社推進へのアクションとその後｜方針模索編

Slide 64

Slide 64 text

課題：エンジニアがテストを書く意思決定ができない ● スキルがない ○ テストコードを書けない・書き方が分からない ● 工数がない ○ テスト作成の工数が分からない。工数の取り方が分からない 👉 経験が無いのでエンジニア個人から、事業インパクトと有効性の説明を事業メンバーにできる人が少ない効果証明だけでは足らない

Slide 65

Slide 65 text

前提：テストコードを書かなくても、今までやってきたQAテストでバグを検知はできる QAテストでの不便な点や、テストコード有効さは分かっていても、テスト作成のスキル獲得へコストがネックになり、 QAテスト実行を選択してしまうという声もあった ※テストコードとQAテストは、互いにテストを設けやすい項目や特化したテスト範囲が違うので、良いところを使い分けていくのがベター QAテストについて

Slide 66

Slide 66 text

書かない事が必ずしも悪い事ではないテストコードを書く≠ 正義テストコードを書かない ≠ 悪例：事業フェーズや事業都合による、テストコードを書かないという意思決定自体は尊重されるべき ● 新規事業立ち上げ時など、高速サイクルでプロトタイピングを行いたいそもそもテストコードを書く事について

Slide 67

Slide 67 text

QAテストだけに頼る課題は無視できないじゃあ書かなくても良いわけでも無い

Slide 68

Slide 68 text

目標を変えた事業やプロダクトの状態を見て、適切な判断でテストコード導入を検討できる状態にしたい > 中長期な運用面効率化をしていきたい > 現状のテスト負荷増加の課題を軽減したい > リリースサイクルをさらに早めていきたい > 恒久的なバグ対策を仕込みたい上記のために戦術として、テストコードを設ける手法を選択できる組織を作る

Slide 69

Slide 69 text

課題：エンジニアから、事業インパクトと有効性の説明をできる人が少ないテストコードを戦術として採用するには、プレイヤーのスキルと経験が足らない適切な判断でテストコード導入検討できるか

Slide 70

Slide 70 text

戦略： ● テストコードを書ける ● 自分のPJでテストコードを書く経験をさせる 👉 テストコードを書ける前提で、テストコードの戦術を選択ができる状態にする上記に向けて、社内エンジニアがテストコードを書くために全面サポートするべきと考えた今やるべき事

Slide 71

Slide 71 text

テストコードの研修とコンサルティングを行う結論

Slide 72

Slide 72 text

他部署のエンジニアに対し、テストコードの研修とコンサルティングを行う ● PHPUnitテストの設け方の研修を行う ● 担当のPJコードから設けられるテストコードの提案とレクチャーを行う ● テストコードの入ったPRを全面的にレビューを行う方針

Slide 73

Slide 73 text

他部署のエンジニアに対し、テストコードの研修とコンサルティングを行う ● PHPUnitテストの設け方の研修を行う ● 担当のPJコードから設けられるテストコードの提案とレクチャーを行う ● テストコードの入ったPRを全面的にレビューを行う方針この取り組みから、上記の事例を作っていく取り組み

Slide 74

Slide 74 text

全社推進へのアクションとその後｜実行編

Slide 75

Slide 75 text

研修カリキュラムとフローを実行カリキュラムカテゴリ内容目的 PHPUnitテストの設け方の講義と基本ワーク・テストコードの効果とプロジェクトの実例・扱い方を紹介・PHPUnit基本講座とワーク基本的な扱い方を学び、実際に手を動かし PHPUnitを知る既存のPJコードから設けられるテストコードを提案とレクチャー・自プロジェクトからどんなテストコードを作れるか知る・自プロジェクトでPHPUnit環境を立ち上げる・自プロジェクトでテストコードを書く今後自身でテストコード拡張を作れるようにするテストコードの入ったPRを全面的にレビュー・継続的なテストコード作成とレビュー拡張したテストコードのレビュー体制を経験し、テストコードを書き続ける

Slide 76

Slide 76 text

● 研修実行するエンジニアチームを決め、研修実行 ● カリキュラム外にも、担当PJの環境作成の整備サポートに入った 👉基礎研修などを通しても、結局は担当PJでのテストコード実装とレビューが一番理解度が上がることを知るやったこと

Slide 77

Slide 77 text

良い点 ● テストコードを組み込むチームが増える ● スキルアップ観点でテストコード実装を目標に入れる人が出る ○ 個人の目標からチームミッションに昇華する事例も出てきた課題点 ● 定着にはまだ遠い。現状もテストコード実装が、「追加タスク」であり「優先度が低」の認識状態がある結果

Slide 78

Slide 78 text

まとめ

Slide 79

Slide 79 text

一番最初は1チームでテストコード実装文化醸成の事例ができたテストコード全面実装事例を出し、テストコードがある効果を実感できる状態も作ったまとめテストコードの有益性を立証するため、定量的な効果をまとめる効果証明だけでは組織は動かせず、エンジニア個人のスキル向上を狙っていく ┗事業やプロダクトの状態を見て、適切な判断でテストコード導入を検討できる状態を目指すテストコード研修実施。まだ定着率は低いが、自発的なテストスキル確立や方針にテスト設置を置くチームが出てくるチームとテストコード全社推進に向けたテストコード効果検証全社推進へのアクションとその後

Slide 80

Slide 80 text

🌱が見えてきた形だが、組織全体がテストコードを書いていくためにはまだまだ障壁がある「テストコード実装は追加工数ではない」当たり前にテストコード設置を模索できる組織を目指していく結論

Slide 81

Slide 81 text

会社として、「小さく・早く」をモットーにしている企業カルチャーの精神を取り組みに。個人に収めず、組織全体の力にしていく行動　「チームウエディングパークでいく。チームでしかいけないところがある。」　小さな人数でプロトタイピングを繰り返し、成果事例を作り、取り組みを拡大していく　取り組みに全員で協力し、同じ未来へ全員でいく結論チームとテストコード全社推進に向けたテストコード効果検証全社推進へのアクションとその後 https://speakerdeck.com/weddingpark/weddingpark-culture-book

Slide 82

Slide 82 text

ご清聴ありがとうございました