本連載では、スピードと品質を両立するためのアジャイルテスティングにおける重要なキーワードである「テストの自動化」について、WebブラウザやAPIレベルのエンドツーエンドテスト（E2Eテスト、この連載でのテスト自動化は主にE2Eテストの自動化を指しています）が求められる時代背景から、戦略や戦術、組織づくり、ノーコード・SaaS型のAIを活用したテスト自動化サービスの進化と具体的な実装、ベストプラクティスを解説します。前回は、アジャイル開発やDevOpsが当たり前になった時代において求められるテストや品質について紹介しました。今回は、テスト自動化の戦略について考えていきます。
| 目次 |
|---|
はじめに
前回は、アジャイル開発やDevOpsが求められる時代において、「アジャイルテスティング」の必要性について解説しました。今回は、テスト自動化をうまくすすめるための戦略を考えていきます。
テストと品質の現状分析
筆者は、mablの仕事とは別に、QA組織の立ち上げや、アジャイルテスティング実現の支援を行っています。そうした仕事の事前準備として、その開発組織におけるテストと品質の現状分析を実施しています。
なぜこのような作業が必要になるかというと、企業によっては部署ごとにサイロ化が進んでおり、それぞれが何をやっているかわからず、似たようなテストを複数の開発チーム／メンバーで行ってしまうケースが多いからです。
これだと非効率なのはもちろん、間に落ちたボールが拾えません。ボールが落ちた結果、責任のなすり合いに発展するのは悲しいものです。
現状分析は、関係者の視点を揃えるサポートにもなります。ざっくりとでもいいので分析ができると、それが地図となり、改善の道標になっていきます。
現状分析のポイントは以下の通りです。
- どんなテストがあって
- それぞれが何を守っていて
- 何ができていて、何ができていないか
これらが整理できれば、理想とのギャップを認識し、そのギャップをなくすためにどうすべきか？ と考え方が未来志向になります。できない理由を探すのではなく、できる方法を考えるべきです。
DevOpsのプロセスに合わせた分析もできます。例えば上記の図の場合、横軸にDevOpsのプロセスを置き、縦軸にプロダクトオーナー、フロントエンジニアといった役割を並べて、それぞれのプロセスと役割から見た問題や課題を洗い出しています。
複数の役割で似たような問題が出ている場合、改善するとその効果は大きくなります。
誰が何をテストすべきか？
誰が何をテストすべきかは、開発組織によって考え方が異なるはずです。
例えば、エンジニアリングで品質を改善する力がある組織であれば、ほとんどのテストが自動化され、マニュアルテストへの依存も少ないはずです。スタートアップであればQA体制が組めないケースも多く、開発者があらゆる機能をテストする体制になりがちでしょう。また大規模な開発組織であれば、職能横断型チーム（企画、開発やリリース業務が完結するチームを指しています）を作るより、開発部、QA部……と役割で組織を分け、それぞれで作業を行ったほうが効率が良いかもしれません。
本連載はアジャイル開発・DevOps時代のテストや品質のあり方を取り上げているため、アジャイル開発を採用している開発組織の役割分担を検討します。
なお、テストにはさまざまな種類があるため、この連載ではシンプルに「単体テスト」、「機能テスト」……と表現しています。また、テスト対象によっては扱うテストも異なるため、ここではWebアプリケーションをテスト対象としています。もし、ご自身の現場と異なる場合は、自分たちの現場に合わせて整理してください。
単体テストは誰がする？
単体テストは、機能単体レベルのテストとします。一番小さいテストであり、開発者の大切な仕事のひとつです。
最小単位のテストは自動化可能であり、自動化によって高速実行も可能になります。高速実行によって、テスト結果というフィードバックを早く受け取ることでき、軌道修正など変化への対応がアジャイルになります。
機能テストは誰がする？
機能テストは、単体テストを組み合わせたテストとします。ここではブラウザを介した1機能のテストを想定しています。画面テストとも言えます。
多くの開発組織では、機能テストをQAエンジニアが担当するケースが多いかもしれません。しかし、「仕様通りの機能を実現するのは開発者の責務」とも考えられるため、開発者が機能テストを担当する企業も増えてきています。筆者も同意です。
開発者が担当することで、「QAエンジニアが機能テストはじめようとしたけど全然動かない……」というように、タスクがブロッカーになってしまうことを防げます。さらに、仕様通りかどうかのテストを終わらせてからQAエンジニアがテストするため、UI/UXや非機能要件といった「仕様の確認」以上のテスト、いわゆる魅力的な品質に、QAエンジニアのコストを集中投資できます。
とはいえ、開発者も人間ですので、機能テストの見落としが発生する場合もあるでしょう。QAエンジニアは品質のプロフェッショナルとして、機能テストのレビューや、より良い機能テストの作り方を開発者に伝授することで、機能テスト品質の底上げにつなげます。
リグレッションテストは誰がする？
リグレッションテストは、アプリケーションを広く浅くテストすることで、アプリケーションが壊れていないことを確認するためのテストとします。繰り返し行われるテストであり、単調で膨大な作業ですので、自動化にぴったりなテストです。
開発者が機能テストを進めている間、QAエンジニアはリグレッションテストの作成に取り組めます。こちらも自動化できるなら自動化しても良いでしょう。
注意したいのは、あらゆるすべての機能をリグレッションテストでテストするのは困難だということです。なぜなら、UIによっては自動化が困難なケースもあり、テスト数が膨大な巨大なシステムでは、自動化は果てしない道のりとなります。もちろん、システムやサービスによっては高い基準の品質が求められるかもしれません。自分たちのシステムやサービスにおいて、最低限必要なリグレッションテストの粒度は何なのかをよく考える必要があります。
受け入れテストは誰がする？
受け入れテストは、仕様どおりに開発された機能が、期待通りの要件を満たしているかを確認するためのテストとします。受け入れテストは、スクラムでいうとスプリントレビューに近い存在です。よって、プロダクトオーナーを中心に、開発チーム全体で成果を確認する必要があります。
仕様通りかどうかは機能テストでチェックしているため、ここでは、スプリントの成果確認とともに、正しいものを作れているかどうかの確認にもなります。
このテストは特殊です。開発チーム全体で成果を確認しながら、さまざまなフィードバックを集めます。集めたフィードバックは、次回以降のスプリントで活用していきます。
テスト自動化の戦略を立てる
それでは、テスト自動化を進めるための「戦略」を具体的に考えていきましょう。戦略は状況に応じて変化するものなので、この連載ではいくつかのパターンを洗い出し、自分たちにあった戦略を選べるように選択肢を提示します。
本当に大切なゴール設定
アジャイル開発におけるインセプションデッキのように、テスト自動化におけるゴール設定はとても大切です。ゴールを明確にしなければうまくいっているかどうかもわかりません。筆者の場合は、テスト自動化を導入したいお客さまとの初回のMTGで、次のような問いを投げかけるようにしています。
ここで明確なゴール設定、課題設定ができない場合は、サービスを売ることはできません。売ってもお互い不幸せになるだけです。また、テスト自動化もおすすめできません。自動化を進めても、将来その効果を実感できないですし、うまくいった／失敗したの確認すらできません。
テスト自動化のタイムライン
ゴールの設定ができたら、そこまでの道のりを考えましょう。筆者の場合は「1か月」「2か月」「3か月」でまずはタイムラインを引きます。
重要なのは継続的にテスト自動化を進めていくことです。テスト自動化も継続的テストのひとつであり、サービス開発と並行で走る長距離マラソンのようなものなので、
- 普段の仕事をしながら
- 自動テストを増やしながら
- 自動テストをメンテナンスしながら
持続可能なスピードで走り続ける必要があります。上記のタイムラインではテスト自動化環境のセットアップからはじまり、自動テストの実装やメンテナンスの開始、CI/CDやSlackへの統合……など、実運用に沿った形で作業を進めていきます。
テスト自動化を推進する人は、関係するメンバーへの勉強会、操作のハンズオンなどを継続的に開催すると良いでしょう。この連載のようなテスト自動化の戦略と勉強会を、テスト自動化前にやっておくと、その後の作業が劇的に進捗するケースもあります。
そして、定期的にレビュー（ふりかえり）を行い、現在位置を確認しながらゴールを調整します。海外だと、四半期ごとのレビュー（QBR: Quarterly Business Review）が一般的のようです。
優先順位別！ テスト自動化の計画づくり
おおまかな戦略ができあがりました。次にもうちょっと具体的な計画づくりを行っていきます。
もし対象のシステムやサービスが大きなものであれば、どこから手を付けるか悩ましいものです。なぜなら、機能がたくさんあり。どれも重要に見えてくるからです。テストを増やすことはためらいなくできるかもしれませんが、スコープを絞ったりして減らすとなると勇気が必要です。
計画は優先順位によって変わってきます。ここでは、いくつかの事例として「目的ドリブンでの計画くづくり」「データドリブンでの計画づくり」「価値ドリブンでの計画づくり」「ポイント制の計画づくり」を紹介します。
目的ドリブンの計画づくり
目的ドリブンで計画を立てるなら、以下のような計画が例として考えられます。
- 重要機能の動作確認として、スモークテストを実装する
- 次に、スモークテストより広い範囲のリグレッションテストを実装する
- リグレッションのパターンを減らすために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の登場」について解説します。
著者プロフィール
- 藤原 大（フジハラ ダイ） スーパーアジャイルコーチ、エンジニアリングマネージャ、『リーン開発の現場』の翻訳者のひとり。創造的、継続的、持続的なソフトウェア開発の実現に向けて奮闘中。週末に娘と息子とお昼寝しながら世界のビーチや離島を旅する夢を見る。最近はテスト自動化サービス「mabl」の導入を支援中。
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
Article copyright © 2021 Fujihara Dai, Shoeisha Co., Ltd.
