第2章の補完「手動テストスクリプトからの組み替え」
第2章には、手動テストスクリプトから自動テストスクリプトへの組み替えを解説しているところがあります。しかし、経験のない、あるいは少ないテストエンジニアがこれに取り組むと、思わぬ落とし穴にはまり込む場合があります。ここでは、筆者の経験からあらかじめ知っておきたい知識を、第2章の補完説明としていくつか紹介します。
テストケース間の依存関係の排除
第2章の「2.2.3 詳細な手動テストスクリプト」では、詳細な手動テストスクリプトがあれば、自動化は容易であると述べられています。しかし、筆者の経験上、詳細な手順で書かれた手動テストスクリプトであっても、そのまま自動化するのは正しい選択とはいえません[1]。それは、次表に示す方針とそれをもたらす理由があるためです。
|
テスト スクリプト |
方針 | 理由 |
|---|---|---|
|
手動テスト スクリプト |
・テストケース間に依存関係を持たせる |
・テスト実行が遅い ・事前条件（事前状態）を作るのに時間がかかる ・途中に障害があっても柔軟な対応（別のテストケースを実行し事前状態を作る、SQLで直接データを挿入する、別のテストケースを実施するなど）ができる |
|
自動テスト スクリプト |
・テストケース間は個別に完結する ・事前条件は個別もしくは共有で設定する |
・テスト実行が速い ・ドミノ効果により後続のテストがまとめて失敗することが続くと自動実行の効果が減る ・依存関係を持たせた場合の柔軟なリカバリーを作り込むのが難しい ・障害はテストスイートの実行後に調査するためにテストケースが個別に完結しているほうが調査しやすい |
テストケース間の依存関係を図に示すと以下のようになります。
手動テストスクリプトがすでにあり、それを元にテスト自動化を図るときには、その手動テストスクリプトを組み替える必要があります。
[1] 手動テストスクリプトをそのまま自動化しようとする問題は、『システムテスト自動化 標準ガイド』の原著者らがまとめている「Test Automation Patterns」（テスト自動化パターン）の1つ「SORCERER'S APPRENTICE SYNDROME」でまとめられています。
テストスイートの単位
テストケース間の依存関係によって手動テストスクリプトと自動テストスクリプトはテストケースをまとめるテストスイートの単位も異なります。手動テストスクリプトから自動テストスクリプトへのテストスイートの組み替えは、共通の事前条件を持つテストケースを抽出してテストスイートとしてまとめることによって実施します。
|
テスト スクリプト |
方針 | 例 |
|---|---|---|
|
手動テスト スクリプト |
・前のテストケースの事後状態を次のテストケースの事前状態としてテストケースをまとめる ・上位の分類は何らかの別のテスト観点（エンティティ、業務、業務の実施部門など）を使う |
・エンティティ（商品や契約など）のCRUD ・業務のライフサイクル（サイクルテスト） ・ユーザーが一般に実行する画面遷移 |
|
自動テスト スクリプト |
・共通の事前条件を持つテストケースをまとめる |
・エンティティが作成されたときに、エンティティに変更を加える ・ある時間やタイミングになったとき ・ある画面にいるとき |
事前条件の設定
手動テストスクリプトでは主に前のテストケースの実行結果が次のテストケースの事前条件（事前状態）となるために、特別な考慮は不要ですが、自動テストスクリプトはテストケースもしくはテストスイート単位で事前状態を個別に作成しますので、複数の設定方法があります。以下に2つの方法を示します[2]。
| 方針 | メリット | デメリット |
|---|---|---|
| テスト対象と同一のレイヤーを利用する | ・テスト対象のレイヤーのインターフェースのみを理解していれば作成できる |
・テスト対象がGUI経由の場合、GUIの変更で事前状態の設定（以降、Fixture）が失敗する可能性がある ・Fixtureの実行が下のレイヤーで実装する場合に比べて遅く、更にテスト対象がGUIの経由の場合、非同期処理など安定させるのが難しい |
| テスト対象より下のレイヤーを利用する |
・Fixtureの実行が同一レイヤーを使う場合より速い ・ビジネスドメインにもよるが、ユーザーインターフェースより、APIやデータベースのスキーマのほうが変更頻度が低い場合が多いため、アプリケーションの変更によりFixtureが失敗する可能性が減る ・下のレイヤーに対して自動テストが存在する場合、部品として再利用できる |
・テスト対象の下のレイヤーのインターフェースの理解が必要である ・下のレイヤーのチームとテスト自動化チームが連携してない場合、下のレイヤーのインターフェース変更によってFixtureが失敗する可能性がある |
[2] 事前状態の設定も含めて、自動テストスクリプトがどのようにテスト対象と通信するべきかは、Test Automation Patternsの1つ「RIGHT INTERACTION LEVEL」で解説されています。
おわりに
第2章の大部分は、現状でも有用な示唆を含んでいます。本稿ではテスト自動化を専任とする筆者の経験から、第2章に現在の実務レベルで必要な知識を補完しました。筆者の印象では、本書を補完する経験則は前述のTest Automation Patternsとして体系化されつつあります。本書を読んだ後、実務で課題にぶち当たったときには、Test Automation Patternsサイトの「Test Automation Issues」で解決策を探してみるとよいでしょう。
本稿をきっかけに『システムテスト自動化 標準ガイド』やTest Automation Patternsに興味を持ってくだされば幸いです。
