はじめに
テスト自動化エンジニアのシラバスを再度読み直し、各章をDailyで読めるようにしてみた
CTAL-TAEの 1.2 Test Automation in the Software Development Lifecycle を今回、翻訳・解説する
SDLC
ウォーターフォールモデル
ウォーターフォールモデルは、各フェーズが順次進行する線形なモデル。
要件定義、設計、実装、検証、保守といったフェーズがあり、各フェーズは明確に区切られ、ドキュメント化される。
テスト自動化は通常、実装フェーズと並行して、もしくはその後に行われる。
ソフトウェアコンポーネントがテスト可能になる検証フェーズで、テストの実行される。
テスト自動化の適用
- 検証フェーズ
ソフトウェアが完成した後に、すべての機能を網羅的にテストするフェーズです。このフェーズで、機能テスト、性能テスト、セキュリティテストなどの自動化が中心となります。 - 回帰テスト
新機能を追加したり、バグを修正したりした際に、既存の機能が壊れていないかを確認するテストを自動化します。
メリット
- テスト計画が立てやすい
プロジェクトの初期段階からテスト計画を詳細に立てられる。 - テストケースの管理が容易
テストケースを体系的に管理できる。
デメリット
- 変化に弱い
後半のフェーズで要件が変更になると、テストケースの修正に時間がかかる可能性がある - フィードバックが遅い
実装タイミングが後工程のため、開発の後半までバグが見つからない可能性。
Vモデル
Vモデルは、上流工程と下流工程がV字型に対応するモデル。
上流工程で定義された要件に対して、下流工程で検証・統合活動が行われる。
このモデルでは、コンポーネントテスト、コンポーネント統合テスト、システムテスト、システム統合テスト、受け入れテストといった伝統的なテストレベルが定義される。
各テストレベルに対して、テスト自動化フレームワークを導入することを推奨。
テスト自動化の適用
- 各テストレベルでの自動化
各テストレベルに対応したテスト自動化フレームワークを導入し、テストを自動化する。
メリット
- 品質の高いソフトウェアを開発できる
各フェーズでテストを行うため、品質の高いソフトウェアを開発できる。 - テストの漏れを防ぐ
テストレベルが明確に定義されているため、テストの漏れを防ぐことができる。
デメリット
- 柔軟性に欠ける
アジャイル開発のような変化に対応しづらい可能性がある。
アジャイルソフトウェア開発
アジャイルソフトウェア開発では、ウォーターフォールやVモデルと異なり、テスト自動化エンジニアとビジネス関係者がロードマップ、タイムライン、テストの計画を決定することができる。
アジャイルでは、コードレビュー、ペアプログラミング、頻繁な自動テスト実行などのベストプラクティスが推奨される。
サイロ化を排除し、開発者、テスター、その他の関係者が協力することで、すべてのテストレベルを適切な範囲と深さで自動化し、スプリント内での自動化という目標を達成できる。
テスト自動化の適用
- 継続的なテスト
スプリントごとにテストを繰り返し行い、ソフトウェアの品質を維持。 - テスト駆動開発（TDD）
テストケースを先に作成し、それに合わせてコードを開発。 - デプロイパイプライン
コードの変更が自動的にビルド、テスト、デプロイされるパイプラインを構築。
メリット
- 変化に強い
顧客のフィードバックを迅速に反映できます。 - 品質の高いソフトウェアを短期間で開発
継続的なテストにより、品質の高いソフトウェアを短期間で開発できる。
デメリット
- 計画が立てにくい
スプリントごとに計画が変更になる場合があります。 - ドキュメントが不足しがち
コードが中心となり、ドキュメントが不足する可能性があります。
テスト自動化選定
テスト対象システムの分析
テスト自動化ツールの選定にあたり、まずテスト対象システムを詳細に分析することが重要。
- アプリケーションの種類
Webアプリケーション、モバイルアプリ、デスクトップアプリなど、アプリケーションの種類によって最適なツールは異なる。 - 技術スタック
使用されているプログラミング言語、フレームワーク、データベースなど。 - テスト対象の機能
テストする機能範囲を明確にすることで、必要なツール機能を絞り込むことができる。 - システムの規模
システムの規模が大きいほど、より高度な機能を持つツールが必要になる場合がある。
ツール機能の比較
様々なテスト自動化ツールには、それぞれ特徴的な機能があります。
- 記録・再生機能
操作を記録し、再生することでテストケースをかんたんに作成できる機能。 - スクリプト作成機能
プログラミング言語を用いて、より柔軟なテストケースを作成できる機能。 - オブジェクト認識機能
画面上の要素を正確に識別し、操作できる機能。 - データ駆動テスト機能（データドリブン）
テストデータを変えて繰り返しテストを実行できる機能。 - 並列実行機能
複数のテストケースを同時に実行し、早くテストできる機能。 - レポート作成機能
テスト結果をわかりやすくレポートとして出力する機能。 - そのほか
CI/CDツールとの連携、バグ管理ツールとの連携など、他のツールとの連携がスムーズに行えるかなど。
チームのスキルと経験
- プログラミングスキル
チームメンバーのプログラミングスキルによって、選択するツールの難易度が変わる。 - テスト自動化経験
過去のテスト自動化経験に基づいて、適したツールを選択。 - ツールの習得意欲
新しいツールを学ぶ意欲が高いチームであれば、より高度なツールを選択できる。
コスト
- ライセンス費用
商用ツールは、ライセンス費用がかかる。 - 導入コスト
ツールの導入には、初期設定や学習コストがかかる。 - メンテナンスコスト
ツールを継続的に利用するためには、メンテナンス費用がかかる。
ツール選定でその他の考慮事項
- オープンソースか商用か
オープンソースツールは無料で利用できますが、サポート体制が弱い場合がある。商用ツールは、サポート体制が充実していることが多いですが、費用がかかる。 - コミュニティ
ツールに関するコミュニティが活発であるか確認。 - 拡張性
将来的に機能拡張が必要になった場合に、対応できるか確認。
適切なツールの選択プロセス
- テスト対象システムの分析
テスト対象を明確にする。 - 必要な機能の洗い出し
どのような機能が必要かを洗い出す。 - 候補ツールの選定
複数のツールを候補に挙げる。 - 評価
各ツールの機能、価格、コミュニティなどを比較評価する。 - PoC (Proof of Concept)
可能であれば、実際にツールを試してみる。 - 決定
最適なツールを選択する。