2025.03.26
第2回では、テスト自動化をどのプロジェクトで、どの範囲で実施するのかの判断基準までご紹介しました。
今回はいよいよ手動テストを自動化に移行するフェーズについてです。
テスト自動化に移行する際に確認しておくべきことや、テスト自動化を継続して運用していくためのポイントについて解説していきます。
- もくじ
1．手動テストを自動テストに移行する際の懸念事項
手動テストからテスト自動化へ切り替える対象として、リグレッションテストが一般的です。
自動化によってテストの効率が向上し、実行頻度を増やすことが可能になります。しかし、移行にはさまざまな課題が伴い、慎重な検討が必要です。
移行に関しての懸念事項として、主に以下の６つが上げられます。
- テストケースの妥当性
- 移行コストの増加
- 機能の重複
- データ共有の依存
- テストの相互依存性
- テスト実行の前提条件
それぞれ解説していきます。
1-1 テストケースの妥当性
移行する手動テストが、そもそも正しいテストであることを保証する必要があります。
なぜなら、手順や期待値などが間違ったテストを自動化しても、正しい結果を得られず、品質検証できないからです。
そのため、テストケースの内容を見直し、正しい手順と期待値であるかを確認してから、自動化に移行しましょう。
1-2 移行コストの増加
手動テストから自動テストに移行する際、一時的にコストが増加することが懸念されます。
なぜなら移行中は、手動テストと自動テストの両方が実施する必要があるからです。また、自動化スクリプトの作成・メンテナンスに工数がかかることも考えられます。
特に初期の段階では、自動化のメリット（効率化やコスト削減）が得られる前に開発チームやテストチームの負担が一時的に増す点を考慮する必要があります。
1-3 機能の重複
自動テストへの移行において、同じ機能・ステップのスクリプトが複数のテストケースで重複して作成されることがあります。
重複するとメンテンナンス性が低下し、修正が必要になった際に複数のスクリプトを更新する必要が出てきてしまいます。
こういった事態を避けて保守性を向上するためにも、共通化で最適化することが望ましいです。
1-4 データ共有の依存
自動テストでは、テストデータを複数のテストケースで共有することがあります。
ただし、この依存度が高くなると、データの変更・削除などでほかのテストケースに悪影響を与えます。
例えば、Aというテストケースがデータを変更すると、それを利用するBというテストケースが想定外の動作を引き起こす可能性があります。
そのため、共有の依存は減らし、個々のテストケースが独立して実行できるようにすることが望ましいでしょう。
1-5 テストの相互依存性
1つのテストが、複数の他テストに依存することがあります。
依存性が高まると、テストケースの正しい実行順番を維持する必要があり、テスト実行が複雑になります。
例えば、テストA、B、Cの順番で実行する必要がある場合、その順番で実行し、もし途中のテストBで失敗すると、Cを実行しても必ず失敗します。そのためCを実行させないなどの実行制御が必要になります。
パイプラインなどで依存性を下げる仕組みが必要です。
1-6 テスト実行の前提条件
テストを実施するためにテストデータがそろっているなどの前提条件を必要とすることが多いです。
この前提条件を構築する自動化スクリプトの作成と、実行管理が必要になります。
2．テスト自動化を継続運用するために考慮すべきこと
コード修正が行われ、テスト環境にデプロイ、利用可能になった直後に、テストを継続的に実行することを、「継続的テスト」といいます。
これにより、即時のフィードバックが提供され、欠陥を早期に検出することで欠陥コストを削減できます。ビルドプロセスの早い段階でテストをシフトレフトすることにもなります。
継続的テストを行うために、いくつかの運用を考慮する必要があります。ここでは7つご紹介します。
2-1 テストスイートの更新
テストスイートとは、テストの目的や条件が似ている複数のテストケースをまとめたものです。
仕様変更に際しては、テストスイートに必要な変更を行い、テスト自動化のテストを行ってから、テストスクリプトをデプロイしましょう。
2-2 テスト自動化スクリプトの不具合への対応
スクリプトに不具合が発生した場合、改修可能性の検討や工数見積もり、そして修正をすぐにするか の判断を行いましょう。
例えば、修正規模が大きく時間がかかる場合、もしくは優先度的に見送らないといけない場合、いったんそのテストを実行対象から外します。（つまり、手動テストでカバーするように切り替えます。）そして、修正が終わったら、実行対象として再登録する対応を行います。
2-3 テスト自動化のバージョンコントロール
プロダクトのバージョン（ブランチ）に対応したテストスイートを管理・デプロイする仕組みが必要です。
各ブランチに適したテストを用意し、プロダクトがロールバックした際にはテストも対応するバージョンへ戻せるようにします。
これにより、テスト自動化が常に正しい環境で実行され、品質保証の一貫性を保つことができます。
2-4 環境のアップデート
OSやブラウザのソフトウェア等、さまざまなバージョンアップを行いましょう。
その場合、新しいバージョンの環境で今のテスト自動化が動くことを事前に検証した上で、継続実行する環境を更新していく必要があります。
2-5 CI/CDの組み込み
CI/CDの組み込みも重要です。
プロダクトがテスト環境にデプロイされた後、事前設定の操作含めて、適切な順番でテスト自動化が実行されるように構築しましょう。
2-6 テスト実行結果の集積・表示と分析
テスト実行結果の集積や表示、分析も行いましょう。
継続的なテスト実行により、テスト実行結果が多く蓄積される場合や、複数の環境や並行実行でテスト結果が複数個所にある場合、１か所に集約して表示されるようにすると、分析がよりしやすくなります。
さらに、貯めた結果を分析して、プロダクトの状態を評価するダッシュボードなどを検討すると、より自動化の実行結果が活きてきます。
2-7 実行速度とモニタリング
継続的な運用のためには、開発へ求められるスピードでフィードバックし、また次のデプロイ・テスト実行までに完了させておくなどのテスト実行スピードを考慮する必要があります。
また、この実行時間をモニタリングし、実行時間が劣化していないかなど定期的に確認することが重要です。
まとめ
いかがでしたか？
今回は手動テストから自動化へ切り替えていくときの懸念事項と、テスト自動化を導入後、それを継続的に利用していくための検討事項を解説しました。
手動から自動化への切り替えの一時的なハードルを乗り越えるために本記事の内容をぜひ参考にしてみてください。
そして、これまで3回に分けてテスト自動化を導入する際のポイントについて解説してきました。
この連載を通して、自動化を作るだけではなく、継続的に実行してプロダクトの品質を常時担保するような運用に乗せることができれば、筆者としてうれしい限りです。
テスト自動化運用については以下の記事にて詳しく解説していますので、こちらもぜひご覧ください。
T-DASHはWebアプリケーションの動作確認・検証をコードを書かずカンタンに作成・実行できるテスト自動化ツールです。
初期設定からテストの実行まで、T-DASHのすべての機能でコードを書く必要はありません。そのため開発を担当していない非エンジニアの方でも手軽にご利用いただけます。
他のテストツールを導入している企業さま、まだ自動化ツールを試してみたことがない企業さまもこの機会にT-DASHにぜひ触れてみてください。
