（狭い範囲だがきわめて重要な）問題がある。アプリケーションのバージョン1.0で利用したテストスクリプトが、そのアプリケーションのバージョン2.0ではたいてい使えなくなるという問題だ。テスト担当者は新しいものをゼロから作成せずに済むよう古いテストスクリプトを編集しようとするが、その作業は時間がかかり、単調かつ退屈で、障害も発生しやすい。問題が発生するまでスクリプトを実行（時間がかかる場合が多い）し、それがテストスクリプトの問題なのかどうかを確認し、もしそうならばこれを修正して最初からやり直す。それが、場合によっては数百回にもおよぶ。
例を示す。同じ機能でもアプリケーションのバージョン1.0ではコンボ・ボックスを使っていて、バージョン2.0ではテキストボックスを使っている場合のテストスクリプトがどうなるか想像していただきたい。言うまでもなく、コンボ・ボックス（だったもの）を使うスクリプトは2.0では問題を引き起こす。これは、「Changed Object （CO：オブジェクト変更）」エラーの一例だ。エラーのタイプとしてはほかにも、2.0で削除されてしまった GUI エレメント（ボタンやチェックボックスなど）にスクリプトがアクセスしようとして発生する「Wrong Path （WP：不正パス）」などがある。いずれのエラーもテストを突然停止させてしまうことになる。
解決策の1つとして考えられるのは、テストスクリプト1セットと、2つのバージョンのあるアプリケーションをもとに、GUI とスクリプトのなかから齟齬のある部分をすべて自動的に特定し、スクリプトが2.0でも機能するようスクリプトを変更するのを手伝うというものだ。これが REST の仕事だ。
REST は、プログラム分析とアクセシビリティレイヤ（動作中の GUI プログラムの構造と動作に関する豊富な情報を提供する API）を組み合わせることでこの機能を実現する。通常、アクセシビリティレイヤは、さまざまな身体的弱点（視覚／運動障害など）を持つユーザーにサービスを提供するために利用されるが、別のプログラム（この場合は REST）から GUI アプリケーションを分析するためにも利用される。
REST は、アプリケーションの各種メイン画面への遷移をテスト実行者に依存しており、それからアクセシビリティレイヤを使ってこれらの画面の GUI コンポーネントツリーを構築する（ツリーのサンプルとしては、61番のウィンドウにはダイアログボックスが1つあり、そこには6つのボタンとテキストフィールドが1つある、といったものがある）。メイン画面ごとに2つの GUI ツリー（1.0のものと2.0ののもの）の比較が行われる。違いが見つかると、REST は半自動（ある程度テスト実行者の助けが必要）分析を行い、それぞれの不一致が WP エラーなのか CO エラーなのかを判断し、いずれの場合も、影響のあるテストスクリプトをバージョン2.0で機能するよう変更する作業をテスト実行者に指示する。
Comments