Datadogを活用したテスト自動化の取り組み
はじめに
カラクリ株式会社、QAチームのリーダーを務めている芹沢憲二と申します。私の自己紹介はこちらの記事で紹介していますのでご興味ある方はご覧ください。
弊社QAチームでは、開発したプロダクトのリリース前に行うリグレッションテストの自動化（テスト自動化と呼ぶ）を進めています。そして、このテスト自動化にDatadogを活用しています。今回は、弊社で行っている「テスト自動化」の取り組みの一部を紹介します。
少し記事が長くなっていますがご了承ください。
この記事から得られること
弊社のE2Eテスト（UIテストと呼ぶ）の自動化の取り組み事例を知れる
テスト自動化の具体的な内容を知れる（一部を抜粋して紹介）
開発プロセスの概要
テスト自動化のお話の前に、まずは簡単に弊社の開発プロダクトと開発プロセス（開発〜QA）を紹介しておきます。
まずは開発プロダクトについて、弊社ではAIチャットボットシステム「KARAKURI chatbot」をはじめ、FAQサイトの構築〜管理が行えるシステム「KARAKURI smartFAQ」、有人チャットシステム「KARAKURI talk」、お客様の困りごとをAIが予測・自動案内で解決を行うサービス「KARAKURI hello」など、コールセンターのサポートシステム全般の開発を行っています。詳しくは弊社HPをご確認いただけたら幸いです。
次に開発プロセスについて、以下にフロー図で可視化しました。開発プロセスにスコープを絞っているため、関わるチーム以外のことは可視化していません。また、実際にはもっと細かい複数のプロセスが存在しますが、テスト自動化の紹介をするためのものとして詳細は割愛しています。全体感がざっくりわかる程度に可視化しています。ご了承ください。
上述に登場する各チームの主な役割は以下となっています。
箇条書きで簡単に紹介しておきます。
開発チームの役割・作業
スプリントバックログの開発〜ユニットテスト
リリースモジュールの選定（プルリクエストのピックアップ＆レビュー）
リリースバージョンの作成
QAテスト指摘の不具合改修
リリース作業
スプリント活動への参加
スプリントバックログの作成・見積り（スプリントプランニング）
開発したものをメンバーに公開・レビュー（スプリントレビュー）
開発振り返り（スプリントレトロスペクティブ）
QAチームの役割・作業
QAテスト準備（結合〜受入までのテスト設計・準備）
QAテスト実行（結合〜受入テストの実施・不具合改修確認）
QAテスト完了報告
スプリント活動への参加
スプリントバックログの作成・見積り（スプリントプランニング）
開発されたものに対する事前レビュー（スプリントレビュー）
QAテスト振り返り（スプリントレトロスペクティブ）
今回は、このうちQAチームで行ったテスト自動化の紹介をしていきます。
リグレッションテストの課題解決のためにテストを自動化したい
様々な機能が追加・開発されていく中で課題も出てきました。それは、新規機能の追加、既存部分に対する改修、リファクタリングの対応が行われた際のデグレードの検知です。機能が拡張することでシステムも複雑化していくため、開発担当者側で想定していた影響範囲外の箇所でも不具合が起きてしまうことは稀にあり、リグレッションテストを行う以外には防ぎきれないという課題です。これは未然に予測できるものではないため、QAチームとしてはリグレッションテストを定常的に回すしか検知する術がありません。もちろんQAとしてはこのテストプロセスは必要不可欠で、それでもやらなければいけないのがテストです。
また、プロダクトの開発が進む中で既存機能の多くは機能仕様も安定し、これに合わせてリグレッションテストの内容も安定化していきました。定常的なテスト内容も増えていきました。これらのテスト実行には都度テスト工数も掛かりますし、マニュアルでのリグレッションテストの実行はモチベーション的にもつらいものです。
こうして、テスト自動化を考えるようになりました。以下表の赤枠部分です。
テスト自動化検討の背景を整理すると以下です。
プロダクト改修時のテストでデグレードを検知するという課題があった
テスト実施内容が定常化してきたことで機械的なテスト内容が増えてきた
テスト実施範囲の拡張によりテストボリュームが増えてきた
上述に対応するマニュアルテストの負荷が大きくなってきた
定常的なテストやデプロイの都度行うリグレッションテスト（不具合改修によるデグレードがないかのチェック）をマニュアルで実施してもモチベーションが上がらない
テストツールの選定・導入までの進め方
以下の流れで進めました。特に目新しいものはありませんが、参考までに記載しておきます。
テストツールの調査（まずはツール機能の情報収集）
テストツールの利用・トライアル（実際に触ってみる、使い勝手を確認する）
テストツールの選定（どれを採用するかを決める）
テスト自動化の実装・運用開始（テスト自動化を進める）
テストツールの選定基準（期待する要件）
弊社の場合は、以下を考慮して進めました。
安定して動くか（動作不安定など起きないか）
テスト動作は速いか（テストを素早く回せるか）
エラーシューティングは容易か（問題箇所や原因を素早くウォッチできるか）
使いやすいか（ツールの動作は軽いか、機能は豊富か）
運用コストは安いか（コスパは良いか）
ツールの選定（なぜDatadogにしたのか？）
今回は、Autify（Autify for Web）とDatadog（Datadog Synthetic Browser Test）を調査対象にしました。Autify、Datadogのそれぞれを実際に利用し、比較しながら調査を進めました。
この2つのツールを調査対象にした背景について、まずはAutifyですが、過去に使ってきた使い慣れているツールでもあり、KARAKURIのテストにも使えるのではないか、KARAKURIのテストでも使いやすいのではないか、と思い調査対象にしました。
次にDatadogですが、テスト目的でツールの利用を検討したというよりは、もともと開発チームにてKARAKURIのシステムログの統合管理にDatadogを利用しており、このDatadogにテスト機能のサービスがあったため、Datadogで目的のテスト自動化が行えるのではないか、と思い調査対象にしました。また、利用経験が無いため使いやすさがどうなのかを知ってみたいところもありました。
それぞれの調査結果を以下に纏めておきます。あくまで弊社による調査時の結果を可視化したものであり、公式の情報ではないためご留意ください。（2023年1月 現在）
比較表（参考）
※1：エラースクショ画像のエラー発生箇所が赤枠になり把握しやすい
※2：使い方によることは留意（弊社利用の背景に準ずるもの）
※3：モバイルテストは別途契約が必要（追加で費用がかかる）
※4：実行プランのカスタマイズ性が高い（組み合わせが充実している）
※5：要素指定に誤りがないかをその場で確認できる機能がある
※6：UIテストと組み合わせて利用できる（統合テストが可能）
※7：キャプチャ＆リプレイでステップを作成する際のサポート機能がある
※8：サポート窓口がメールのみ
※9：サポート窓口が有人チャットでの問い合わせが可能
※10：ダッシュボードのカスタマイズができる（分析機能も豊富）
※11：別途追加契約が必要（追加で費用がかかる）
※12：複数ユーザーの操作テストを1シナリオ内で実行できる機能がある
このようにそれぞれを調査できました。そして、弊社の場合はDatadogを採用することにしました。Datadogを採用した理由は以下に纏めておきます。
※ちなみに、それぞれのツールはどちらも使いやすく、どちらのツールを利用しても目的のテスト自動化は達成できることがわかったため、決してAutifyがダメというものではないことはご留意ください。例えば、細かい設定が不要なものをテスト自動化する等であれば、Autifyのほうが操作はシンプルですし、わかりやすいところも多いので、コードの知識なく設定したい人とかはAutifyを使うのが良いと思います。
Datadog採用の理由
キャプチャ＆リプレイ機能が直感的で使いやすい。ステップを作成する画面内で、実際の画面にアクセスして操作しながら、行った操作をそのままステップとして組み立てることができる。また、組み立てたステップの編集や、任意のステップ挿入や削除なども気軽に行えて容易であり使いやすい。
1テスト実行のスピードが速い。テスト実行してから結果が返ってくるまでが早い。気軽にテストが行える。弊社目的のテスト自動化内容の範囲ではこの結果が得られたこと。
管理画面上の動作が軽い。例えば、テストステップが増えても動作が重くならず操作ストレスが少ない。「システム動作の重さを考慮してシナリオを組む」ことを意識する必要がない。
動作の不安定さは特に無い。コケやすいテストなどがあれば、スクリプトの組み方次第で十分にカバーできる。上述に記載の使い勝手のとおりで修正が行える。
エラー発生時のアラートやエラーシューティングが容易。エラー発生時はメールやSlackにてアラートを受け取れる。そこからエラー発生箇所のステップにすぐに辿れる。定期リマインド設定もある。
PC, Tablet, Mobileそれぞれのテストが1契約で行える。モバイルだけ別契約などが不要。行いたいテスト環境に合わせたテストを気軽に行える。
HTTPリクエストのテストをUIテストに組み込める。統合テストの自動化が可能。
CSSやXPathで指定した要素の事前チェック機能がある。指定した要素は正しいか？の確認が行えるというもの。
ダッシュボードのカスタマイズができる。目的に合わせてダッシュボードが作れる。
実行回数に応じた課金方式でコストのムダが少ない。また、1テスト実行あたりのコストが安い。あくまで弊社使い方の範囲に準ずるものではあるが。
（上述を達成できるツールでありながら弊社としては）システムのログ管理とテスト自動化の一元管理が行える。
Datadogを利用することにより、目的のテスト自動化を達成できること、ツールの一元管理ができること、目的の使い方の範囲であればツールの利用コストを大きく抑えられることがわかったこと、この3つは上述の中でも主な決め手の理由です。
例えばコスト面では、Datadogの料金体系は以下のようになっており、必要な分を必要に応じて実行することを考えれば安く抑えられることがわかりました。
Browser Testing（機能）：1000テスト毎に12$
1テスト≦25ステップの計算。例えば26〜50ステップなら2テストになる。これが1テストシナリオ実行当たりの[テスト数]になる。
実際の実行では、[テスト数]×[ブラウザ数]×[端末環境数]×[リージョン数]の計算になる。例えば「40ステップのシナリオをTabletのChromeブラウザでテストしたい」場合には以下のようになる。
2(40ステップ) × 1(Chrome) × 1(Tablet) × 1(東京) ＝ 2テスト
詳しくは公式ドキュメントをご参照ください。
実際に使ってみた結果でも、弊社の利用目的・使い方の範囲であれば、Autifyを利用した場合と比較して5分の1から10分の1程度の価格に抑えられることがわかりました。
※あくまで現状の弊社の背景やテスト自動化に対する要求と照らし合わせた場合の結果であることはご留意ください。
ツール導入検討時におけるコストの試算については、テスト自動化の利用目的・範囲・使い方・内容を整理するなど、予めテスト自動化導入の設計を行った上で、これに合わせて「利用した場合の実行コストがどうなのか」を考えて進めることをオススメします。
それと、比較調査によりDatadog利用におけるデメリットもいくつか確認しているため以下に記載しておきます。
Datadog利用のデメリット
問い合わせ窓口のサポートがメールのみ。有人チャットでの問い合わせができない。サポート担当者とのリアルタイムなコミュニケーションによる問い合わせが行えない。
表示言語に日本語がない。アプリ側の機能での日本語化はできない。（Google翻訳機能を活用した利用はできる）
AIによる学習・スクリプト補正の機能はない。スクリプトの修正は全て自ら行う必要がある。
スクリプト作成時のテストシナリオのリプレイ機能がない。ツールに実動作をリプレイさせて、続きからステップを組むといった機能のこと。テスト実行回数としてカウントされずにシナリオを組める便利な機能がAutifyにはあるが、この機能がない。
導入するツールを検討する際の参考になれば幸いです。
具体的なテスト内容
ここでは「具体的にどのようなテストを組んだのか」がわかるように、テストシナリオの中身を紹介します。全ての紹介は難しいため、参考になるものをいくつかピックアップして紹介させていただきます。テスト自動化の範囲・内容の検討時、実装時の参考になったら幸いです。
シナリオ1：システムへのログイン
概要
KARAKURIに登録されているアカウントのみログインができる。ログイン情報が正しい場合にのみログインできることを確認する。一般的な機能のため詳細の説明は割愛。
テストシナリオ（手順）
KARAKURIログイン画面にアクセス
不正なアカウント名とパスワードを設定してログインを実行
アカウント名＆パスワード不正でのログイン（未入力でのログイン）
アカウント名不正でのログイン
パスワード不正でのログイン
正しいアカウント名とパスワードを設定してログインを実行
工夫ポイント
不正なログイン情報の場合はエラーになりログインできないかを確認するテストを取り入れて、正しいログインの場合にのみログインできるかを確認できるようにした。
不正なログインの場合のエラー表示をテストするようにした。
シナリオ2：サーバー設定値の変更（管理用API機能のテスト）
概要
会話カードの管理機能や有人チャット機能を利用するためには、サーバー側で持つ各種機能の制御フラグ（設定値）を変更する必要がある。この制御フラグを予め正しい設定値に変更した上で、各種テストシナリオを実行していく必要がある。
また、この設定を外部から変更することができる管理者向けのAPI（機能）がある。この管理者用APIが正しく使えるか？のテストと合わせて、まずは設定値を変更する。
ちなみに、この管理者用APIを利用するためには正しいトークン（期限付きトークン）を持つ必要がある。この正しいトークンを発行するためのAPI（機能）もある。
テストシナリオ（手順）
正しいトークンをサーバーから取得する（トークン取得用APIの実行）
取得した正しいトークンを利用して管理者用APIを実行（サーバー側設定値を変更）
工夫ポイント
ステップ1で取得した正しいトークンを変数に持たせて、ステップ2で利用する仕組みを取り入れた。（HTTPリクエストテストとUIテストを1シナリオの中で組み合わせることができるという、Datadogの機能を活用した）
シナリオ3：会話カードの新規作成
概要
問い合わせに対するチャットボットの会話には、「会話カード」というボット用のメッセージ管理機能を利用する。この会話カードでは、ボットへの様々な質問に対して「どの様なメッセージを返答させるのか？」のメッセージの流れを組み立てることができる。このメッセージを組み立てるための機能が様々あり、様々なパターンの会話カードを作成することができる。
このメッセージの組み立てに使う各種機能を一通り利用した会話カードを作成することで、各種機能が利用できること、会話カードの作成が行えることをテストする。
また、作成した会話カードがどのように使われるのか（エンドユーザーからどのように見えるのか）を確認するためのプレビュー機能もある。これを活用して、作成が成功したかをテストする。
テストシナリオ（手順）
管理画面にログイン
会話カードの一覧画面を表示
会話カードの新規作成機能から新規作成画面を表示
会話カードの新規作成を行う（各種機能を実行した会話カードを作成）
プレビュー画面で表示を確認（表示内容は正しいか？のテスト）
保存して会話カード一覧を確認（作成した会話カードがいるのか？のテスト）
工夫ポイント
プレビュー機能を活用して、意図した会話カードが作れたかのテストを取り入れた。
保存後に、作成した会話カードが一覧に存在しているのかのテストを取り入れた。
シナリオ4：有人チャット
概要
有人チャットとは、シンプルにはエンドユーザーとオペレーターでチャットが行える機能。エンドユーザーとの直接コミュニケーションを取るための機能。
エンドユーザーによるお問い合わせからオペレーターへの接続、双方向チャット、そして有人チャットの切断までの一連の流れが行えるかをテストする。
テストシナリオ（手順）
ブラウザAで以下を行う
管理画面にオペレーターアカウントでログイン
オペレーターモードをONにする（エンドユーザーの応対が可能な状態にする）
ブラウザBで以下を行う
エンドユーザー画面にアクセス
お問い合わせ用のチャットを行う
オペレーターへの接続を行う（オペレーター接続用の会話カードを実行）
オペレーター接続モードになっているかを確認
ブラウザAで以下を行う
エンドユーザーの問い合わせを受け取る（担当者を当該オペレーターに変更）
エンドユーザーにチャットする
チャット履歴にチャットが表示されているかを確認（オペレーター画面側の送信テスト）
ブラウザBで以下を行う
チャット履歴にオペレーターからのチャットが表示されているかを確認（エンドユーザー画面側の受信テスト）
オペレーターにチャットする
チャット履歴にチャットが表示されているかを確認（エンドユーザー画面側の送信テスト）
有人チャットを終了する
ブラウザAで以下を行う
チャット履歴にエンドユーザーからのチャットが表示されているかを確認（オペレーター画面側の受信テスト）
オペレーターモードをOFFにする（終了する）
工夫ポイント
Subtest機能を活用して、2ブラウザ（別々のセッション）を利用した双方向でのやり取りを行うテストを自動化した。
エンドユーザーとオペレーターが行ったチャットに対し、それぞれの画面での表示確認テストを入れることで、チャットが行えたかどうかをテストした。
オペレーター側としては、業務の開始〜エンドユーザーの応対〜業務の終了まで、一連の流れをテストできるようにした。
エンドユーザー側としては、チャットボット利用によるお問い合わせ〜オペレーターへの接続〜有人チャットの利用〜有人チャットの終了まで、一連の流れをテストできるようにした。
この様にテスト自動化を行っています。
テスト自動化ができなかったこと
逆に、現在のDatadog Synthetic Browser Testの機能ではテスト自動化ができなかったものもあるため、参考に記載しておきます。（2023年1月 現在）
できなかったこと：パスワード変更
概要
パスワードの変更には、パスワードリセットの手続きを行う必要がある。これを行うと、登録されたメールアドレスに仮パスワードを送信する。送信された仮パスワードでログインすることで、新しいパスワードの設定ができ、この設定と合わせてログインができるようになる。
テストシナリオ（手順）
パスワードの変更画面に遷移
メールアドレスを入力してパスワードリセットの操作を実行
届いたメールから仮パスワードを取得
ログイン画面にアクセスして取得した仮パスワードでログイン操作
新しいパスワードを設定してログイン
できなかったこと
手順3で届いたメール本文から仮パスワードを取得すること。
例えば、手順3のメール本文内の文字列から仮パスワード部分を変数に持たせて、これを手順4で利用することができれば良いのだが、この機能がDatadogには無かった。
本シナリオのテストも行える様に、Datadogに機能が追加されることを今後は期待しています。
テスト自動化の状況
現在は以下の様にテスト自動化を進められています。
テスト自動化の進捗も可視化し、管理しながら進めています。
活動の参考になれば幸いです。
※以下のシナリオ名には弊社独自の言語も多いため、具体的にどの様なテストなのかイメージできないものもあるかと思いますが、予めご了承ください。
上述のように、いくつかのシナリオに分割してそれぞれを1シナリオとして作成。作成した各シナリオを順番にスケジュール実行する形で定期テストを行っています。
※CI/CDパイプラインへの組み込みは対応を検討中。https://www.datadoghq.com/ja/blog/datadog-synthetic-ci-cd-testing/
ちなみに弊社では、改修したプロダクトを週次でリリースするサイクルを回しています。そして、この都度リリース前のリグレッションテストを行う必要があり、これを行っています。
上述のテストを全てマニュアルテストで実施すると、実際には4〜5人日/週の工数がかかっていました。このテスト対象・範囲を完全にテスト自動化しました。1人月分のテスト作業を自動化できているというものです。
そして、テスト自動化を進めたことで、新規機能や機能改修部分のテストに以前よりも注力できるようになっており、QAテストの視点でより細かいところに目を向けたり、テスト観点の思考・導出に時間を割いたテストが行えています。テスト品質の向上も実感できています。
また、上述以外にもテスト自動化したいものは随時増え続けています。
引き続きテスト自動化を進めて行こうと思います。
テスト自動化の成果事例
テスト自動化を進めてみたことで、あるタイミングのバージョンでデグレードの不具合を検知することができました。内容としては「会話カードの新規作成フローにて、画像を添付した会話カードの作成ができない（画像の追加が行えない）」といった不具合です。
これは会話カード作成における基本機能の1つなのですが、この不具合を見つけるためには、会話カードの作成で様々なパターンの会話カードを作成して見る必要があります。つまり、使い方の組み合わせは除くにしても、一通りの機能を利用してカードを作成してみるといったテストが必要です。それぞれの種類の機能を呼び出すだけでも約15パターンの種類が存在し、実際のテストステップ数で言えば約120ステップのテストを行う必要がありました。
またこの不具合事象は、当時の改修内容の影響範囲としては想定していなかった箇所での不具合発生でした。まさに、リグレッションテストを行ったことで防げた不具合になります。
もしも、このテストを行っておらず見逃してリリースしてしまっていたら、お客様からの不具合報告やクレームに繋がっていたでしょう。これをテスト自動化により手間をかけずに検知できたというものです。テスト自動化の成果、成功を体験できたものでした。
テスト自動化の良さが伝わればと思い、成果事例のお話も書かせていただきました。
このようにテスト自動化の取り組みにより、テストを少しでも楽しく、正しく行うことができています。マニュアルテストの負荷も減らせています。
いかがでしたでしょうか。
以上、テスト自動化の取り組みの紹介でした。
まとめ
行ったこと
リグレッションテスト領域の課題やテスト内容の安定化に合わせてテスト自動化を検討した
テストツールの選定・導入に向けてツールの比較調査を進めた
Datadog Synthetic Browser Testを活用したテスト自動化を進めた
達成できたこと
弊社背景にマッチする良いテストツールを導入できた
テスト自動化をうまく進めることができている（現在進行系）
紹介したこと
弊社開発プロダクトと開発プロセスの概要を紹介
テスト自動化の進め方を紹介
具体的なテスト自動化内容の一部を紹介
テスト自動化の進捗状況を報告
以上で今回の記事は終わりにしたいと思います。
「これからテスト自動化を検討している」「テスト自動化は既に対応済みだが見直しを考えている」といった方にとって、本記事が参考になれば幸いです。
最後までお読みいただきありがとうございました。
以上
この記事が気に入ったらサポートをしてみませんか？