はじめに
この記事における 自動テスト導入支援 とは開発プロセスに自動テストを組み込むことで、なにかしらの長期的なプラスの効果を作り上げることを指します。
例. 毎リリースごとに実行していた回帰テストの自動化
LIFULLのSETチームはこの長期的に価値をもたらす支援とある特定のリリースの際にスポット的に行う自動テスト支援と２パターンの関わり方がありますが、今回は前者に関する内容になります。
この支援において学んだことを心得としてをまとめてます。少しニッチな内容ですがお付き合いください。
ちなみに下記が弊社のSETの支援体制です。
支援フェーズごとの心得
心得は以下のフェーズごとにあると考えています。
※ このフェーズは目安なので、対象に合わせて調整します
- 支援開始
- テスト計画・設計
- テスト実装
- 運用開始
- 支援終盤
支援開始
支援対象チームのテスト自動化についての状況を把握しましょう
例えば「自動化したいテストケースが設計済で自動化を進めたい」と「まずはテスト自動化について知りたい」だと支援内容がかなり違います。
自動化の準備がどのくらい進んでいるのか、自動テストの要求分析が済んでいるのか、そもそも自動テストに関する知識がどの程度あるのかなどを確認する必要があります。
支援対象チームメンバーはどのくらい工数をさけるのかを確認しましょう
何人が、週に何時間くらい使えるのかを確認しましょう。
コミュニケーションのとり方を決めましょう
共通のチャットツールがあればチャンネルをつくったり、定期的なMTGを行うのかを決めましょう。
私の経験上、初期段階では最低週１回は定期的なミーティングを行うべきだと思います。
顔合わせ機会を増やすことと進捗の同期が重要です。
相手の心情やスキルの把握ができ、心理的安全性の確保（話しやすい関係の構築）にも繋がります。
かなり大事です。
アジェンダには次回定例までに何をやるかを決めて終わりにするのも有効です。
テスト自動化はサブプロジェクトになることが多いため明確なアクションを握っておくことも大事です。
テスト計画・設計
テスト計画書をつくりましょう
自動テストにおいてもどのようなテストにするかをテスト計画に落とすのは大事です。
テストアプローチが明確になります。
テスト自動化に関するコストの算出
構築にどのくらいかかって、運用にどのくらいのコストがかかる見込みなのかを構築前に出してあげると納得感をもって進むことができます。
詳しい話はこちらをご覧ください。
自動テストの効果測定に使われるEMTEとは？ - LIFULL Creators Blog
テスト対象の優先度を決めましょう
私達の支援は自動システムテストが多いです。
その場合テスト対象を絞って導入する必要があります。
どのような基準で絞っていくかを支援対象チームと決めていく必要があります。
例えば「壊れたらビジネスにクリティカルな被害が出る機能を優先する」や「過去に障害が起きた機能を優先する」などがあります。
テスト実装
自動テストに関する学習を手伝いましょう
長期的な価値を生み出す支援は最終的には支援対象チームが自走している状態にならなければなりません。
自動テストの基礎知識から、テストコードの実装方法、テスト結果の確認手順などを教えていきます。
ハンズオン形式で手を動かすようにすると自動化楽しいという気持ちを植え付けることができて、その後実装が進めやすくなります。
テストコード実装をモブ・ペアプロで行いましょう
一つ前の学習に関連する項目です。
実装しておいてくださいといったところでなかなか前に進めないことが多かったです。特にテストコードの実装については走り始めはSETがブースターとなって学習を促す必要があります。
基本的には開発チームメンバーがドライバーとなる形が良いでしょう。
テスト対象システムのデプロイまでのフローを確認しておきましょう
自動テストは可能な限り自動で実行開始するべきだと思います。
そのためには開発スタートしてからどのようなフローでテスト対象環境までデプロイされるかを把握する必要があります。
知ることで適切な提案が可能になります。
テストデータの整備を可能な限り自動化しましょう
テストコードの実装に注力するとテストデータを整備することを忘れがちです。
自動でデータを更新するための仕組みを検討することをおすすめします。
運用開始
少ないテストケース数の段階で運用を始めましょう
達成感によりテスト自動化のモチベーションを高めます。
また、早めの運用で運用フローの検討不足なども早期発見できます。
また繰り返し実行した分だけ価値が生まれるので早期に運用開始するべきです。
短い期間で運用に載せてスクラムのように改善・テスト追加を繰り返していくのが良いと思います。
支援終盤
自走できる状態を定義してそこまで引っ張りましょう
運用がSETの支援なしに回っている状態やテストコードのメンテナンスやテストケースの新規追加が支援対象チームだけでできている状態など自走できる状態を定義し、できていない箇所の学習や経験ができるように手伝いましょう。
はじめのほうでモブプロをした人から別のメンバーに指導してもらうのもいい手です。
終わりに
心得を簡単にですがまとめてみました。
まとめてみてこの心得はSETによる支援だけでなく開発チームが自発的にテスト自動化に取り組む際にも役立つことがあると思いました。
うまくまとめられず記載できていないものもまだまだありますが、それはまたの機会にでも共有できればと思います。