本記事では「MagicPodの活用状況」と題して、MagicPodを利用している各チームの方へのインタビューをお届けします。

DialogPlayのプロダクトチームからスクラムマスター森さん、エンジニア山田さんにMagicPodの具体的な活用事例や工夫ポイントなど、お話を伺いました。

MPintervew thumbnail1

MagicPodの利用推進 施策について

TISでは2023年からMagicPodの利用を開始し、全社のE2Eテスト自動化比率UPを目標に社内の利用推進を進めています。

MagicPodは、株式会社MagicPodが提供するモバイルアプリテスト、ブラウザ(ウェブアプリ)テストの両方に対応したAIテスト自動化クラウドサービスです。豊富な機能と高いメンテナンス性でリリースサイクルの高速化を支援します。

現在、社内では6件のプロジェクトにMagicPodを導入しています。

他チームの活用事例は以下をご覧ください。

Sales Driveの安定リリースを支える自動テスト:MagicPodの活用状況

AI搭載型チャットボット作成サービス:DialogPlay® について

DialogPlayはWebサイトやメッセージングアプリ上で動作する、ユーザーの「困った」を理解してくれる業務チャットボットアプリケーションを提供するSaaS型サービスです。DialogPlayはTISが開発したチャットボットで、「他システム連携」や「お客様からの要望による機能アップデート」など、ご提案が可能です。

DaialogPlay

DialogPlay ブランドサイトはこちら

インタビュー

サマリ

  • 別のテストツールから1人の担当が約3週間で移行
  • これまでと比べて、自動テストが安定稼働。作業時間の大幅短縮に
  • 必要な機能が充実しており、効率的なテストケース作成を実現

MagicPod導入の経緯

―MagicPodの利用のきっかけはなんでしたか?

森:元々、MagicPodでない別のテスト自動化ツールを利用して自動テストを組んでいました。そのサービスが提供終了にあたり切り替え先のツールを探していたところ、社内でMagicPodを紹介されて導入することに決めました。2023年8月から本格導入開始しました。

チーム体制

―どのような体制で開発されていますか?

森:私が所属しているDialogPlayチームはエンジニアが専属で2名、兼任でさらに1~2名が稼働しています。その体制で6~8週間のリリースサイクルで動いています。

―品質保証のプロセス全体について教えてください。

森:スクラムのプロセスをとっており、リリーススプリントを明確に設けています。リリース前2週間をリリーススプリントとし、テスト環境・ステージング環境でのテストを実施しています。

  • 1週目:つくるものを決める
  • 2週目〜4週目:バックログを消化しながらバックログ単位の受け入れ基準も段階的に明確化
  • 5週目〜6週目:リリースサイクル – リリースするためのテストなど諸々

テスト工程の管理には、TestLinkというツールを使用しています。

基本的には開発担当者がチケットの受け入れ基準に基づきテストを行います。

チケットの受け入れ基準=テストケースとなっており、受け入れ基準は要素の配置・文言レベルまで詳細化しています。受け入れ基準は開発を進めながら段階的に詳細化していきます。

リリーススプリントでは、ステージング環境で担当者以外が担当し第三者目線でチェックします。実装者が見抜けないポイントを他のひとがテストを組んで不具合発見効率を高めるねらいがあります。

MagicPodは、テスト環境、本番環境でそれぞれ利用しています。(各環境のテスト内容は後述)

環境の分類 説明 MagicPod利用対象
個人環境 開発者個人ごとの動作確認環境。EC2インスタンス1つのみで完結する簡易な仕組み。
開発環境 開発者が自由に構成変更できる開発者共有の動作確認環境。SQSやCloudFrontなどネイティブサービスを利用した機能開発時に利用。
テスト環境 リリーススプリント中に実施するテスト時に利用する環境。リリース時に提供する機能を全て入れた環境としてテストする(ここでは、基本的に開発者自身が開発した機能をテストする) MagicPod利用あり
ステージング環境 リリーススプリント中に実施するテスト時に利用する環境。大きくはテスト環境と同じだが、できるだけ本番環境に似せたセキュリティ機能などを含めている(ここでは、基本的に機能開発者以外のメンバーがテストする)
本番環境 実際に顧客利用が発生する環境。 MagicPod利用あり

MagicPodの導入

―MagicPodの導入をすすめた具体的な状況について教えてください。

森:チームメンバ1名、山田さんをMagicPod導入担当者として進めました。最低限の機能についての学習時間を2日とり、移行を開始しました。移行する必要のあったケースはおよそ25ケースで、3週間ほどで完了しました。

  • 導入期間:0.7ヶ月(8月2日~8日23日)

―専任の担当者を置くことで役割が明確になりますね。導入はスムーズに進みましたか?

山田:はい、スムーズに進めることができました。先ほどお話しした通り、元々別のテスト自動化プラットフォームを利用していたこともあり、そちらで作成していたシナリオを流用しました。MagicPodに移行するにあたり、シナリオを大きく変える必要もありませんでした。

