テスト自動化やQA業務に従事されているみなさんは、現状の開発組織全体、あるいは自チームの責任範囲であるプロダクトのテストの総数と分布を正確に把握していますか？
私は残念ながら把握しておりません。
そんな状態なので、もちろんテストピラミッドについてもどのような形をしているのか、責任範囲や開発・検証フローも把握していません。
今回はこんな状態のスタートラインから、どのようにプロダクト信頼性の維持とバランスついてプロセスを整理できるか考えてみました。なお、今回の話はE2Eテストをメインとしています。アプローチの手法をそのまま真似するのではなく、自社やご自身の置かれた状況に応じて問題点や施策の洗い出しを変え、適用してみてください。
テストピラミッドとテストの信頼性の話
テストピラミッドとテストの信頼性の定義と課題感については、t_wadaさんの以下の記事と、SpeakerDeckを参考にしています。
というのも、私は 「テスト自動化はコスト削減を目的の1つとしている」 と長年考えていたので、特にリグレッションテスト（開発完了済みの既存機能や過去のテストケースを、新機能の実装や改修時に再度実行して問題ないかを確認するテスト）においては、 手動テストにかかる工数を数日→数時間までに削減できる = コスト削減できる と考えていました。
しかしながら、自動テストが増えるたびに時々失敗するflakyテストの増加や、テストのメンテコストなど負債も同時に増えてしまうことを最近実感しています。
このことからも言えるのですが、自動化のやり過ぎも、コスト削減が目的の施策も本質的な問題解決にはならないということです。
ちなみに過去以下のような記事を書いているのですが現実は甘くありませんでした……。
問題点
改めまして今回の状況における問題点について整理したいと思います。
- テストピラミッドを把握できていない
- 責任範囲やプロダクト開発のプロセスを把握できていない
- テスト自動化の目的が「コスト削減」になっている
結論としては、 全体を俯瞰できていないため場当たり的なテスト自動化によるコスト削減が目的となってしまっていて、その価値や信頼性、正当性について誰も明確に認知・判断できないかもというのが問題 という感じですね。
解決策
問題点についての解決策を以下のプロセスに沿って考えていきます。
- 全体のテストを把握する
- 現状評価
- テスト管理と責任範囲の明確化
- 目的の再設定
- チームでの共有とフィードバック
全体のテストを把握するため、テストを一元管理する
以下はテスト自動化があまり進んでいない、またはE2Eがめちゃくちゃ多いという、あるある状態を示す図です。（t_wadaさんの資料から引用）
今回のケースもこれに該当します。
それではテストピラミッドの全体を把握するために、一番数が多いであろう手動テストの内容について把握しましょう。
大体の手動テストは組織お手製のExcelかGoogleスプレッドシートが存在します。
そして、担当者や機能が増えるたびになぜか複製され、「XXテスト_最新（１）」や「XXテスト_20240717」「XXテスト_マージ作業中」などという謎のファイルが散見されるようになります。
また、テスト進捗についてはNotionやJiraなどのチケット、ガントチャートによる消化件数と残件数、もしくはExcelやGoogleスプレッドシートの関数を駆使して作られた温かいバーンダウンチャートがメインとなっているのではないでしょうか。
プロジェクトマネージャーやプロダクトマネージャー相手にはこれだけでも問題ないかもしれませんが、システムを開発しているエンジニアが知りたいのは、きっと どの機能がどういう理由でどんな不具合を出したか だと思うわけです。
そういうわけで、チケット管理システムのバグチケットには、以下のような要素が含まれるでしょう。
| 項目 | 種別 | 選択肢/形式 | 目的 |
|---|---|---|---|
| 1. タイトル | テキスト | - | バグの概要を簡潔に説明する |
| 2. 説明 | 長文テキスト | - | バグの詳細、再現手順、期待される動作を記述する |
| 3. 優先度 | プルダウン | 緊急、高、中、低 | バグの修正優先順位を決定する |
| 4. 深刻度 | プルダウン | クリティカル、重大、中程度、軽微 | バグがシステムに与える影響の大きさを示す |
| 5. ステータス | プルダウン | 新規、確認中、修正中、修正済み、クローズ | バグの現在の状態を追跡する |
| 6. 発見日 | 日付 | - | バグが報告された日を記録する |
| 7. 修正期限 | 日付 | - | バグの修正完了予定日を設定する |
| 8. 影響範囲 | チェックボックス（複数選択可） | UI、バックエンド、DB、API、その他 | バグが影響を与える可能性のあるシステム領域を特定する |
| 9. 再現性 | プルダウン | 常時、時々、稀に、不明 | バグの発生頻度を示し、デバッグの難易度を予測する |
| 10. 添付ファイル | ファイルアップロード | - | スクリーンショットやログファイルなど、バグの理解や解決に役立つ資料を添付する |
| 11. 関連チケット | リンク | 他のチケットID | 関連するバグや機能要求とのつながりを示す |
| 12. コメント | 長文テキスト（追記可能） | - | バグに関する追加情報や進捗状況を共有する |
| 13. 不具合種別 | プルダウン | - | 機能不具合、UI、互換性、ネットワーク、仕様・ドキュメント不備など |
| 14. 原因 | 長文テキスト（追記可能） | - | バグの原因を記述する |
| 15. 修正PR | テキスト | - | 修正対応したPRをリンクさせる |
で、QAの方はバグが起きるたびにこれを書くわけですが、手元にあるテスト管理表からの写経をすることになっているのではないでしょうか。
あるいは、手元のテストケース管理表にチケットのリンクを貼って別管理するためのシートを作っているのではないでしょうか。
これでは単純に作業量が2倍になっただけです。
更に、チケットの量やQA作業者が多くなってくると別の管理表が作られることとなり、テストをするために3〜4つ以上のExcel、Googleスプレッドシートを開いてそれぞれの記述内容が同期しているかどうかを確認しながらテスト作業をすることになるでしょう。
QAもNotionやJiraだけでテストケースを管理できれば何ら問題はないのですが、1つのツールでは厳しいのが現状です。
そこで使えそうなのが TastRail です。
TestRailによるテストの一元管理
TestRailについての説明は割愛します。参考記事を参照してください。
TestRailは各プロジェクトやフェーズによってテスト計画を作れます。それに従ってどのテストケースを実行するかを管理できます。
テストケースの総数は「テスト スイートとケース」タブを選ぶと右側に表示されます。
写経回避のためには、最悪各テスト実施後のコメントにリンクURLを貼れば問題ないと思います。
TestRailには豊富なチケット管理ツールとの連携が可能のようで、下図のようにAdminから設定すればTestRail→チケット管理へ起票という流れは自動的に作れるようです。URLリンクである程度運用が安定化してきたら連携先を増やして自動化したり効率化したりやっていきましょう。
進捗報告用のバーンダウンチャートや消化率グラフもTestRailが勝手に生成してくれます。便利ですねぇ。
バグ（欠陥）についてもまとめて出してくれます。
ちなみに 「テスト完了報告は終わっているが、バグは残っている」 パターンも発生します。これは例えば発生確率が低い、事情により修正する時間がないなどでバグのままプロダクトリリースされるときがそうです。
そういう場合でもTestRailだとテストケース個別の履歴を見ることで、「このテストは過去に不具合のまま放置されてる」というのが分かるようになっています。これも地味に便利。flakyテストかどうかを判別することもできそうですね。
以上、TestRailを使うことで手動テストの総件数と、テストケース別の状況把握ができそうです。
注意点としては、 なるべくお互い依存関係のないテストスイートとテストケースを工夫して作らなければならない というところでしょう。
テストケースを見直し、評価する
テストケースの見直し作業
次の作業としては、手動テストからE2Eに移す、あるいはE2Eテストからインテグレーション、ユニットテストに移すテストを検討する作業を想定します。
上述のとおりTestRailで整理されたテストスイート、ケースがベースとなります。
エンジニア側ではおそらくコードテストを書いていると思うので、それらをどのような検証をしているかわかるレポートファイルとしてエクスポートしてもらいます。
QA担当者はエンジニアからもらったファイルと、TestRailのテストケースを突合し、可能な限り同じテストを減らしていくようにします。
この作業自体はTestRailを使わずとも実現可能なのですが、削除した意図や変更した内容について簡単に履歴を残せるのでその点でTestRailの利便性が高いです。
ExcelやGoogleスプレッドシートを使う場合は、テストケース最初の1シート目に「変更履歴」シートを作って、そこで変更管理をするか、あるいは直接セルを塗りつぶしたりコメントつけたりしてわかりやすくするかという方法もあります。
テストを管理するための責任範囲を明確化
テストケースの管理は基本的にQAメンバーが責任を持って担当することとした場合、全体のテストケースの整合性はQAが担保します。
新しい機能がリリースされるとテストケースが追加されるわけですが、これらのテストケースがリグレッションテストや既存機能のテストケースの追加・修正に影響することも多々あります。
このあたりが一番大変で面倒ですが、少なくともテストケースやテストスイート単位でのエクスポートが可能なTestRailであれば、ExcelやGoogleスプレッドシートのセルコピペ作業よりはだいぶ楽に作業できるはずです。
なお、他社の事例だとTestRailの管理もすべてエンジニアがやっているパターンもあるようです。（E2Eを含めたリグレッションテストの管理をエンジニアがやっている）
テストケースの整理ができたら、QAとエンジニアが協力して全体のテスト計画を正しいテストピラミッドになるように毎回のリリースの定例やアジャイル/スクラムにおけるスプリントにて戦略を立てていく、という感じになります。
確実に他チームを巻き込むことが大事です。
主目的をコストダウンから品質向上へ
指標の作成
テスト自動化の目的がコスト削減の場合、E2Eテストの肥大化とともにメンテナンスコストも増えてしまい、目的達成できなくなることは前述した通りです。
そのため、コスト削減ではなく、それとは別の新しい目的を掲げ、それを評価するための指標を作成する必要があります。
目標は色々あると思うのですが、テストピラミッドを構築するということ=品質の向上と考える場合、要は手動テストやE2Eテストを削減してもプロダクトの品質が変わらないことを測定できればよいのではないかと考えます。
例えばこんな感じ。
| 指標 | 説明 | 目標 |
|---|---|---|
| テストカバレッジ | ソースコード全体に対するテストカバレッジ率（行カバレッジ、条件カバレッジなど） | 80%以上の行カバレッジを目指す |
| バグ発生率 | リリース後に報告されるバグの数 | 各リリースごとにバグ発生率を移行以前と同程度に抑える |
| テストスピード | テストスイート全体の実行時間 | 全テストの実行時間を短縮させる |
| flakyテスト率 | flakyテストの割合 | flakyテスト率を低下させる |
| リリース頻度と安定性 | 安定したリリースの頻度 | 毎月の安定したリリースを維持する |
定量的な評価をあまり入れていないのは意図しています。というのも、多分みなさんの組織でもこれらすべての現在の定量的数値を把握している組織はあまりないはずです。なのでまずは定性的に指標を作ることを目的としています。
何度か検証を進めると数値が出てくるので、それをベースに再度指標を見直すと良いでしょう。
資料の作成
次は資料を作ります。これらの資料は「何をユニットテストと捉えるか」「E2Eでカバーする範囲とはなにか」などを定義したもので、新しいメンバーやチーム編成があった場合でも共通認識を保つために必要となります。
QAをやっていたらもともとあるであろうテスト完了レポート（テスト完了報告書）を除いて、以下のような資料があれば良いかもしれません。
| 資料名 | 概要 | 内容 |
|---|---|---|
| テスト戦略ドキュメント | テストの全体像を説明し、各テストレベルの範囲と目的を明示 | ユニットテストの範囲、統合テストの範囲、E2Eテストの範囲 |
| テストカバレッジレポート | 現在のテストカバレッジを示し、カバレッジ率と成否を可視化 | 各テストレベルのカバレッジ率、未カバー部分のリストと優先順位 |
| 品質指標ダッシュボード | 設定した指標の進捗をリアルタイムで確認できるダッシュボード（TestRailで代用可能） | テストカバレッジ率、バグ発生率、テストスピードなどをグラフで可視化 |
| flakyテスト管理シート | flakyテストの発生状況を管理し、対応状況を追跡する | flakyテストのリストとその原因分析、修正対応状況と優先順位。失敗するたびに当該テストを追記する形式でもOK |
これらを活用して各テストピラミッドの各層でのテスト・カバレッジの増減や、指標の評価を行っていきます。
チームでの共有とフィードバックループ
最後に、ここまで定義したり作成したりした内容を、リリース、スプリント、あるいは定例などでチームで共有・フィードバックする仕組みづくりを行います。
ここで問題点にも挙げている 開発プロセス を全体的に把握します。
そのためには普段は参加していないミーティングに参加させてもらったり、あるいは参加してもらったりする場面もあると思います。他部署や他組織・他チームに協力を依頼する際はぜひボス（上司）を活用しましょう。
また、整理にあたってはプロセスマッピングという手法を使うとよいかもしれません。
あとは整理したプロセスマッピングに従って、テスト戦略について評価・共有し、フィードバックするプロセスを組み込んでいく感じになります。
まとめ
ここで挙げたプロセスではテストの整理にTestRailをベースにしていますが、現在管理しているツールが別であるのであればそれを利用することでも問題ないです。
大切なのは「何を使うか」ではなく「なぜやるか」と「どうするか」です。
冒頭で述べた通り、アプローチの手法をそのまま真似するのではなく、現状においての最適解をチームメンバーと共に見極めていきましょう！
私もここまでまとめた内容を実践していきますので、結果が報告できることをご期待ください……！