優先順位別！ テスト自動化の計画づくり
おおまかな戦略ができあがりました。次にもうちょっと具体的な計画づくりを行っていきます。
もし対象のシステムやサービスが大きなものであれば、どこから手を付けるか悩ましいものです。なぜなら、機能がたくさんあり。どれも重要に見えてくるからです。テストを増やすことはためらいなくできるかもしれませんが、スコープを絞ったりして減らすとなると勇気が必要です。
計画は優先順位によって変わってきます。ここでは、いくつかの事例として「目的ドリブンでの計画くづくり」「データドリブンでの計画づくり」「価値ドリブンでの計画づくり」「ポイント制の計画づくり」を紹介します。
目的ドリブンの計画づくり
目的ドリブンで計画を立てるなら、以下のような計画が例として考えられます。
- 重要機能の動作確認として、スモークテストを実装する
- 次に、スモークテストより広い範囲のリグレッションテストを実装する
- リグレッションのパターンを減らすためにAPIレベルのテストを実装する
ここから静的解析を導入する、パフォーマンステストを自動化する……というように、テストの目的や種類をベースに、カバレッジを上げていく計画も可能です。
データドリブンの計画づくり
個人的におすすめしたい計画づくりです。なぜなら、テストの海は膨大ですので、効率よく泳いでいきたいからです。データドリブンの計画づくりでは、データを使って効率性を高めます。例えば、ECサイトの場合、多くのユーザーが、
- 商品を検索して
- 商品を確認して
- かごに入れて
- 購入する
という動線を歩いていきます。もし、80%のユーザーがこの動きをするとしたら、すぐにでもこのシナリオを自動テストにすべきでしょう。そして、このシナリオのテスト自動化が完成すれば、「ユーザーの動き」という視点で言うならば、カバレッジ80％をいきなり達成できるとも言えます（少々乱暴かもしれませんが）。
価値ドリブンの計画づくり
ECサイトだと、かご（カート）に入れた商品を購入するプロセスが、非常に重要なクリティカルパスになります。このクリティカルパスでのトラブルを防ぐのであれば
- 支払いパターンを網羅
- 送付先住所のパターン
- ポイント利用のパターン
といった網羅性をテスト自動化で高めていくのも手です。
価値ドリブンの計画づくりではページや機能の価値を中心に優先順位を付けていきます。Google Analyticsが使えるのであれば、どのページに価値があるかを調べ、価値の高いページから実装を進められます。
リスクとコストをポイント付けする計画づくり
筆者が翻訳に関わった『リーン開発の現場』（オーム社）でも紹介されている方法です。上記の例では、とある金融系アプリのテストケースを考えています。
リスクが高く、手動コストが高くつき、自動化コストが低い「講座の凍結」はすぐにでも自動化するテストでしょう。
一方で、「デザイン変更」は、リスクも低く、手動コストも低く、自動化コストがとても高くついているため、自動化するには十分な検討が必要です。
優先順位付けするポイントが複数あるなら、上記のようにそれぞれをポイント付けして考えるのも手です。
ここでは、いくつかの計画づくりを紹介させていただきましたが、他にもコードの複雑度や更新頻度を軸に、自動化の計画を考える方法もあります。
リグレッションテストのスコープ
どんな戦略をとるにしても、テストの特性上、リグレッションテストの自動化から入るのが一番はじめやすいと思います。
リグレッションテストの範囲は広大ですが、考え方によっては狭くもなります。前述のテストと品質の現状分析でも述べたように、自分たちの求めるリグレッションテストをきちんと定義し、ゴール設定しなければなりません。
例えば、下記のようにリグレッションテストを松竹梅の3つに分けてみましょう。
- 梅レベル： 最低限の機能正常系のみ網羅
- 竹レベル： 全機能の正常系を網羅
- 松レベル： 全機能網羅（正常系・異常系）
竹レベル以上はかなり実装が大変そうです。人よりは多くの組織の品質課題を見てきたつもりですが、竹や松を実現し続けている企業を、まだこの目で見たことがありません。
テスト自動化に現実的に取り組むのであれば、竹や松のレベルを調整する必要があります。
書籍『ソフトウェア品質を高める開発者テスト アジャイル時代の実践的・効率的なテストのやり方』（翔泳社）にはこう書かれています。
ほとんどのバグはソースコードファイルの10％〜20％から出る
『ソフトウェア品質を高める開発者テスト アジャイル時代の実践的・効率的なテストのやり方』より
筆者の感覚でしかありませんが、全機能の20％〜30％を網羅できれば、リグレッションテストとして十分に機能するように思います。つまり、重要な機能を20％〜30％に絞れるなら、松竹梅の定義は以下のように変えられそうです。
- 梅レベル： 全機能の5％を網羅
- 竹レベル： 全機能の15％を網羅
- 松レベル： 全機能の30％を網羅
より現実的な数字になってきたのではないでしょうか？ 異常系まで考慮すると数が膨大になるため、正常系だけに絞ってもいいかもしれません。
5％（ここでは5％にしていますが10％など好きな数字できざめばいいと思います）で十分な効果があるなら竹レベルを目指す必要はありません。30％の実装でも効果が得られないサービスやシステムであれば、さらにカバレッジを上げるかどうかの判断をします。
次に、どのようにリグレッションテストの実装を進めるかを考えていきましょう。理想はテストピラミッドに従って、単体テストを多く、UIテストを少なく作っていく必要があります。
しかし、単体テストの実装が少ない現場では、なかなか単体テストのカバレッジを高めるのは難しいはずです。そういう場合は、一時的にUIテストでシステムやサービスを包み込み、壊れてもすぐ気がつけるようにしてから、単体テストやAPIテストのカバレッジを高めていく作戦もあります。
その場合も、リグレッションテストをレベル分けしておき、梅から徐々に竹に近づけていく方法が取れます。
がんばればリグレッションテストのカバレッジ100％は可能です。しかし、イテレーション／スプリントのたびに機能がリリースされる開発プロセスだと、常にカバレッジ100％を目指すのはとても難しいはずです。また、カバレッジはある一定の高さ（感覚として70％〜80％ぐらい）まで上がると、そこから極端に上げるのが難しくなります。
カバレッジは目安でしかありません。カバレッジが目的にならないように、自分たちにあったカバレッジのゴールをしっかり見据えてテスト自動化を進めていきましょう。
コラム： テストピラミッドは現在も有効？
『アジャイルな計画と見積もりづくり』（マイナビ出版）の著者で有名なマイク・コーン氏は。自著『Succeeding with Agile』でテストピラミッドを紹介しました。フィードバックの速いUnit test（単体テスト）を多く作り、次にIntegrationレベル（API、Integration）、その次にUIレベル（Web E2E)のテストを積み上げていく考え方です。
「単体テストは重要！」というのはどの開発者も賛成する内容だとは思いますが、現実問題として単体テストが十分な現場がどれぐらいあるのでしょうか。
そして、時代とともにUIテストは高速化が進み、クラウドの恩恵で並列実行も可能になりました。
まだまだ単体テストの重要性は変わらないとは思いますが、もし、E2Eテストがより高速化実行できるようになり、テスト作成コストが下がってくるとすれば、テストピラミッドも再考が必要になってくるかもしれません。
まとめ
今回は、テストと品質の現状分析を行い、誰が何をテストすべきかを整理しました。また、テスト自動化の戦略を考えるために、計画づくりのさまざまな方法を解説しました。そして最後に、自動化の肝になるリグレッションテストのスコープを検討しました。
次回はいよいよモダンなテスト自動化の代名詞とも言える「ノーコードとAIの登場」について解説します。
