2024.11.13
テスト自動化の導入を検討されている方々に聞きます。
テスト自動化を構築した後は、使えば使うほど手動テストの作業が置き変わり、リターン（ヒューマンコストの削減）だけが発生すると思いますか？
答えはNOです。
必ず、一定の運用コストが発生します。そして運用を考慮していない仕組みになっていると、かえって大幅なコスト増になり、テスト自動化の特徴であるコストメリットが失われることになります。
筆者はテスト自動化を10年近くやってきました。テスト自動化として、Selenium、Appium、T-DASH、Ranorex等いろいろなソリューションを用いて構築してきました。
アプリケーションエンジニアであれば、テスト自動化を構築することだけなら割と簡単にできます。
ただ、その先の運用フェーズを考えずに構築してしまうと、後で苦労します。筆者も運用フェーズになって、運用の非効率を感じてテスト自動化を作り直したことがあります。(詳しくは以下の記事で語っています。)
つまり、テスト自動化を有効活用するための要は、構築より運用にあるのです。
そこで、本連載記事ではテスト自動化の運用を成功させるためにおさえておきたいポイントを全５回に分けて解説します。
第1回である今回は、プロダクトの仕様が追加・修正されたときに発生する運用について解説していきます。
- もくじ
1．仕様追加・変更に伴うスクリプティングとは
プロダクトは常に成長します。そのたびに仕様の追加や変更が行われるでしょう。
仕様の追加が行われれば、テスト自動化のカバレッジが下がるために、新規スクリプトを考える必要があります。
仕様の変更が行われれば、変更内容によっては、これまで動いていたテスト自動化が動かなくなる可能性があります。
このようにプロダクトの仕様追加・変更に伴って、発生するのがテスト自動化のスクリプティングです。
プロジェクトの中では、どのようにスクリプトの追加・修正をするか、計画的に行う必要があります。なぜなら、テスト自動化がプロジェクトの期間中に期待の結果を出せなくなる可能性があるからです。
また、上記のようなネガティブな状況が続くことで、最終的にテスト自動化が正しく運用されなくなり、廃止になる可能性もあります。そのような状況にならないためにも、プロダクトの仕様追加・変更が行われた際は、テスト自動化のスクリプティングを計画的に行うことが重要です。
次章から、既存機能で仕様が変更された場合と、新規機能で仕様が追加された場合の、テスト自動化のスクリプティングについて解説していきます。
2．既存機能で仕様が【変更する場合】の運用
まず、アプリケーションの既存機能で仕様変更が行われる時の運用について、プロセス上の課題とその課題の解決策を解説していきます。
2-1 プロセス上の課題
一つのプロジェクトで各工程を時間軸で表した例が以下の図になります。
既存機能で仕様が変更される場合、仕様変更で動かなくなるテスト自動化の修正する必要があります。
ただ、テスト自動化を修正できるようになるのは、対象のアプリケーションがテスト環境にリリースされてからです（図の仕様変更のアプリケーション利用可能期間）。
一方で、この修正とテスト実行はこのプロジェクトのテスト期間に終わらせる必要があります（図の自動化修正、リグレッションテスト期間）。なぜなら、テスト自動化がこのプロジェクトのリグレッションテストとして役割を担っているからです。
このように、スクリプトの修正期間が限られてしまうというプロセス上の課題があります。
そのうえ、テスト期間中に、ユーザビリティの観点でさらなる仕様変更が入る可能性もあります。追加仕様変更がテスト期間中に発生すると、さらにスクリプト修正を行わないといけない課題も発生します。
2-2 スクリプティングの進め方
そこで運用を成功させるためには、以下の流れで進めていきます。
- 仕様変更点の収集
- 既存のテスト自動化スクリプトで影響を受けるもののリストアップ
- テスト自動化修正の優先順位を決める
- スクリプティングの開始時期を決める
- リグレッションテストの開始目標・期限を決める
- 期限に間に合わない場合の策を検討
1．仕様変更点の収集
最初に要求仕様が固まってから仕様変更の内容を収集します。
2．既存スクリプトで影響を受けるもののリストアップ
その仕様変更の情報から、既存のテスト自動化スクリプトで影響を受けるものをリストアップします。リストアップされたものそれぞれで修正規模を見積もります。
3．テスト自動化修正の優先度を決める
次にテスト自動化修正の優先順位を決めます。優先度の基準としては、機能の重要性、仕様変更の大きさ（アプリケーションコードの修正量）などで決めます。
4．スクリプティングの開始時期を決める
次にテスト自動化のスクリプティングが開始できるタイミングとリグレッションを終わらせる期限を確認します。この期間は、主に以下の運用が発生します
- 既存のスクリプトで仕様変更の影響を受けるものを修正とテスト自動化のテスト
- テスト期間中に変更が加えられた仕様・UI等のスクリプトの修正
- リグレッションテストで失敗したテストの原因調査
5．リグレッションテストの開始目標・期限を決める
「2-1 プロセス上の課題」で説明したように、基本的にはテスト環境にアプリケーションがリリースされてからスクリプティングが可能になります。
そのタイミングから、目標としていつからすべてのリグレッションテストを開始可能にするか（影響のないスクリプトは常に実行させたほうがいいでしょう）、そして最終的に間に合わせないといけない期限（テストが終わる）を設定します。
その期間、テスト自動化エンジニアが集中できるように配慮する必要があります。
6．期限に間に合わない場合の策を検討
最後に、万が一の場合として、テスト自動化エンジニアの工数が不足して間に合わない場合も考えておく必要があります。
この場合は、優先度の低いテストをテスト自動化で担保せず、手動テストのみにすることも検討し、事前に手動テストチームや開発チームと相談するといいでしょう。
3．新規機能で仕様が【追加になる場合】の運用
続いて、仕様変更時の運用とは異なり、新しい仕様が追加になる場合の運用を説明します。
3-1 プロセス上の課題
先ほどの、仕様変更時の運用とは異なり、新しい仕様が追加になる場合の運用を説明します。
新規機能に対してプロジェクト期間中にテスト自動化のスクリプティングを行うには、以下のような難点があります。
- 安定したアプリケーションに対してスクリプティングできる期間が限られる
- 既存機能の仕様変更の対応との優先度
ここで考えなければならないのは、安定したアプリケーションがスクリプティングとして使える期間です。
具体的には、新規機能をプロダクトに追加した場合、既存機能の仕様変更に比べてテストにて多くの不具合が見つかる可能性が高いです。
上記のような、不具合を多く含んでおり、開発改修・テストが必要な状態を「不安定なアプリケーション」とします。それに対して、開発改修・テストが収束し、不具合が少なくなった状態を「安定したアプリケーション」とします。
不安定なアプリケーションに対して、テスト自動化のスクリプティングを行うと何が起こるでしょうか？それは、不具合のあるアプリケーションに対して成功するテスト自動化スクリプトが出来上がります。もしくは、安定したアプリケーションになるまで、スクリプトの修正が何回も発生する可能性があります。
このように、不安定なアプリケーションの時にテスト自動化のスクリプティングを始めると、通常に比べて多くの工数が発生する可能性があります。とはいえ、テストの初期段階でアプリケーションが安定するとは限りません。テスト終盤になる可能性もあります。安定するまで待ってからスクリプティングを開始すると、たいていプロジェクト期間中に間に合わないでしょう。
次に考えるのは、プロジェクトで新規機能追加と既存機能の仕様変更両方が発生する場合です。この場合、先ほど説明したように、既存のテスト自動化のテストが失敗します。プロジェクトとしてどちらを優先にするかを検討する必要があります。テスト自動化で、既存機能のテストか新規機能のテストをカバーするのか？
この２つの課題から、どのように対応する必要があるかを考える必要があります。
3-2 スクリプティングの進め方
筆者がお勧めする案は次のようになります。
- 新規機能は基本的に手動テストで保証し、テスト自動化では保証しない。もしくは一部機能のみ保証する（リソース、スケジュールが間に合えば）。
- 既存機能はテスト自動化で保証する。プロジェクト期間中に修正を行い、リグレッションテストをすべてパスするようにする。
- 新規機能のスクリプティングは既存機能のスクリプトの修正が終わり、かつアプリケーションが安定してから開始する。新規機能のスクリプトは次のプロジェクトからリグレッションテストとして使えるようにする。
このように、手動テストとテスト自動化で品質保証するスコープをあらかじめ決めておき、テスト自動化は優先度を決めて、無理のないスケジュールでスクリプティングを行うのが良いでしょう。
まとめ
今回は、プロダクトの仕様が追加・修正された際に発生する運用についての内容を解説しました。
プロダクトの新規機能追加・修正が発生すると、スクリプティングの運用が主として発生します。スクリプティングは期間が限られているため、テスト期間中に対応することは簡単ではありません。一方、失敗するスクリプトの修正を放置すると、テスト自動化の価値が下がり、陳腐化してしまいます。
テスト自動化を陳腐化させず、かつプロジェクトで最大限に活用させるためには、手動テストとテスト自動化の双方の役割を明確にし、テスト自動化エンジニアが集中できるリソース確保をする必要があるでしょう。
ぜひ今回の内容を、プロダクトの仕様追加・修正によって発生する、テスト自動化のスクリプティングにお役立てください。
第2回の記事はこちら▼