ケース作成画面
テストシナリオの作成画面

―移行の中でハードルになった点はありましたか?

山田:実際に自分で設定を行うにあたり、具体的な手順がわかりづらいこともありました。たとえば、複数のブラウザで同一のテストを流す方法などです。疑問点はMagicPodのヘルプページを検索することで解消できました。MagicPodのヘルプページはとても充実していると思います。

複数ブラウザのテスト一括実行設定
複数ブラウザのテスト一括実行設定 – MagicPodヘルプページより抜粋

自動テストの稼働状況

―現在の自動テストの稼働状況の詳細をお聞きできますか?

山田:MagicPodを利用して2つのテストを回しています。リリース前、リリース後にテストを回すことでより品質に自信をもってアプリケーションをリリースすることができています。

実行タイミング 内容 トリガー 実施頻度 実行時間 並列度
リリース前 リリース前に実施するテスト環境向けのメインフロー動作確認テスト 手動 1回/6~8週間 30分弱 1

※並列実行すると失敗するテストであるため

リリース後 リリース直後に実施する本番環境向けのメインフロー動作確認テスト 手動 1回/6~8週間 30分弱 1

※並列実行すると失敗するテストであるため

MagicPodのメリット

―MagicPod導入前にも別製品を利用されていたということで、MagicPodならではの恩恵があれば教えてください。

山田:それまで利用していたE2Eテスト製品と比較して、安定稼働することが挙げられます。前のツール利用時は、テストを一括実行した際に何らかの失敗が起きていました。テストケースの一括実行には時間がかかるため、手戻りによる時間のロスが大きかったです。MagicPodの利用を始めてからは安定性が高く、処理時間が早いため大幅な時間削減につながっています。

製品 安定性 処理にかかる時間 立ち上がりのスムーズさ 作業時間
前E2Eテスト製品 一括実行時は何らかの失敗が起こる 1サイクル1時間 * 失敗回数 5分程度
立ち上がりの問題でツールが落ちることも
1日確保して作業
MagicPod 予期せぬFailが起きていない 30分程度 立ち上がりに時間はかからない 1~2時間で結果確認までを完了

 

―テスト実行が安定して処理時間が早いことは重要ですね。テストケース作成の機能においてメリットはありましたか?

山田:必要なサポートを的確に提供する機能が充実している印象があります。以下の機能を使うことで、効率的なシナリオ作成ができています。

  • ログインなどよく利用する処理を共通化でき、部分的に動作確認も可能
  • 要素(idロケータなど)が見つからず失敗した際に、代わりの要素を提案してくれるのでテスト改修がスムーズ
  • 変数機能があり、値を一括管理できるようになった
  • 複製機能があり、似たようなテストケース作成が容易になった

―idロケータ要素が見つからず失敗した際に、代わりの要素を提案してくれるのはとても便利ですね。

山田:テスト実行自体が失敗で止まらないのは、とても開発者体験が良いです。実行結果画面で「要確認」として担当が確認しやすいですし、シナリオへの修正反映もボタン押すのみです。

 テスト実行結果確認画面 - idロケータの自動修正

自動修正結果の確認画面
自動修正結果の確認画面

 

開発プロセス全体におけるE2Eテスト自動化の位置付け

―テスト自動化を進めるにあたり留意されている点を教えてください。

森:全てをテスト自動化するのではなく、抑えたいポイントを優先することです。すべてを自動化するのはその方が手動テストより時間がかかってしまいます。機能として落としたくないものを考えてクリティカルパスを意識します。回帰テストは「軽いものをたくさん」をモットーにしています。

―ひとつひとつが積み重なることで、時間削減効果が大きくなりそうですね。

森:アジャイル開発での品質の担保が難しい理由のひとつに短期間でサイクルを回すため、テストを行う時間が限られてしまう点が挙げられます。リリースサイクルを安定させるためにもテスト自動化は必須です。

自動テストの導入は、一見すると余計な工数に感じるかもしれません。しかし、長期的な視点で見ると、これは製品の品質と開発チームの生産性を大きく向上させる重要な投資となります。自動テストは、現代のソフトウェア開発において不可欠な要素です。適切に導入することで、プロダクト品質の一貫性確保、開発サイクルの短縮、技術的負債の削減が期待できます。

重要なのは、自動テストを単なる品質管理ツールではなく、開発プロセス全体を改善するための機会として捉えることです。長期的な視点で取り組むことで、その価値は最大限に発揮されます。

さいごに

「MagicPodの活用状況」と題して、他ツールからの移行とMagicPodならではのメリットについてお聞きしました。より効率的に自動テストを実行できることでプロダクトのリリースを早め、ユーザーへの価値提供に注力することができます。

今回インタビューいたしましたチームが提供する業務チャットボットを作成することができるプラットフォーム DialogPlayにもぜひご注目ください。無料で使い始めることもできます!

開発チームを支えるテスト自動化ツール、MagicPodの社内利用推進を今後も進めてまいります。