ServiceNowのAutomated Test Framework（ATF）は、設定変更やアプリケーション開発、アップグレードの後に「従来どおり動くか」を繰り返し確認するための自動テスト機能です。この記事では、ATFのテストを作成し、ステップを追加して実行する基本操作から、ロールバックの範囲、Service Portal、Run Server Side Script、Cloud Runner、Test Generatorの使い分けまでを、実務で事故を起こさない順番で整理します。
ServiceNow ATFとは何か
ATFは、ServiceNowインスタンス上の機能を対象に、レコード作成、フォーム操作、条件検証、Service Catalogの注文、REST処理、サーバーサイド処理などを一連のテストステップとして実行する仕組みです。手作業の確認を完全になくす道具ではなく、毎回同じ条件で繰り返す回帰テストを自動化し、人が確認すべき例外や設計判断へ時間を振り向けるために使います。
公式ドキュメントでは、変更したインスタンスがアップグレード後、アプリケーション開発中、Update Setによる構成配備後にも動作するかを確認する用途が示されています。テストを一度設計して終わりではありません。対象フォームや業務ルールを変更したらテスト側も更新し、現在の要件を表す回帰テストとして保守します。
最初に覚える結論
- ATFを実行するのは非本番環境です。本番でテストを回す前提にしません。
- テストは「準備→操作→検証」の順に作ります。操作だけで終わるテストは、成功条件を判定できません。
- テストデータのロールバックは万能ではありません。除外テーブルやインスタンス外部の副作用を別途確認します。
- 標準ステップを優先します。Run Server Side Scriptは、標準ステップで表現できないサーバー側検証に限定します。
ATFを使い始める前の準備
非本番インスタンスでテスト実行を有効にする
ATFのテスト実行プロパティは、誤って本番で実行しないよう既定で無効です。開発・テストなどの非本番インスタンスで、All > Automated Test Framework > Administration > Propertiesを開き、Enable test/test suite executionを有効にします。Run Testボタンが見えないときは、ロールだけでなく、この実行プロパティを最初に確認してください。
テストの作成には、公式手順上ではatf_test_adminまたはatf_test_designerが必要です。テスト実行では、テストの種類や管理操作に応じてadmin、atf_test_admin、atf_test_designerが関わります。開発者全員へadminを配るのではなく、設計・実行・管理の責務に合わせて最小権限に分けます。
何を自動化し、何を人が確認するかを決める
「ATFを導入する」こと自体を目的にすると、保守されない大量のテストが残ります。先に対象業務の重要経路を選びます。たとえば、インシデント起票時に優先度が期待どおり決まる、カタログ申請からRITMが作成される、対象ロールを持つユーザーだけがレコードを更新できる、といった業務上の結果です。色や余白などの視覚的な細部をすべてATFで網羅するより、業務停止や権限制御の事故につながる経路から作る方が効果的です。
ATFテストの作り方を5段階で理解する
1. Testsからテストレコードを作成する
All > Automated Test Framework > Testsを開いてNewを選び、NameとDescriptionを入力して保存します。名前は「Incident Priority」のような機能名だけでなく、「Incident｜Impact 1・Urgency 1でPriority 1になる」のように、対象と期待結果を読める形にすると、失敗結果から直すべき業務経路を判断しやすくなります。
同じ操作を複数データで反復する場合は、Parameterized testingも候補です。ただし最初から共通化しすぎると、失敗時にどの条件が原因か読みづらくなります。まず代表条件で一本を完成させ、重複が見えてからデータセット化します。
2. Test Stepsに準備・操作・検証を追加する
テストフォーム下部のTest Steps関連リストでAdd Test Stepを選びます。Add Test Step画面では、Form、Application Navigator、Server、Service Catalog、RESTなどのカテゴリ、またはAll Stepsから目的のステップを探せます。フォームを操作するテストでは、Open a new formまたはOpen an existing formから始め、Set Field Values、Submit a form、その結果を確かめる検証ステップへつなぎます。
多くのステップは出力値を返します。たとえば作成したレコードのsys_idを次のステップへ渡せば、固定された既存レコードへ依存せず、自分で準備したデータだけで検証できます。この設計にすると、環境ごとの差や別テストの実行順による失敗を減らせます。
3. 検証ステップを必ず置く
フォームを送信できたことと、業務要件を満たしたことは同じではありません。Priorityが期待値になったか、Assignment groupが設定されたか、権限のないユーザーでは更新できないかなど、結果を明示的に検証します。サーバー側のレコード検証にはRecord Validation、UI上の値にはフォーム向け検証ステップなど、対象に合う標準ステップを選びます。
一つのステップで多数の条件を確認すると、失敗時の原因が分かりにくくなります。重要な期待結果は分けておくと、結果一覧を見ただけで「作成に失敗」「値が不一致」「権限で失敗」を切り分けられます。
4. Run Testで実行する
テストフォームのRun Testを選びます。サーバーステップだけならブラウザ選択なしで実行されます。フォームなどのUIステップを含む場合はPick a Browserが表示され、既存のClient Test Runnerを選ぶか、新しいrunnerを開始します。実行中は進捗を確認し、完了後にGo to ResultsからTest Resultsと各Step Resultを読みます。
UIテストをローカルのClient Test Runnerで回す場合、ブラウザのCPU抑制に注意します。公式の推奨では、runnerを独立したウィンドウで開き、画面上で一部が見える状態を保ち、画面ロックやスリープを避けます。「設定は正しいのに待機で失敗する」ときは、対象画面だけでなくrunner側の実行状態も確認します。
5. Test Resultsは最初の失敗から読む
後続ステップの失敗は、前段で必要なレコードを作れなかった結果かもしれません。最後の赤い行だけでなく、最初に失敗したステップ、その入力値、実際値、スクリーンショット、クライアントエラーを確認します。意図した失敗をテストしている場合は、失敗が成功条件になるassert typeもあります。単に全行を緑にするのではなく、要件に対して正しい判定になっているかを読みます。
ATFのrollbackで戻るもの・戻らないもの
ATFはテスト実行によって作成・変更されたデータを追跡し、テスト完了後にロールバックします。Run Server Side Scriptで作ったレコードも、追跡対象であれば全ステップの完了後に戻されます。デバッグ時にはPause before rollbackを使い、ロールバック直前で一時停止して作成データを確認できます。
ただし、ATFのrollbackを「インスタンス全体が実行前のスナップショットへ戻る」と理解してはいけません。公式には追跡・ロールバックから除外されるテーブルがあります。代表例はECC Queue ecc_queue、Email sys_email、Email Log sys_email_log、History sys_history_line、Number Counter sys_number_counter、各種ログや実行追跡テーブルです。除外テーブルを継承するテーブルや、特定の接頭辞を持つテーブルも対象外です。
さらに、外部APIへ送った要求、外部メール配送、MID Serverの先にある処理など、インスタンス外で発生した副作用をATFのデータロールバックが取り消すわけではありません。統合テストではモック先やテスト用エンドポイントを用意し、実サービスへの書き込みを避けます。番号カウンタも除外されるため、テスト後に番号が飛んでいても「ロールバック失敗」とは限りません。
| 対象 | 基本的な扱い | 設計上の注意 |
|---|---|---|
| テストが作成した通常レコード | ATFが追跡し、完了後にロールバック | 固定既存データより、テスト自身で作るデータを優先 |
| 除外テーブルのレコード | 追跡・ロールバックされない | 公式の除外テーブル一覧を確認し、清掃手順を別に持つ |
| 外部システムの副作用 | ATFのインスタンス内rollbackの範囲外 | テスト用接続先、スタブ、送信抑止を使う |
| 失敗・キャンセル時 | 実行中に作った追跡対象データはロールバックされる | 例外対象と外部副作用は別途確認 |
Run Server Side Scriptはいつ使うか
ServerカテゴリのRun Server Side Scriptは、サーバー上でJavaScriptを実行するステップです。Jasmineを使った検証、Business RuleやScript Includeの細かな結果確認、標準ステップでは表現しにくいデータ準備などに使えます。前段ステップの出力値はsteps(SYS_ID)で参照でき、スクリプトから後続ステップへrecord_idやtableを出力できます。
便利だからといって、レコード作成・検索・値検証をすべてスクリプトへ集約するのは避けます。標準ステップなら、入力と期待結果をフォーム上で読み取れ、非開発者も保守しやすいためです。Run Server Side Scriptは「標準ステップで表現できないロジック」または「サーバー側単体テスト」に限定し、何を準備し、何をassertするかをNotesへ残します。
新規のJasmineスクリプトでは、公式リファレンスに示される対応バージョンを確認します。既存テストの古いJasmineを無計画に一括変更せず、対象リリースでの互換性と結果をテスト単位で確認します。また、スコープによって使える構文やAPIが異なるため、Application欄もテスト対象と揃えます。
Service Portalのカタログ申請をATFでテストする
Service Portal上のCatalog ItemやRecord Producerを確認する場合は、Service Catalog in Service Portalカテゴリのステップを使います。Open a Catalog Item (SP)、変数値の設定、注文、生成された要求の確認というように、利用者の導線に沿って組み立てます。標準Service Catalog向けのカテゴリとService Portal向けカテゴリを混同しないことが重要です。
公式資料では、Service Portal向けステップにAutomated Test Framework Service Catalog Service Portalプラグイン（com.glide.automated_testing_impl.service_catalog_portal）が必要とされています。新しいインスタンスでは既定で有効でも、以前からアップグレードしてきた環境では管理者による有効化が必要な場合があります。対象ステップが見つからないときは、テストの作り方を疑う前にプラグイン状態を確認します。
Service PortalのUIテストでは、申請画面が開いたことだけで終わらせず、注文後にREQ・RITM・SCTASKのどこまで生成されるのかをサーバー側ステップで確認すると、表示とデータの両方を検証できます。UIステップで取得した出力を後続ステップへ渡し、固定番号に依存しない設計にします。
Cloud RunnerとTest Generatorの使い分け
Cloud Runnerはテストをクラウド上のブラウザで実行する
Cloud Runnerは、ServiceNowがホストするheadless browserでATFテストを実行する選択肢です。ローカルのClient Test Runnerを開き続けなくてよいため、定期実行や多数のUIテストに向きます。ただしATF本体だけで常に使える機能ではなく、ATF Test Generator and Cloud RunnerのStoreアプリ、cloud userの設定、対象環境の対応条件が必要です。
公式手順では、テストまたはATF Generated SuiteのRun画面でPick a Browserを開き、Cloud Runnerを選択します。Cloud Runnerでsuiteを実行すると、suite内テストは並列で動き、実行順はランダムになり、suiteのexecution orderとabort on failureは無視されます。したがって「前のテストが作ったデータを次のテストが使う」構成は不安定です。各テストが自分のデータを準備し、単独・任意順で通るようにします。
ATF Test Generatorは候補テストを生成する
ATF Test Generatorは、インスタンスの動作やワークフローを分析して回帰テストを生成し、既存ATFへつなぐStoreアプリ側の機能です。公式手順ではadminでAll > Automated Test Framework (ATF) > Administration > Test Generatorを開きます。生成中の処理はBrowser Orchestration Queueでも確認できます。
生成されたテストは、そのまま品質保証の最終成果物になるわけではありません。自社の期待結果、権限境界、使用データ、外部副作用を人がレビューし、不要なステップを減らして検証条件を具体化します。また、似た名前のNow Assist for Creatorの「Test generation」は別機能です。Australiaリリースの公式情報では、このTest generationは将来の廃止に向けた準備対象と案内されています。機能名だけで同一視せず、導入しているアプリとリリースを確認してください。
保守しやすいATFテストのベストプラクティス
うまく動かないときの確認順
| 症状 | 最初に見る場所 | 次の判断 |
|---|---|---|
| Run Testが表示されない | ATF Propertiesの実行許可、利用者ロール | 非本番であることを確認して有効化 |
| UIステップだけ待機・失敗する | Client Test Runner、ブラウザ表示、画面ロック | runnerを別窓で可視状態にし、対象UI変更も確認 |
| テスト後にデータが残る | 公式のrollback除外テーブル一覧 | 除外対象なら専用の清掃・送信抑止を設計 |
| Service Portalステップがない | 対象プラグインとステップカテゴリ | 標準Catalog用ステップとの混同を解消 |
| Cloud Runnerが選べない | Storeアプリ、cloud user、環境対応条件、表示プロパティ | ローカルrunnerとの機能差を確認 |
| 単独では通るがsuiteで落ちる | 共有データと実行順依存 | 各テストで準備・後片付けし、任意順で通す |
CAD学習でATFをどう押さえるか
CAD対策では、ATFの画面名だけでなく「どの層を、どのステップで検証するか」を整理します。フォーム操作はUI・Form系、レコード値はServer系、外部I/FはREST系、カタログは標準UIかService Portalかを問題文から切り分けます。ロールバックについては「テストデータは原則戻る」だけで止めず、除外テーブルと外部副作用が残ることまで説明できるようにします。
学習順に迷う場合は、ServiceNow CAD対策ハブで試験範囲とPDI演習の配分を確認してください。実装場所の選び分けが曖昧なら、ServiceNow CAD完全ガイドでClient Script、Business Rule、Flow Designerの責務を整理できます。理解確認にはServiceNow CAD無料模試・特化演習464問を使い、正解番号ではなく「標準ステップを選ぶ理由」「rollbackの例外」「runnerの違い」を言葉で説明できるかを確認します。
理解確認ミニ問題
問題1
ATFで作成した通常のテストレコードが実行後に消えました。最も適切な説明はどれですか。
- ATFが追跡対象のテストデータを完了後にロールバックした
- Cloud Runnerがすべてのテーブルを初期化した
- Update Setがテストデータを削除した
- Client Test Runnerがブラウザキャッシュを削除した
正解：A。ATFは追跡対象のテストデータをロールバックします。ただし除外テーブルや外部副作用まで必ず元に戻るわけではありません。
問題2
Cloud Runnerでsuiteを実行する設計として、最も安全なのはどれですか。
- テストAが作った共有データを、必ず次に動くテストBが利用する
- execution orderだけを根拠に、テスト間の依存関係を作る
- 各テストが必要データを自分で作り、任意順・並列でも通るようにする
- 最初の失敗でsuite全体が必ず停止する前提にする
正解：C。Cloud Runnerのsuite実行ではテストが並列で動き、順序がランダムになるため、テスト間依存を避けます。
よくある質問
ATFは本番環境で実行してもよいですか
推奨されません。公式ドキュメントは、データ破損や停止を避けるため開発・テストなどの非本番インスタンスだけで実行するよう明記しています。実行プロパティも既定で無効です。
ATFのテストデータは必ずrollbackされますか
通常の追跡対象データはテスト完了後にロールバックされますが、ECC Queue、Email、Email Log、History、Number Counterなどの除外テーブルと、その継承テーブルや特定接頭辞のテーブルは対象外です。外部システムで起きた副作用も別途対策が必要です。
Run Server Side Scriptだけでテストを作ってもよいですか
技術的に可能な場面はありますが、標準ステップで表現できる作成・操作・検証まで一つのスクリプトへ隠すと保守性が下がります。標準ステップを優先し、複雑なサーバーロジックやJasmineによる検証に限定するのが安全です。
Cloud RunnerとClient Test Runnerの違いは何ですか
Client Test Runnerは利用者側のデスクトップブラウザを使います。Cloud RunnerはServiceNowがホストするheadless browserで実行し、ローカルブラウザを開き続ける負担を減らします。Cloud RunnerにはStoreアプリ、cloud user設定、環境条件があり、suiteの並列・ランダム実行にも注意が必要です。
Service PortalのCatalog ItemもATFでテストできますか
できます。Service Catalog in Service Portalカテゴリの専用ステップを使います。対応プラグインの有効化が必要で、アップグレードしてきた環境では管理者による確認が必要な場合があります。
まとめ
ServiceNow ATFは、非本番環境で重要な業務経路を繰り返し検証するための仕組みです。最初は、テスト自身がデータを準備し、標準ステップで操作し、期待結果を明示的に検証する短いテストから始めます。ロールバックの除外対象、Service Portal用ステップ、Run Server Side Scriptの使い所、Cloud Runnerの並列性を理解すれば、アップグレードや開発変更に耐えるテストへ育てられます。
公式確認先
- Getting started with the Automated Test Framework
- Create a new automated test
- Add steps to an automated test
- Enable or disable executing ATF tests
- Tables excluded from rollback
- Server category / Run Server Side Script
- Service Catalog in Service Portal category
- ATF Test Generator and Cloud Runner
- Executing tests using Cloud Runner
