はじめに
テスト自動化エンジニアのシラバスを再度読み直し、各章をDailyで読めるようにしてみた
3.1.4 Apply Different Approaches for Automating Test Cases を今回は翻訳・解説する
テスト自動化を実現するために、さまざまなアプローチが利用できます。それぞれのアプローチには、独自のメリットとデメリットがあり、プロジェクトの特性やチームのスキルセットに合わせて選択する必要があります。
キャプチャ/再生
手動で一連操作を行ない、SUTの操作を記録するアプローチである。
これらのツールは記録中にテストスクリプトを生成し、ツールによってはテスト自動化コードを修正することもできる。
コードを出力しないツールはノーコードテスト自動化と呼ばれ、一方コードを出力するものはローコードテスト自動化と呼ばれる。
メリット
- プログラミングスキルが不要で、短時間でテストケースを作成できる。
- GUIテストに適している。
デメリット
- テスト対象システム（SUT）の変更に弱く、メンテナンスコストが高い。
- テストケースの構造が複雑になりやすく、可読性が低い。
- テストデータの管理が難しい。
活用シーン
- 回帰テスト
- GUIの動作確認
- 短期間で多くのテストケースを作成したい場合
線形スクリプト
TAEがカスタムテストライブラリを作成しないプログラミングで、テストスクリプトの作成と実行に用いられる。
TAEはキャプチャー＆プレイバックで記録されたテストスクリプトを活用し、修正できる。
メリット
- 柔軟性が高く、複雑なテストロジックを実装できる。
- テストケースのカスタマイズが容易。
デメリット
- プログラミングスキルが必要。
- メンテナンスコストがかかる。
活用シーン
- 機能テスト
- APIテスト
- 複雑なシナリオのテスト
構造化スクリプト
テストライブラリを利用し、再利用可能なテストステップやユーザーシナリオを定義できる
メリット
- メンテナンス性、拡張性が高い。
- ビジネスロジックとテストロジックを分離できる。
- 大規模なプロジェクトに適している。
デメリット
- 初期構築に時間がかかる。
- プログラミングスキルが必要。
活用シーン
- 大規模なシステムのテスト
- 長期間にわたるテストの保守管理
テスト駆動開発（TDD）
SUTの新しい機能を実装する前に、テストケースは開発プロセスの一部として定義される。
このアプローチはテスト、コード、リファクタリングもしくは、レッド、グリーン、リファクタリングのサイクルである。
- 開発者は失敗するテストケースをまず作成する。（レッド）
- 開発者は機能を開発し、テストケースを満たす（グリーン）
- コードをリファクタリングし、最適化し、クリーンコード原理に従う。(リファクタリング)
メリット
- コード品質の向上
- テストカバレッジの向上
- バグの早期発見
- 設計段階からの品質向上
デメリット
- 初期導入コストが高い
- 開発者の意識改革が必要
活用シーン
- ユニットテスト
- 新機能開発
データ駆動テスト
テストデータ（CSVファイル、Excelファイルなど）を元に、同じテストケースを繰り返し実行できる。
メリット
- テストケースの拡張が容易
- テストデータの変更だけで、複数のテストケースを実行できる
デメリット
- テストデータの管理が必要
活用シーン
- 多様な入力値でのテスト
- 組み合わせテスト
キーワード駆動テスト
キーワードとテストデータを使用して、テストケースを定義し、技術レベルの高くない人でも使いやすくする
メリット
- テストアナリストやビジネスアナリストがテストケースの作成に参加できる
- テストケースの可読性が高い
デメリット
- キーワードの定義とメンテナンスが複雑
活用シーン
- ビジネス要件に基づいたテスト
- 非技術者との協業
振る舞い駆動開発（BDD）
自然言語でテストケースを記述し、自動化します。
メリット
- 開発者、テスター、ビジネスアナリスト間のコミュニケーションが円滑化
- テストケースの可読性が高い
デメリット
- 複雑なテストケースの定義には技術的なスキルが必要
活用シーン
- ユーザーストーリーに基づいたテスト
- アジャイル開発