問題39：テスト自動化の保守と異常の分析

問題 #39

あるビジネスアプリケーションが保守フェーズにあり、ビジネスロジックへのいくつかの変更がすでに実装されているか、次のリリースで実装される予定である。変更が行われるたびにビジネスケースが回帰テスト（リグレッションテスト）されることを保証するために、テスト自動化が使用されている。

テスト自動化にはキーワード駆動アプローチが使用されている。前回のリリース以降、いくつかの緊急修正が必要となり、現在、テスト自動化のレポートが異常（アノマリ）を浮き彫りにしている。

テストアナリストは次にどのステップを実施すべきか？（※2つ選択してください）

a) 行われた変更を反映するために、キーワードとデータを更新する
b) 自動化スクリプトをモジュール化する
c) 異常（アノマリ）を分析し、問題がキーワード、入力データ、自動化スクリプト自体、またはテスト対象のアプリケーションのいずれにあるかを特定する
d) 同じデータを使用して失敗した自動テストを開発者に手動でステップ実行してもらい、障害がアプリケーション自体にあるかどうかを確認する
e) 異常の原因が見つからない場合は、自動化された回帰テストパックからそのテストを削除する

正解

a) 行われた変更を反映するために、キーワードとデータを更新する

c) 異常（アノマリ）を分析し、問題がキーワード、入力データ、自動化スクリプト自体、またはテスト対象のアプリケーションのいずれにあるかを特定する

解説

この問題は、テスト自動化環境下において、テストアナリスト（TA）が担うべき適切な役割と責任範囲（特に異常時のトリアージと保守）を問うています。

a) 正解。 キーワード駆動テストにおいて、ビジネスロジックの変更に合わせて「キーワード（操作の定義）」や「テストデータ」を保守・更新することは、ビジネス要件を理解しているテストアナリスト（TA）の重要な役割です。
b) 不正解。 自動化スクリプトそのものの「モジュール化」やリファクタリングといったコードレベルの作業は、TAではなくテスト自動化エンジニア（TAE）やテクニカルテストアナリスト（TTA）の役割です。
c) 正解。 自動テストが失敗（異常をレポート）した場合、TAはその根本原因を分析します。仕様変更によるデータの陳腐化なのか、スクリプトの不具合なのか、それともアプリケーション自体の本物のバグなのかを切り分ける責任があります。
d) 不正解。 失敗した自動テストの処理を「開発者に」手動でステップ実行してもらうのは誤りです。障害がアプリケーションにあるのかテストウェアにあるのかを確認するために、テストアナリスト自身が手動でステップ実行して検証すべきです。
e) 不正解。 異常の原因がすぐに見つからないからといって、重要なビジネスケースを担保している回帰テストを安易にテストパックから削除してはいけません。

ポイント

JSTQB AL TA試験において、「テスト自動化」に関する問題が出た場合は、TA（テストアナリスト）と TAE（テスト自動化エンジニア）の役割分担を明確に意識することが最大の鍵になります。

キーワード駆動テストにおける役割分担:
- TA（テストアナリスト）: 「何をテストするか（What）」を定義します。ビジネスプロセスに基づき、キーワードの組み合わせとテストデータを設計・保守します。
- TAE（自動化エンジニア）: 「どうやって動かすか（How）」を実装します。キーワードを実際にシステム上で動かすためのスクリプト（コード）を作成・保守します（選択肢bのような作業）。
自動テストがコケた時の「最初の行動」:
自動テストが失敗（赤色）になったからといって、すぐに「バグだ！」と開発者に報告する（または開発者に調査を丸投げする：選択肢d）のはアンチパターンです。まずはTAが「テストデータが古くないか」「画面の仕様変更（ボタン名が変わった等）に対応できているか」を手動で追体験し、問題を切り分ける（トリアージする）必要があります。

異常（アノマリ）という言葉
JSTQBでは、期待結果と実際の結果の「ズレ」を総称して「異常（Anomaly）」と呼びます。これが本物の欠陥（Defect/Bug）なのか、テストケースの誤りなのか、環境の問題（False positive: 偽陽性）なのかを分析することが、このプロセス（選択肢c）の目的です。