はじめに
ServiceNowのAutomated Test Framework（ATF）は、テストを自動化する強力なツールですが、作るのがかなり面倒な印象があり、とっつきづらいです。
イベントやセミナーでATFの話を聞いてその場では感心するのですが、会社に戻っていざ作ってみようとすると何一つまともなものが作れない。それがATFです。
ATFにはイヤなところがいっぱいあります。
ATFのイヤなところ
- 作るのが大変そう
- パーツの選択肢が多くて何を選択したらちゃんと動くかわからない
- OOTBのテストを見ても、クイックテストを見てもさっぱりわからない
- 開発するのと同じくらい手間がかかりそう
- 開発物を変更したら毎回直さないといけない
あまりにも好きになれないので、イベントで「メジャーアップグレードの時にATFのパッケージ自体が正しく動いているかだれが確認するんですか。ATFが壊れたせいでテストが成功しているかもしれないじゃないですか」みたいなことを言ったら、ServiceNow社の方もイベントに参加した方も、全員 口がへの字になって変な空気になりました。
私は、それくらいATFに否定的でした。
パーツの選択は本当に訳が分からない
以下がおなじみのカオスなパーツ選択画面です。
最初のステップでCreate a UserやImpersonateが必要な意味が分からない。レコードの作成も、SPがあったりなかったりするので思った通りに作れない。最初の選択で結構つまづきます。
じゃあ、RPA使う？
そんなにATFが作りづらいのであれば、「別のRPA製品を使ったらいいのでは？」という思いもありました。
しかし、ポータルでの申請はRPAで作りやすいのですが、プラットフォーム画面ではNext Experience（Poralis UI）とRPA製品の相性が悪すぎて、UIの要素を上手に掴めない。という問題がありました。また、たくさんテストを作っても、また新しいUIが誕生したらすべて作り直しになるのでそれもまた工数がかかるな。と思い諦めました。
シンプルに考えようATF：実はよく使うパーツを覚えたらあとは楽になる
ServiceNowとかかわってから5年間も避け続けてきたATFといよいよ向き合おうと思いました。お客様から今まで以上に品質を求められることが増えてきましたし、アップグレードの手間も省きたい。そんな思いが強くなってきたからです。
イヤなところばかり言っててもしょうがないので、どうやったらハードルを下げられるか。それを考えてみました。最初は大変ですがいろいろ試行錯誤する中で基本は次の４つパーツの繰り返しでうまく作れることが分かりました。みんな、なぜこれを教えてくれなかったんだろう。
ATFのテスト構成は「探す → 開く → 更新する → 確認する」
これだけです。
前後にちょっとした処理はありますが、ポータル操作でもプラットフォーム操作でもこの４つの繰り返しを覚えれば、たいていのことはできてしまいます。あのたくさんのパーツの選択肢を頭の中でポータル４つ、プラットフォーム４つの合計８つしか使わない。 そう思えばだいぶATFのハードルが下がります。
ネットでATFの記事を探しても、テストスイートとテストの関係性や最初の起動部分とかの概念の話が多くて、実際に仕事で使おうと思ったら、レコードのクローズまでをどう操作したらいいか。 というのはあまりありませんでした。それもATFが浸透しない理由だと思います。
ポータル操作とプラットフォーム操作で使うパーツ群は違いますが、やっていることは同じです。
ポータル操作
| カテゴリ | ステップ名 | 使用タイミング | 説明・ポイント |
|---|---|---|---|
| 初期登録 | Impersonate | テストの開始時に特定のユーザーとして操作する | 指定したユーザーとして操作を行う。手前に新規ユーザー作成にするか既存のユーザーを選択するかは要検討。実在するユーザーの方がエラーを発見しやすいかもしれない |
| 開く | Open a Catalog Item (SP) | カタログアイテムを開く | Service Portalでカタログアイテム（例: Apple iPhone 13）を開き、フォーム入力の準備を行うステップ。 |
| 更新する | Set Variable Values (SP) | フォームへの入力値を設定する | カタログアイテムのフォームに対して、ユーザーの入力値を設定する。入力後にUIポリシーなどで後続のフォームが変わる場合は、レコードを分ける。 |
| 確認する | Validate Variable Values (SP) | 入力した値を確認する | フォームに入力した値が正しいかを確認する。これがないと、入力だけうまくいって値が正しいかはわからないのでテストのエラーが発見できないことがある |
| 更新する | Order a Catalog Item (SP) | カタログアイテムのリクエスト送信時 | 設定した値でカタログアイテムをサブミットする。 |
プラットフォーム操作
| カテゴリ | ステップ名 | 使用タイミング | 説明・ポイント |
|---|---|---|---|
| 探す | Record Query | レコードの検索 | 対象レコードを探す。基本は1つ前のステップのレコードを探す |
| 開く | Open an Existing Record | 見つかったレコードを開く | 検索で取得したレコード（例: リクエストアイテム、承認レコード、カタログタスクなど）の詳細画面を開く。 |
| 更新する | Record Update | レコードの更新 | 取得したレコードに対し、ワークフローに応じた更新操作を行う。たとえば、ワークノートの追加やステータスの変更。 |
| 確認する | Record Validation | レコードの値を確認する | 更新後のレコードが期待される値を持っているか確認する。これがないと、入力だけうまくいって値が正しいかはわからないのでテストのエラーが発見できないことがある |
| 更新する | Click a UI Action | UI上で特定の操作ボタンをクリックする場合 | UI上の「承認」などのボタンをクリックする。 |
図解：ポータルから申請してワークフローを回してレコードをクローズするまでの流れ
よくあるワークフローを例に、処理の流れを見ていきます。もちろんほかにもするべき操作はいっぱいありますが、これを覚えるだけで他のことにも応用が利くはずなので、基本を覚えましょう。
▼ ServiceNowでよくある操作
1) おまじない（ユーザー指定）
2) ポータルの申請
3) リクエストアイテムを開く（受付しました）
4) 承認をする（承認しました）
5) カタログタスクをクローズする（作業をしました）
6) RITEM,REQがそれぞれクローズしたことを確認する（完了しました）
大きく6つの流れがありますが、それぞれの内側で、「探す → 開く → 更新する → 確認する」 を繰り返しているだけです。とてもシンプル。
改めて考えたATFのいいところ
イヤがり続けたATFですが、ちゃんと作ってみるといいところも見えてきました。なかなか愛着も出てきます。
- テストをしたゴミレコードが残らない（ログは残るので後からチェックはできる）
- スクショを撮り続けてくれる（フルサイズでとれる）
- UIが変更したらUIを指定しなおせばいいだけで直せる
- テストはコピーできる
- RPAと違って一度うまく動いてしまえばタイミングで空振りすることがない。とても堅牢
- スケジュールでずっと回しておけるので、予期せぬ不具合を検知できる
- 「1つ前のレコードに対してｘｘをする」という指定が楽にできる。RPAで特定のレコードを探すのは大変
なんだ、いいところがいっぱいあるじゃないか。
おわりに
今回は、概念についてお伝えしましたが、今後は各パーツの1つずつの具体的な設定について書いていきたいと思います。
そして、あまりネットの記事にないATFのテスト自体を自動作成する「Test Generator」についても書いていきたいと思います。ご期待くださいませ。
世界中のServiceNowエンジニアがメジャーアップグレードのテストや日々の開発でのテストの苦しさから解放されて、楽しく開発できることを心から祈っています。
- 続きはこちら -