こんにちは。
最近、ServiceNowのAutomated Test Framework(ATF)を使用する機会があったので、その際に学んだことのご紹介となります。
ATFとは
ATFはServiceNowのインスタンス上で自動テストを作成・実行することが可能なツールです。
新しい機能を開発、リリースした時、インスタンスアップグレード後のリグレッションテスト時などで使用できます。
ATFには以下のような特徴、メリットがあります。
- マニュアルで行っていたテストを自動化することによる生産性向上(テスト実行のスケジューリングも可能!)
- ローコード・ノーコードでテストを作成できるため、高度な開発技術が不要
- テスト中に作成されたデータや設定変更はテスト終了後にロールバックされるため、インスタンスがクリーンな状態に保たれる
ATFのコンポーネント
代表的なコンポーネントをいくつか記載します。
Test
後述するTest Stepをグルーピングするものとなります。
テストを実行する最小の単位であり、テスト対象となる1つ1つ機能や業務フローごとにTestを作成していくイメージとなります。
Test Step/Step Configuration
Step Configurationは、ユーザーに成り代わる、メニューにアクセスする、フォームを開く、などの単一のアクションになります。OOTBで多くのアクションが用意されています。
そしてTest Stepではこれらのアクションを使用して、テスト項目の動作確認をするための1つ1つのステップ詳細を定義していきます。
例えば「Impersonate」というユーザーに成り代わる動作を行うことができるStep Comfigurationを使用する場合、どのユーザーに成り代わるのかをTest Stepで指定します。
たくさんのStep ConfigurationがOOTBで用意されていますが、個人的によく使用したものをいくつか紹介します。
Create a User | 特定のグループ、ロールを持ったユーザーを作成します。作成したユーザーでそのまま代理操作することも可能です。 各ペルソナの権限で動作確認したい場合などに使用します。 |
Open a New Form / Set Field Values / Submit a Form | 3つを一緒に使用することで、「フォームを開く」「フィールドに値を入力する」「フォームをサブミット」するという一連の動作を再現することができます。 |
Order Catalog Item | カタログアイテムをオーダーすることができます。 |
Record Validation | レコードのフィールドの値が特定の条件を満たしているかを検証します。 Business ruleやScheduled Jobによる処理、ユーザーの操作などにより、フィールドの値が想定通りに更新されているか確認できます。 |
Test Suite
複数のTestをグルーピングしたものとなります。
Test Suiteを実行することで、紐づく全てのTestが自動で実行されます。そのため、ペルソナごと、業務内容ごとなどの切り口でTestをTest Suiteに紐づけグループ化することで、管理しやすくなります。
また、Test Suite内で各Testの実行順序を定義したり、Test Suiteを自動で実行するためのスケジュール設定も可能です。
例:全体の構成は以下のようなイメージとなります。
Test Suite
システム運用者の運用業務
Test
①問題レコードを起票する
②変更レコードを起票する
③インシデントレコードを起票する
(Test③に対する)Test Step/Step Configuration
①システム運用者のアカウントに代理操作する
②インシデントフォームを開く
③各項目を入力する
④フォームをサブミットする
ATFを使ってみる
以前作成した「User Registration Request」を使用して、①カタログアイテムをオーダーする、②部門長が承認する、③ユーザーが自動で作成される、というプロセスをATFで自動テストしてみます。詳細は以下記事をご参照ください。
その際、成功・失敗時のATFの動作を確認するため、以下2パターンでATFを実行します。
成功パターン
ロールを持たない一般ユーザーで「User Registration Request」を申請する。
失敗パターン
「User Registration Request」を申請できる権限を「user_admin」に制限する。
ロールを持たない一般ユーザーで操作しようとしたが、権限が足りず申請することができない。
テストの作成
Automated Test Framework (ATF) > Testメニューから新規にTestを作成します。
その後、「Add Test Step」をクリックし、Test Stepを追加していきます。
追加したTest Stepは以下の通りとなります。
各ステップで行っていることは以下の通りとなります。
①Creat a User | 「User Registration Request」をオーダーするユーザーを作成して代理操作する。 この時、ユーザーの所属部署を「IT」に設定する。(=承認はIT部門長に設定したユーザー宛てに依頼される) |
②Open a Catalog Item | カタログアイテム「User Registration Request」を開く。 ※操作しているユーザーの権限が不足している場合、エラーとなる。 |
③Set Variable Value | 「User Registration Request」の各項目を入力する。 |
④Order Catalog Item | 「User Registration Request」をオーダーする。 |
⑤Record Query | リクエストアイテムが作成されていることを確認する。 |
⑥Record Query | IT部門長宛てに承認レコードが作成されていることを確認する。 |
⑦Impersonate | IT部門長のユーザーアカウントに代理操作する。 |
⑧Open an Existing Record | 自分宛ての承認レコードを開く。 |
⑨Click UI Action | UIアクション「Approve」をクリックして承認する |
⑩Record Query | ユーザーテーブルをクエリし、申請通りにユーザーが作成されていることを確認する。 |
Test Stepを追加していく際、各Test Stepのアウトプットは後続のTest Stepで利用することができます。
④⑤のステップを例に説明すると、、
④のOrder Catalog Itemではアウトプットとして、「Request」レコードが作成されます。
そして、⑤ではRequest Itemテーブルをクエリしていますが、クエリ条件に前ステップ④のアウトプットを使用しています。
設定は、画面上でポチポチするだけで完了します。
各ステップの詳細な設定手順は省きますが、基本ローコード/ノーコードで操作できるため、簡単に作成することができました。
テストの実行
「Run Test」をクリックし、テストを実行します。
テスト実行中は、以下の画面のようにテストの進捗を確認することができます。
テストの実行が完了しました。
「Go to Result」をクリックします。
Test Resultの画面では、各Test Stepごとの実行結果が確認できます。
また、画面操作などクライアント側のテストを実行した場合は、自動で画面のスクリーンショットを取得して添付してくれます。
次にテストが失敗した場合の動作を確認していきます。
「User Registration Request」をオーダーできる権限を「user_admin」に設定したうえでテストを実行します。
結果を確認すると、Test Step②のOpen a Catalog Itemでテストが失敗しています。
最初のステップで作成したユーザーが何も権限を持っていなく、「User Registration Request」を開けない為、失敗になったことが分かります。
感想
ATFを活用することで、テストに要する時間を大幅に削減することができると感じました。
また、アップグレードや新規機能リリース時、意図せぬ変更が行われていた場合の既存機能への影響検知に役立ちます。
今回は基本機能の一部分を紹介しましたが、他にも便利機能が多く用意されているので、引き続き勉強してアウトプットしていきたいと思います。