「当たり前にテストコードが書かれている環境にする」ために取り組んでいること
こんにちは、atama plusでスクラムマスターをしている松村です。
今回は、開発チームにて取り組んでいる「ソフトウェアテストの浸透」について紹介したいと思います。
そもそもどんな状況か
atama plusのコードベースは、「テストコードが十分に書かれている」という状態ではありません。もちろん全く書かれていないわけではなく、プロダクションコードとともにテストコードを書いているエンジニアも多いです。
しかし、前職等でテストコードを書いていたメンバーや入ったばかりのメンバーから「テストコードが十分でない」、「コード修正やリファクタリングに不安がある」という声をよく聞きました。また、QA（品質保証）メンバーからも「一度検知したバグを再度検出することがある」といった声を聞くこともありました。
このように開発活動を行う上での課題が表出していることや、中長期の視点ではプロダクトの開発スピードに影響が出るという懸念もあり、開発チームにてソフトウェアテストを浸透させるための活動を進めることにしました。
目指すところ
活動の指針としては、エンジニア目線での「テストコードが十分に書かれていない」「書くのが当然、という状況ではない」「プロダクションコードの修正に不安感がある」という状況が定性的に改善されることを目標としました。
定量的な指標で評価することも検討しましたが、適切なメトリクスを設定するのが難しく、例えば、カバレッジやテストケース数に関して設定する場合、数値目標に対する義務感が強くなり、カバレッジ向上だけを目的とした効果的でないテストが書かれる可能性が出てくると考え、参考程度の指標としました。
活動の方針
活動を推進するチーム
過去のnoteでも紹介しているのですが、atama plusはLeSSベースの体制で開発を行っていて、atama＋のアプリケーションを開発するチームは6チーム存在します。
今回はそのうち、Oyakataというチームと一緒にこの活動を推進することにしました。
選定の理由としては、前職にてテストが十分に書かれている環境を自ら作ってきたエンジニアが所属しているので、そのメンバーを中心に進めていくのが筋が良さそうというものです。
浸透させるための方策
活動の進め方としては、まず1チームで小さく活動を始め、テストが書けていない要因の調査や改善を行い、チーム内で成熟したらそのプラクティスを他チームにも展開する計画としました。
活動を行う時間の捻出
スプリント外で活動を行うと、残業のような形となりチーム活動が不健全になると想定し、スプリント内で時間を取れるように調整しました。
エンジニアからPOに技術負債の返済に初期コストがかかることとソフトウェアテストを浸透させるメリットを共有し、バックログにこの活動のPBIを入れることとしました。
スプリント計画時に他のPBIとの優先度の兼ね合いを見ながら活動量は調整していますが、平均すると1、2割程度をこの活動に充てています。
実際に取り組んだこと
ここでは実際に取り組んだ施策について、いくつか紹介したいと思います。
課題は大小様々なものが思い当たりましたが、中でもエンジニア目線で「明らかに阻害要因となっているもの」と「少ないコストで改善効果を見込めるもの」に対して優先的に取り組むことにしました。
施策1.肥大化したテストデータの整理
課題の一つとして、テスト実行時に使用するテスト用のデータセットが肥大化していることにより、テストコードの実行速度が遅いというものがありました。そのためTDDのように頻度高くテストを実行しづらく、テストを書くモチベーションを下げる要因にもなっていました。
そこで、肥大化したテストデータを分離し、テスト毎に必要なテストデータを読めるように整備を行いました。
結果として2分以上かかっていたテスト実行が数秒程度にまで高速化されました。また整備したことを他チームに周知した際には「困っていたのでありたがい！」といった声が上がり、客観的にも効果を実感できました。
施策2.効果的なテストの書き方ワークショップの実施
テストコードを書くことにも技術力が必要ですが、社内であまりテストを書く環境が整っていないこともあり個々人の前職までの経験によって大きく差がありました。「書き方がよくわからない」といった声もあったので、普段からテストを書いているメンバーが効果的なテストの書き方をチーム内にワークショップ形式で共有しました。
良いテストコードの例を取り上げながら、例えば「責務によってクラスや関数を分け、ここのパーツに対してのテストを書く」「APIをクライアント・ブラウザから使ったときの振る舞いに対してもテストを書く」といったように テストコードを書く際に守るべき基本的な考え方を揃えることを行いました。
直接的な効果として、テストコードに関する考え方を揃えることができたのも良かったのですが、それ以上にこのワークショップを機に、コードレビュー時に毎回効果的な書き方をFBし議論するという流れができ、スプリントごとにテストコードの技量が上がるサイクルができたのが最も大きいと感じています。
施策3.参考にできるテストコードを追加する
プロダクションコードを書く際に類似の処理があるところは共通化したり、参考にしたりするように、テストコードもまずは参考にできるコードがないと、なかなか書き始めづらいという仮説を立てました。
そこで、テストコードが書かれていない箇所にリファレンスとなるテストコードを追加することにしました。これもテストコードを書くことに慣れているエンジニアが率先してPBIを取り、実装していきました。
まだ整備したばかりですが、今後関連する箇所の処理を書く際のテストコード実装時の負担を軽減する環境ができました。
施策4.テストコードを書く際のガイドラインを作成する
初期の仮説では、PBIの完了を判定する基準であるDefinition of Done（完了の定義）やコードレビューのルールに「テストコードを書くこと」という内容が含まれないため、テストを書く動機や力学が生まれないことが問題なのではないかと考えていました。
そこでどのようなルールを策定したら良いか、チーム内で検討を進めようとしました。しかし、上記施策1~3に取り組む中で、すでに少しずつ効果を実感していた段階であったこと、またルールで縛ると義務感だけでテストコードを書くことになりそうという懸念から、ルール策定は一旦不要という結論となり、ルールを策定するという施策は取り下げました。
ただし、どのあたりに書けば良いかの指針がある方がチームメンバーの認識を揃えやすいという話となり、これもテストに強いメンバーが以下のようなガイドラインを作成しました。
現在の状況
現在のOyakataチームでは、かなりテストコードが書かれるようになり、プルリクエストにテストコードが含まれるのが当たり前の状況になりました。次の段階として、テストコードを書く技術を上げることに力を入れています。
実際にチーム内で「テストコードのおかげで、安心してリファクタできた」という声やQAから「バグが少なくなった」という声が上がっていました。
今後の動き
今後、別のチームにも今回の取り組みを展開していく予定です。ただ、チームやメンバーによって感じている課題感が異なる可能性もありますし、Oyakataチームはコードレビュー等で技術力の引上げを行いやすかったですが、テストコードを書くことに関するエキスパートがいないチームでどのようにテストの書き方に習熟していくかもポイントになるかと考えています。
そのため、上記で当たっていた施策が適用できず検討し直すことや棄却した仮説に再度取り組むことがあるかもしれません。
ただ、1チームでうまくできたという実績を基に、他チームへの浸透も積極的に行っていきたいと考えています。
またこの活動が進んだ際にはその状況をnoteに書きたいと思っています。
atama plus株式会社では一緒に働く仲間を募集しています！