2025.03.26
前回、テスト自動化を導入するメリット・目的や、活用シーンについてご紹介しました。
また導入に際して考慮すべき事項も解説したため、何を検討すべきなのかがご理解いただけたかと思います。
今回は、テスト自動化を進めていくにあたって、どのプロジェクトでどの範囲を自動化するかの判断・選定基準について解説していきます。
- もくじ
1．適切なプロジェクトを選定する5つの基準
テスト自動化を初めて導入する場合、パイロットプロジェクトとして少しずつ進めることが望ましいでしょう。
なぜなら、未経験の状態で、大きなミッションクリティカルなプロジェクトに自動化導入を試みようとすると、自動化導入（失敗）が原因でそのプロジェクトに悪影響を与え兼ねないからです。
適切なプロジェクトの選定基準として、以下の点が考えられます。
1-1 開発タイプ
まず一つ目は「開発タイプ」です。
新規開発のプロジェクトは、テスト自動化のスクリプティング開始時期が遅くなり、スケジュール的に厳しくなるため、初期の自動化スクリプト作成には不向きです。すでに構築されているシステムに対して機能開発するといった、開発保守案件などが適しています。
1-2 プロダクトの安定性
次に「プロジェクトの安定性」です。
コードの変更が頻繁に行われるプロジェクトは、初期の自動化スクリプト作成の活動に影響するため、避けたほうが良いでしょう。また、 テスト環境が頻繁に変化したり、不安定だったりする場合も、スクリプト作成の活動に影響するため避けることをおすすめします。
1-3 複雑性
次に「複雑性」です。
単純なプロジェクトでは、自動化の効果が実感しにくいです。ただし、逆に過度に複雑なプロジェクトでは、自動化に時間がかかりすぎたり、エラーが発生しやすくなったりする可能性があります。程よい難易度のプロジェクトが望ましいでしょう。
1-4 代表性
続いて「代表性」です。
パイロットプロジェクトで得られた知見を、他のプロジェクトに適用できることが理想的です。組織全体の状況を代表するプロジェクトを選ぶことをおすすめします。
1-5 ビジネスへの影響
最後に「ビジネスへの影響」です。
パイロットプロジェクトで問題が発生した場合でも、ビジネスへの影響が最小限に抑えられるプロジェクトを選ぶことが望ましいです。
2．どこまで自動化する？スコープの判断基準
テスト自動化を行うとき、すべての手動テストケースを自動化することは現実的ではありません。
適切な判断軸をもって、また自動化の難易度や効果を見据えながら、テスト自動化のスコープを判断することが求められます。
実際にテストケースを自動化するにあたり、技術面、コストメリット面などいくつかの視点で、テスト自動化をする・しないを判別することが必要になります。
その判断例としては以下のような項目があります。
✓ 技術的な実現可能性
・・・テストケースを自動化する方法が存在するか？
✓ 技術的な課題
・・・自動化の実装に影響を与える技術的な課題はあるか？チームは実装作業の準備ができているか？
✓ 投資対効果 (ROI)
・・・コーディングの労力に見合うだけの価値があるか？
✓ 実行頻度の価値
・・・テストケースを頻繁に実行する価値はあるか？
✓ テストの種類
・・・機能テストか非機能テストか？スモークテストスイート、回帰テストスイート、確認テストスイートのいずれかに属するか？
✓ 繰り返し可能性
・・・テストケースは繰り返し実行可能か？
✓ メンテナンス性
・・・SUTの更新による変更に容易に対応できるか？
✓ ビジネスワークフローのカバー範囲
・・・テストケースは頻繁に使用されるビジネスワークフローをカバーしているか？
✓ テストステップとテストデータの再利用可能性
・・・テストケース間で機能的な重複があり、テストステップやテストデータを再利用できるか？
3．テスト自動化の効果が見られる場面/難しい場面
テスト自動化の効果を得られやすい場面と難しい場面についても把握しておきましょう。
3-1 テスト自動化の効果が得られやすい場面
テスト自動化を行うことで大きな効果がみられるテストの特徴は以下の通りです。
- 長時間の手動テストの実行
長時間のテストを自動化することで、テスト時間を短縮し、効率を高めることができます。 - テストケースの同期実行
複数のテストケースを同時に実行したり、特定の順序で実行したりする必要がある場合、自動化は有効です。 - テストのタイミング精度が必要な場合
ミリ秒単位の精度が必要なテストでは、自動化による正確なタイミング制御が有効です。 - テスト結果をパイプラインで利用
CI/CDパイプラインにテスト自動化を組み込むことで、自動ビルドやデプロイと連動したテスト実行が可能になります。 - 大量のログファイルを解析
自動化ツールを使用してログファイルを解析し、特定のパターンやエラーメッセージを検出することができます。 - マルチのOS、ブラウザ、デバイス、場所などのテスト
自動化により、さまざまな環境でテストを実行し、互換性を検証することができます。 - 大量のテスト実行やデータ入力
自動化により、大量のテストケースを繰り返し実行し、広範囲なテストカバレッジを実現することができます。 - 非機能テスト
ストレステストや信頼性テストなどの非機能テストでは、負荷の生成やパフォーマンスの監視を自動化すると効果的である。
3-2 テスト自動化の効果が得られにくい場面
テストケースの自動化を困難または不可能にする特定のテスト条件があります。以下にいくつかの例を示します。
- デザインの検証
異なるプラットフォーム間でのUIの一貫性など、ソフトウェアの全体的な外観と感触は主観的なため、人間のレビューが必要です。 - 人の手を介在する
手動操作を継続的に発生する作業は一部を自動化できますが、あまり効果を得られないことが多いです - 技術的な制限
テスト自動化で要素を特定できなく、操作を行えないものは自動化は困難です。座標軸の自動化テクニックはあるが、保守性が大きく損ないます - 時間依存性の高いテスト
テスト実行が長時間かかる場合、自動化の効率が悪くなり、手動テストよりも設定が難しくなります。 - 探索的テスト
テスト自動化は、明確なテストステップをスクリプトにする必要があります。臨機応変なテストは困難です - ランダムなテスト
ランダムな操作や、値の検証は困難です。また、ランダムな操作を実現できたとしても、何を検証しているのか、テストの目的を失うことになります - ロボットを回避する仕組みをもつ機能
CAPTCHAなど、ロボットの操作をブロックする機能に対して、自動化するのは困難です。
まとめ
今回はテスト自動化を実施するプロジェクトの選定基準について解説しました。
テスト自動化を導入する際は、この「対象となるプロジェクトの選定」が重要になります。
５つの基準で適切にプロジェクトを選定することで、パイロット導入するプロジェクトを成功に導くことができ、またほかのプロジェクトにもテスト自動化を展開させることにつながります。
また、テスト自動化のスコープに関しても説明しました。すべてをテスト自動化することは望ましくありません。
テスト自動化を導入することによって得られる効果を最大限にするためには、技術的な視点、実用的な効果の視点などからスコープを選定することも重要だということを覚えておきましょう。
T-DASHはWebアプリケーションの動作確認・検証をコードを書かずカンタンに作成・実行できるテスト自動化ツールです。
初期設定からテストの実行まで、T-DASHのすべての機能でコードを書く必要はありません。そのため開発を担当していない非エンジニアの方でも手軽にご利用いただけます。
他のテストツールを導入している企業さま、まだ自動化ツールを試してみたことがない企業さまもこの機会にT-DASHにぜひ触れてみてください。
