こんにちは！TECH Street編集部です！
2023年9月12日（火）に開催した、 「テスト自動化の先駆者3社が集結！今後の自動化の方向性」では、テスト自動化プラットフォーム3社（Autify／MagicPod／mabl）が集まり、各社のプレゼンテーションだけでなく、デモも見せていただきましたので、その様子をレポートいたします。
登壇者はこちらの方々！
松浦 隼人さん／オーティファイ株式会社
伊藤 望さん／株式会社MagicPod
おだしょー (小田 祥平)さん／mabl Inc
- テスト自動化プラットフォーム｢Autify｣におけるAI
- MagicPodで実現するE2Eテスト自動化
- mablで品質エンジニアリングジャーニーを実現しよう！
- Q＆Aコーナー
テスト自動化プラットフォーム｢Autify｣におけるAI
松浦：まずは我々が提供するプラットフォーム「Autify」についてのご紹介です。「Autify」はコードを書ける方でなくても、誰でも簡単にテストを作って実行できます。「完全ノーコードでもテストが作れる」という点が一番大きな特徴だと思います。
デモ動画
テスト自動化のきっかけ
「テスト自動化したい」と思うきっかけは様々あるかと思いますが、主なきっかけは以下の3つに分けられると考えます。
複雑化するアプリケーション → 手動ではカバーしきれない
アプリケーションが複雑化していくと、それに伴いテストも複雑化して、テストケースがどんどん増えていきます。そうすると手動でカバーしきれなくなり、「自動化しよう」という機運が高まります。
改善スピードを上げる必要性 → リリース頻度/テスト頻度を上げる必要性
アプリケーションの改善スピードを上げると、リリースの頻度も上げる必要がでてきます。Webアプリケーションの場合、「 1日に何回もリリースする」というのも当たり前になりつつあります。そうすると、テストの頻度も上げる必要が出てきて、手動だと対応できなくなり、「自動化する必要がある」という結論になることが多いかと思います。
同じテストの繰り返し増 → 自動化による手動工数削減
上記の2つ（「複雑化するアプリケーション」と「改善スピードを上げる」）をしていくと、同じテストを繰り返すことになります。「繰り返す」というのは、コンピューターが得意なことなので、それを自動化すると、手動でやっていた工数を大きく削減できます。これが自動化するきっかけになると思います。
しかし、このようにテスト自動化を進める必要性が出てきたとしても、実際にテスト自動化をする際には、難しい課題もあります。
テスト自動化の問題点
問題点①：自動化ならではの問題
・人間なら自然に回避できる問題を明示的に回避する必要がある
例：時差をつけて現れる要素をクリックする
例：要素の情報（idやclassなど）が動的に変わる
例えば、皆さんの中に「Web ページが開いた時に画像が遅れて表示される」などのような「時差をつけて現れる要素」に出会ったことがある人もいるかと思います。
この「遅れて表示してきたかどうか」というのをうまく対処しないと、テスト自動化するときに問題が起こることがあります。
問題点②：作成した自動テストのメンテナンスコスト
・テスト対象が変わった時のシナリオのアップデート
テストシナリオがどんどん増えていってリリース頻度も増えるということは、アプリケーションの改善がスピードアップしていくことになります。
（これはこれでいいことなのですが）自動化したことによるアプリケーションの改善の速度アップについていかないといけず、これが結構負担になることがあります。
このようなテスト自動化に関する問題は、Autifyなどのツールを使えば解決できると思います。
AIを使ったテスト自動化：問題点を解決・緩和
・手動テストとは違ったスキルが必要 → コードを（ほとんど）書かなくてもOK
・自動化ならではの問題 → AIがサポート
・作成した自動テストのメンテナンスコスト → AIがサポート
AutifyにおけるAI
変化した要素の探索
・主にHTMLを使用
・要素の特徴情報から、変化した要素を高精度で特定
・ 人間はそれが正しいかチェックするだけ
・ テストシナリオのメンテナンスが短時間で容易に
下図の左側の画像と右側の画像では、少しデザインが変わっています。
AutifyにおけるAIのロジックは、その要素の特徴情報を覚えておくことで、デザインが変わり、HTML がガラッと変わったとしても、それが同じ役割のものであると認識できる、というものです。
これによって、人間はそれが正しいかどうかチェックするだけでテストシナリオをアップデートできます。
ビジュアルリグレッションテスト
・テスト実行時のスクリーンショットを比較して差分を検出
・画面全体だけでなく要素単位でも比較可能
これは、「正しく広告が表示されてるか」「正しく画像が表示されているのか」というようなところもAIが判断してくれます。
画像情報を用いた要素の特定、変化した要素の探索
・モバイルアプリのテストの問題
・ 構造化された要素情報がない（乏しい）
・ 画像情報に依存する必要
・画像情報を元に、指定した要素をAIが抽出・特定
・同様に画像情報を元に、変化があった要素を探索
また、例えば上図の「ハンバーガーアイコンをきちんとアイコンであると認識できたり」「Hatty Hive という文字のところもラベルとして認識できたり」、画像の中から要素の情報を全部抽出してくれるようなモデルも開発しています。
この技術によって、モバイルアプリケーションのテストも可能となっています。
AutifyにおけるさらなるAIの活用
・さらに進んだ利用：シナリオの作成支援
・テストステップごとの提案（Autify Step Suggestions）
→ レコーディング時、ステップごとに何をテストすべきか提案
→ 従うだけでテストシナリオが作成できる
デモ動画
まとめ
・テスト、品質保証は人の目が大事、職人芸
・AIを使えばその一部を代替できる
・ テスト実行部分への適用
・ さらにテスト自動化をスムーズにする分野へ
・人間はテスト設計など、より高度な仕事を
松浦さん、ありがとうございました！
続いては、株式会社MagicPod 伊藤 望さんの発表です。
MagicPodで実現するE2Eテスト自動化
伊藤：まずは弊社が提供する「MagicPod」についてご説明します。
「MagicPod」はWebサイトのテストとモバイルアプリのテストの両方を自動化できるサービスです。ノーコードで簡単にテストが作成できることに加えて、柔軟性とメンテナンス性があるのが強みです。
それでは具体的な操作をデモ画面を使ってご説明いたします。
デモ動画
MagicPodが実現したいこと
1.開発生産性向上に寄与
・毎日テスト、常にテスト
・問題の早期検出で生産性が向上
自動化だからこそ、毎日テスト、常にテストができる状態に持っていくことが可能です。これにより問題の早期検出ができ、生産性向上に繋がります。
2.継続的デリバリーの実現を支援
・1日何回も、好きなタイミングで変更を本番環境にデプロイ
・あらゆるレベルのテストを自動化する必要がある
日本では、「1日に何度もデプロイする」という状況はまだ少ないですが、MagicPodのツールを使ってそれが実現できるユーザーが１人でも増えたらいいなと思っています。
Daily Test/Deployを実現したユーザーが増えている
最近はDaily Test/Deployを実現したユーザーが増えていると感じます。
mixiさんの事例
mixiさんの事例ですと、様々なタイプのテストがあるので、優先順位をつけて対応しています。例えば「簡易テスト」は1日に3〜4回実施し、「フル回帰テスト」は1日に1回実施する、といった感じです。
リクルートさんの「スタディサプリ」の事例
例えば『スタディサプリ中学講座』の案件では開発者が任意のタイミングで、かつマイクロサービス単位でリリースしています。その際に手動のリグレッションテストではなく、MagicPodによりリグレッションテストをフローに組み込んでいます。
BUYSELLさんの事例
BUYSELLさんの事例でも、小さく高頻度でリリースしています。そして、開発、テスト、デプロイのサイクルを高速で回してます。プルリクエスト数が1日10件マージされて本番環境に上がることもあるようです。
MagicPod的ベストプラクティス
「MagicPodをどのように活用するか？」について、ベストプラクティスをいくつか紹介します。
テストは毎日自動実行
最新のソースコードを毎日ビルド・デプロイし、テストを自動実行します。そうすることで、手動だと、担当者や体制が変わった際に実施されなくなりがちだった問題を解決できます。
テストはクラウドで実行
MagicPodが提供しているクラウドでも実行可能です。ローカルPCだと、そのPCの固有の問題やバージョンアップの関係などによって、予期せぬ問題でエラーがでたり、セットアップで面倒なことも多いので、クラウドで実行するのがオススメです。
優先順位をつけて自動化する
全て作ってから回そうとすると、作っているうちに陳腐化してしまうこともあるかと思います。なので、少しずつ作って毎日回すことで、早めに何らかの成果を得ることができ、それが自動化定着の近道になると思います。
テスト間の依存関係を減らす
テスト間の依存関係を減らすことで、分かりにくいエラーを減らしたり、失敗切り分け難易度を下げることが期待できます。
共有ステップを積極的に使う
MagicPodにもAIによる自動修復が入っていますが、すべてのケースをカバーできるわけではないので、画面が変わったときのメンテナンスリスクを減らすためにも共有ステップがオススメです。
ロケーターについて学ぶ
ノーコードでも作れますが、ロケーター編集ができるようになることで画面変更に、より強いテストが作成でき、より凝ったことができるようになります。変わりにくいユニークIDをUI要素に付与するなどアプリケーション側がテストしやすくすることも重要です。
文法について学べるコンテンツ
テストしやすいアプリケーションにする
アプリケーション側をテストしやすく作ることも非常に重要です。例えば、「ユニークIDをUI要素に付与して、画面の変更に強くする」や「デバック機能を有効化する」「Google認証のような自動化しにくい機能を迂回する方法を用意しておく」などの工夫をすることでテストしやすいアプリケーションになるかと思います。
各種機能紹介
最後にいくつか機能紹介をします。
クロスブラウザ・マルチ端末
・作ったテストをさまざまなブラウザ・端末で実行
・並列実行もサポート
Visual Regression Test
・画面キャプチャが期待値と一致するかチェック
・デザイン崩れバグなどの検出が可能
UI変更があった場合のテスト自動修復
CI連携
これらの操作は、すべてノーコードで作成可能です。
無料トライアルもあるので、ベストプラクティスを参考にしながら是非皆さんも使ってみてください。
伊藤さん、ありがとうございました！
続いては、mabl Inc. おだしょーさんの発表です。
mablで品質エンジニアリングジャーニーを実現しよう！
小田：mabl（めいぶる）は2017年ボストンで創業され、2021年8月に日本法人が設立された若いスタートアップでありながら、グローバルにおいてテスト自動化SaaSのリーダー企業でもあります。我々が提供するテスト自動化プラットフォーム「mabl」はローコードテスト自動化が可能で開発チームのテスト高速化に貢献できるのが特徴です。
高速開発チームのためのローコードテスト自動化
mablが提供するサービスはローコードでのE2Eテスト自動化やAPIテスト自動化だけではありません。例えば、サイト上で黒背景の上に灰色の文字が置いてあると、ユーザーにとって見づらく、なんらかのアクセシビリティに違反していると思われますが、このような「人の目で確認するのは大変だけど、WCAGなどのガイドラインに違反しているようなもの」があった場合に、mablは自動的に判別して、具体的な違反内容と共に知らせてくれます。
ローコードによるスピード感とさまざまなテストを組み合わせ可能な拡張性があり、必要な場面で信頼性の高い品質フィードバックを提供しています。実行したテストの内容をグラフィカルなレポートで表示する機能もあります。
CI/CD連携など、すでに使用している開発ツールに自動テストをシームレスに組み込むことも可能です。
ローコードテスト自動化 mablのスコープ
mablのスコープは下図の通りです。UIやE2Eのテストはもちろんのこと、APIのテストにも対応しています。
より良い品質のソフトウェアをより早く提供
mablを導入することにより、テスト構築や実行が早くなるだけでなく、コストも安くなるといった効果が期待できます。既に日本のアクティブユーザーは20%を超えており、アメリカに次いで２番目の多さです。
GDPRへの対応、SOC Ⅱ Type 2（米国公認会計士協会が定めたサイバーセキュリティコンプライアンス）認証も取得しているエンタープライズ対応のセキュリティで提供しています。
mablが描くQuality Engineering（QE）ジャーニー
こういった品質保証はよくQA（Quality assurance）と呼称されていますが、mablではそれを更に拡張したQE（Quality Engineering）という概念を提唱しています。
開発後に手動テスト
開発後に手動でのテスト（上図の一番下）が現状まだ多いかと思います。私も過去何度も経験してきましたが、手動テストはとても辛くテスターによっては判断基準が曖昧なため、品質の担保もできず非常に非効率だと思います。（エクセルで切り貼りして操作するなど、とても大変でした,,）
機能テスト自動化のカバレッジ拡大
それまでの手動テストを自動化して、なるべくE2EやAPIなどのテストを通じて、テスト自動化のカバレッジを増やしていこうというのが「機能テスト自動化のカバレッジ拡大」（上図の下から2番目）の段階になります。これにより一定の品質が保証されます。
シフトレスト：自動化されたテストを開発に組み込む
開発の早い段階でバグを特定し対処するために、CI/CDツールと連携し、テストにかかる工数も削減していく段階になります。（上図の真ん中）デプロイ頻度を向上させるにはこれらの対応が欠かせません。
非機能的品質の検証
Non-functionalの要件にも対応するために、たとえばアクセシビリティテストを自動化することで、曖昧な人間の目を使った判断をなくし、自動的に違反判定などを検知し品質の向上を行う段階です。（上図の上から2番目）
品質指標を使用した継続的な改善
テストを回していくと、さまざまなデータが溜まっていくので、それらを活用して、QAチームや開発チームだけでなく、ビジネスオーナーなどの多くのステークホルダーなどを巻き込みながら、品質指標を定められるようになります。その定めた指標を基に継続的な改善を行っていく段階です。（上図の一番上）
デモ動画
各種機能紹介
自動修復でメンテナンス作業を削減
従来、テストは壊れやすくメンテナンスに時間がかかるものでした。この自動修復機能では、画面のレイアウトが変わっても要素の変更を検知して、テスト自体を自動で修復できます。
GCP上で並列テストを実行
並列テスト実行も可能です。おそらく1000件くらいなら並列で回しても、余裕で耐えられるかと思います。
既存のツールとの統合が可能
mablではさまざまなCI/CDツールとのシームレスな連携が可能です。テスト結果をTeamsやSlackに投げることもできます。スライドにはないですが、Safariでのテストも可能です。mabl Linkを使うとインターネットに抜けていない環境のテストも可能です。
CI/CDパイプラインへの統合
一例としてGitHubとの連携画面をご覧ください。このように普段お使いの開発ツール上でテスト結果を確認できます。他にもGitLabやCircleCI、JenkinsやGoogle BigQueryなどさまざまなツールと統合が可能です。
パフォーマンス評価
テスト結果はmabl上に保存されます。たとえば、あるタイミングのデプロイ以降に読み込みが遅くなった場合、グラフィカルなレポートでそれを確認できるなど、問題点の把握に役立てることもできます。
今後のmablについて
今年から来年にかけて、「ネイティブモバイルアプリテスト」と「パフォーマンステスト」に注力していく予定です。既にAPIのパフォーマンス（負荷）テストは早期アクセスでリリースしているので、お手元の環境で試すことも可能です。同時1000ユーザーでの実行や徐々にユーザーを追加するランプアップなど機能が充実しています。
ネイティブモバイルアプリテストは、AndroidとiOSの両方に対応する予定です。
ロードマップを公開
mablでは製品ロードマップを公開しています。投票機能だけでなく、こんな機能がほしい！というリクエストも受け付けていますので、興味がある方はぜひアクセスしてみてください。
Mabl Product Portal
mabl Universityについて
mablには2週間の無料トライアルが用意されています。
とはいえ、せっかくアカウントを作っても、2週間何もしないともったいないですよね。そんな方向けに「mabl University」 という学習サイトを用意しています。さまざまな学習スタイルのメニューを用意しているだけでなく、mabl Skills Certificationsという認定資格制度もあります。現在3つの資格を取得することができるので、学習後すぐに腕試ししてみましょう！
mabl のユーザーコミュニティについて
mablが定期開催、運営しているWebinarだけでなく、「mablers_jp」というmablのユーザーの皆さまが中心となって運営しているコミュニティがあります。ユーザーによる忖度のないリアルな話を聞きたい方はぜひご参加ください。
おだしょーさん、ありがとうございました！
続いては、質問コーナーです。
Q＆Aコーナー
続いてQ＆Aコーナーであがった質問を紹介します。
（Q）オーティファイさん、ノーコードにこだわっているのはありがたいです。エンジニアじゃない界隈を視野に入れているということでしょうか？それともエンジニアだとしてもテストはノーコードがウケる感じなのでしょうか？
松浦：Autifyが創業当初からノーコードにこだわっている意図は、エンジニアだけでなくエンジニアでない方でもテストが作成できることで、チームの垣根を越えて品質保証に取り組むことが可能になるからです。また、発注者側がテストをしたり、カスタマーサポートがテストをして問合せを減らすといった使い方もあったりします。AutifyはエンジニアやQAだけでなく、広い層に支持されて使われています。その一方、実はAutifyはエンジニアのユーザーの割合も大きかったりします。いちいちE2Eテストを書き直さなくて良かったり、何をテストしているかをコードを介さずに他のメンバーと共有できる点を評価いただいており、エンジニア、非エンジニア問わずノーコードであることの恩恵は幅広いと言えます。
（Q）モバイルアプリ版はどのようなモバイルの機種をサポートしてますか？
松浦：AndroidエミュレータとiOSシミュレータです。
伊藤：Android, iOSのエミュレータと実機です。手元実機やBrowserStack/SauceLabs連携を使えばだいたいなんでもできます。
（Q）同じテストシナリオをウェブ版とモバイル版で実行できますか？例えば、ウェブの管理画面で通知を設定し、モバイル版で通知が届くかどうかを確認するような簡単なテストとか
松浦：現時点では、ウェブ版とモバイル版とで別々にシナリオを作る必要があります。ただし、APIなどを使うことで効率化の工夫をしていただくことはできます。
（Q）シナリオ作成の支援むっちゃありがたい。これ、そのままマニュアル化にも活用できる感じでしょうか？
松浦：マニュアル化に活用できるような機能となるように目指しています。実際に"ユーザーが使うものを再現できる"ところを目指しています。
（Q）CypressやPlaywrightではできるけれどAutifyではできないことはなんでしょうか？
松浦：Cypressなどの自動化フレームワークを使うと、コードを書く必要はありますが、コードならではの柔軟なテストを作成できます。（Autifyのようなノーコードツールは複雑なテストを作るには少しテクニックが必要なケースもあります。）一方でAutifyではテストシナリオのセルフヒーリング(AIによる変更検知と提案)など、OSSのフレームワークにないサポート機能を提供しているので、必要な要件に応じて使い分けるのが良いと考えています。
（Q）Autify で作成したテストを他のプラットフォームに移行することはできますか？たとえば Playwright による E2E テストにマイグレーションする、といったことは可能なのでしょうか。
松浦：現時点ではテストシナリオのエクスポート機能がなく、移行はできません。ですが、多くのお客様からご要望をいただいているため、社内で検討を進めております。
（Q）Autify、テスト結果のエクスポートがAPIを通じてしか出来なかったと記憶しているのですが、結果をエクスポートして証跡として提示できるようになっていると実利用では有り難い気がします。
松浦：有償機能として、スクリーンショットとテストステップの詳細を含めたテスト結果エクスポート機能を提供しております。
（Q）AIが提示してくれるテストケースと人が作成したケースを比較した場合、一致率はどのくらいなのでしょうか？
松浦：まだ具体的なデータはありませんが、Autifyでは今後重要度の高いテストシナリオをAIがより高性能に提案するように学習を促し、テストカバレッジ自体の向上にもご活用いただけるようにしていく予定です。様々な場面でのテストをAIが提案し、そのデータをもとにさらに改善できるよう、たくさんのお客様にお使いいただけると嬉しいです！
（Q）MagicPodさん、伊藤様が自ら作ったというのにびっくりしたテスト界隈初心者なのですが、そもそも作ろうと思った一番のきっかけというか理由は何だったのでしょうか？「テストめんどうでやってらんねーよ、もう俺がつくるしかねー！」みたいな？それとも「この先絶対に需要があるから儲かるやろ！」みたいな？
伊藤：13年くらい前に作っていました。あまり使えるツールがなかった。でも作らないと社内で使えるツールがない！と思い、予算をもらって取り組みました。その中で自動テストはニーズはあるが、ソリューションがないというところで起業にいたりました。なので両方です！
（Q）MagicPodさんのLT大会、アーカイブありますか？！見てみたいです！
伊藤：オフライン開催だったので、アーカイブはないです。noteの記事があります！
MagicPodユーザーLT会レポート
（Q）メンテナンス性、これ結構重要ですよね！そこを意識されている理由、どういう箇所がメンテナンス性のポイントなのかを教えてください。
伊藤：初代のツールはメンテナンスはあまり考えてなかったです。でもいざ作ってみるとメンテナンスがしんどいという感想がありました。簡単に作れるだけじゃなく、メンテナンスの重要性を身に染みて感じました。「メンテナンス性」は長期的に使うときの鍵です。
（Q）状況によって自動テストの期待する結果がバラバラなシナリオは作れますか？ 例） ・週間スケジュールビューから任意の曜日を選ぶと、選択した曜日の日別スケジュールが表示される。
伊藤：１週間後など、狙った違う日を選んでスケジュールを出すことはできます。何をやりたいかにもよりますが、ある程度の要望は叶えられると思います！
（Q）MagicPodで、操作対象を拾っていくのではなく、他のツールと同様に操作を記録していくようなテストケース作成ができるようにはならないんでしょうか？
伊藤：操作対象を拾っていく形式のパフォーマンスとサジェスチョン力を極限まで高めれば、理論上は操作記録とほぼ同じスピードでテスト組めるようになると思っており、そちらをまずは注力していく予定です。
（Q）デイリー○○が主流なのですね、これは開発手法としてアジャイル主流だからという感じでしょうか。
伊藤：もっと頻度が高くてもいいんですが、E2Eテストは時間がかかることもあり1日1回よりも頻度を上げるのはなかなか大変ですね。
（Q）ボストン！テスト自動化について、日本と世界での圧倒的な違いと、ここは万国共通だなーな点を聞きたいです
松浦：オーティファイは既にグローバル15カ国で採用されております。日本と海外おける違いに関しては、自動化に対する知識が違うので、USでは自動化を既にしているが、さらに効率化するためにはどうするべきかと言う観点で自動化に取り組んでいるが、日本は自動化をこれから導入するというフェーズにいる企業様が多い。共通点としては、リリースサイクルを向上させ、テストの時間を短くし工数を削減する事に対するニーズがあると言う部分があります。
小田：DX白書2023によると、国内でCI/CDやDevOpsを採用した開発はわずか9〜11%程だそうです。USは50%程度で大きく水を空けられています。逆に米国以外ではEUやインド、オーストラリアなどでも広く使われていますが、日本と似たり寄ったりな話をよく耳にします。
（Q）テスト自動化サービスを初めて知る初心者なのですが、ライブ実演あざます！むっちゃイメージがつかめました！mablさん、外資系とのことですがマニュアルなんかも含めて完全ローカライズされてる感じでしょうか？
小田：mablのデスクトップアプリやヘルプページ(mablについて)などの各種ドキュメント、学習サイト(mabl大学)、認定資格試験(Mabl Skills Certifications / mabl の認定資格)などローカライズには力を入れています。外資製品ではあるあるのちょっと違和感がある翻訳も時折見かけますが、見つけ次第修正依頼しています。mablはほぼ全員が日本が大好きで、逆に向こうから「日本語ではなんて言うの？」とよく質問が飛んできます。
（Q）「高速」というのが重要なポイントということなのですね、ここをポイントにしている一番の理由は何でしょうか？世界の主流？
松浦：ソフトウェアの改善のスピードが求められる場合、テストも高速である必要があります。また一般にE2Eテストは遅いというイメージがありますので、その辛さを解決したいという想いを込めて速さを追い求めています。
小田：手動テストには限界があり、何より人手と工数をかける方法が多用されがちで「遅い」ですよね。モダンな開発を進めていくにあたり、テストフェーズをいかに効率的に行っていくかが1つの鍵になります。そういう意味で「高速」という言葉を使用しています。
（Q）めーぶる？めいぶる？
小田：「めいぶる」です！！よろしくお願いします！！(土下座
（Q）ノベルティほしいのですが、何に参加すればよいですか？
小田：直近では10月にCTC Forum2023に物理ブースを出展します！
オンラインイベントでは難しいのですが、オフラインであれば直接お渡しできますので、是非ブースにお越しください！
一部有資格者限定のノベルティもありますので、是非認定資格試験にもチャレンジしてくださいね。
（Q）アクセシビリティに着目したのは時代の流れですか？(SDGs的な
小田：米国では2022年だけでアクセシビリティに関する訴訟が4000件にも上ったというデータがあります。
日本国内では現在時点であまり重要視されていませんが、ハンディキャップの有無に関係なく同一の体験を提供する必要性は増してきています。実際に2021年に障害者差別解消法が改正され、2024年6月までに行政機関だけでなく事業者にも対応が求められるようになるようです。もうすぐですね。
（Q）愛フォンでQRコード読み込みました！
小田：ありがとうございます！！どこの店舗に並びますか！？(過激派意見
（Q）事業拡大局面において、各社さんが課題に感じているところはどこでしょうか
松浦：事業拡大の課題は大きく分けて技術的な面とビジネス的な面の2つあります。お客様がテストを行う時の問題点を自分たちで理解するため、Autifyを使って、Autifyをテストしています。この時に開発スピードと品質向上をいかに最大化していくかを自分自身（自社）が実感し、解決していくことが今後の事業拡大に重要な技術的課題と考えています。一方ビジネスとしては、日本以外への進出をさらに進めていきたいと考えています。既に15カ国以上で使われている一方、日本と海外ではさまざまな状況が違うので、ここをいかに乗り越えるかが課題です。
伊藤：技術面は、バックログがあるけど人が足りないという点。採用が課題です。営業の人の採用は難しいです。海外進出頑張っていますが、言葉の壁が大変です。最近はインド英語に苦戦しています。
小田：先ほどお話した通り、DX白書2023によると、国内でCI/CDやDevOpsを採用した開発はわずか9〜11%程だそうです。USは50%程度で大きく水を空けられています。
これでは「単純にテストの作業工数を減らす」ことに自動化ツールが使用されるだけで、本来の価値を発揮できません。アジャイル開発の各スプリントで実施されるテストがスプリントを圧迫しないことやシフトレフトを実現するためにテストの自動化を進め本質的な価値提供に時間を割く環境を作る啓蒙活動をする必要性を感じています。
（Q）ずばり、ChatGPTのように、「こんなテストを作って」を基に、各社のサービスを利用して作ってくれるような開発は進んでますでしょうか？その際どのようなハードルが見えてますでしょうか？
松浦：「こんなテストを作って」とオーダーすると、シナリオを作ってくれる機能はAutifyとしても目指す姿です。AutifyのStep Suggestionsは、ChatGPTを活用し、テストシナリオの作成をアシストする最初の段階として、ステップごとの提案をする機能です。（現在ベータ版の提供となっております）
ChatGPTなどのAIを活用して皆さんのニーズに応えるサービスを提供できるように、ハードルを一つ一つ乗り越え、出来ることを増やして提供していきたいと思っています。
伊藤：ゼロからMagicPod に指示するというのは考えていないです。ただ、ChatGPTを取り込んだシステムは検討しています。外側でつくってもらったものを取り込めたらいいなと考えています。
ChatGPTも部品として、要所要所で役に立っているという印象です。ゼロからとなると、ChatGPTも成長が同じくらいなのではないかと考えています。
小田：ChatGPTではハルシネーションは起こりますし、あくまでCopilot("副"操縦士)なんですよね。
デモ用に簡単なHTMLをAdvanced Data Analysisで吐き出しているのですが、テストを回したらよくエラーを吐きます。
そもそもChatGPTで出力された結果は正しいのか、常に念頭に置いておく必要があります。
生成AI時代になったからこそ、テストの重要性が増したと感じています。
（Q）他社にはない、それぞれの強みを教えてください！
松浦：極力コードを書かなくてよく(ノーコード)、直感的に使えるユーザインタフェースを指向してサービスを開発しています。
エンジニアはもちろんエンジニアでない方々にも広く使っていただけるのがAutifyの強みであり、開発者からQA、またプロダクトマネージャーまでチーム一丸となって品質保証に取り組んでいただけます。また、使いやすさの追求という点においてAIの活用にも積極的であり、Step SuggestionsやSelf healingの機能のように、今後も人間がテストを行うのを補助してくれる・代わってくれるAIの開発を進めていきます。（さらに自由度を高めてJavaScriptを使用し、機能を拡張することも可能です）
伊藤：モバイルアプリとWebアプリのテストが高い品質でできます。
小田：直感的なインターフェース、E2Eテストとも連携できるAPIテストやパフォーマンス(負荷)テストが強みです。
平行で1000件の同時実行も可能で、エンタープライズユースも想定したスケーラビリティのあるプロダクトになっています。
E2Eのパフォーマンステストやネイティブモバイルアプリテストも2024年にかけてローンチされる計画が進んでいるので、ご期待ください！
（Q）自動化の普及が遅れている理由はどんなところにあると思いますか。
松浦：リリース速度の向上に比例してテストの頻度も向上するため、自動化の需要も高まります。競合より先に製品をリリースし、顧客のニーズを素早く反映してアップデートし競争力を高める必要があります。競争力の強化を求める時に、開発の速度だけを意識しがちだが、テストの頻度が少ないと高品質な製品を維持することは難しいので、テスト頻度を高めることが競争力の強化に必須だと言う理解が深まるようにAutifyからも情報提供を行なっていきます。
伊藤：テストの頻度が低いから手でやれる。アジャイル開発の普及が遅れているから。ウォーターフォールモデルになりがちなところが、普及の遅れにつながっていると思います。
小田：DevOps などの採用が遅れてるから、自動化の本質的な価値も当然感じてもらいにくい環境にあると思いますね。
（Q）テスト自動化は、全く無知の状況です。 ただ、Autify の社名だけは知ってまして、MagicPod、mabl は、も 当該セミナーの告知で初めて知って。、 その中で 稀少性のようなものを なぜか 直感したので、申し込み させていただきました。
松浦：ありがとうございます！
伊藤：ありがとうございます！
小田：ああああ！初めましてmabl(めいぶる)です！是非お見知りおきください！
（Q）自動テストを、プロダクト同様に資産としてまわしていく、育てていくことになると思いますが、どのようにしますか？
松浦：Autifyをさらに使いやすく、また維持しやすいサービスにすることは重要な鍵だと考えており、継続的に改善をしていきます。
一方で、開発者がプロダクトのコードと同様にテストもメンテナンスしていくことが重要だとも考えており、弊社ではAutifyを使ってAutify自体をテストしています。自動テストをメンテナンスし資産として育てるという考え方を広めることもまた私たちの役目だと思います。
伊藤：GitHubとの連携を可能にさせることが重要だと思っており、ちょっとずつ取り組んでいます。
小田：テスト自体は重要とされつつも蔑ろにされがちなので、既存のCI/CDパイプラインに組み込んで自動実行する仕組みを構築することがお勧めです。Jenkins, GitHub, GitLab, CircleCI, Bitbasketや、チケッティングにはJiraとも連携可能です。
mablによる自動テストを開発ワークフロー全体にシームレスに組込むことが可能
（Q）現場を知ってる人が自動化に着手する。のが一番だと思っているが、現場を詳しく知らない自動化のプロが自動化の先陣を切るとして、大事にするべき心の持ちようやあるべき思考の方向性はどんなものがありますか？
松浦：開発スピードと(自動化を通じた)品質の保持・向上はトレードオフではなく、どちらも両立すべきことであると認識し、現場をよく知ることでどちらかを犠牲にしない施策を打っていく必要があると思います。
伊藤：業務理解を大切にする
小田：QAには横横断的に対応するチームやチーム内専任など形は様々です。
ご質問は前者の場合かな？と推測しますが、現場1つひとつの解像度をなるべく上げて対応することが重要かなと考えます。
一見遠回りになりそうですが、横横断的に対応しているからこそ解像度を上げていくとチーム間の共通の問題やそれぞれの強みなどを客観視でき、価値の高い仕事が提供できるのでは？と思います。
（Q）組み込み系のソフトウェアのテストに適用していく予定や展望があればお聞かせください。
松浦：当社サービスでテストできる対象を広げていくべき分野の1つとしては認識しています。
伊藤：すみません、ありません。Appiumが対応しているRokuとか**TVとかは将来対応できたらいいかもしれません。
（Q）クラウドで行うというのはMagicPodさん独自のサービスなのでしょうか
松浦：Autifyでもクラウド実行を提供しています。
伊藤：他社さんも対応してます！
小田：クラウド実行対応してます！
（Q）3者さんにお聞きしたいです、テストも開発も、もう完全にクラウドが主流、そうじゃないとまずい世の中になっちゃいますでしょうか
松浦：クラウド・ローカル共に利点欠点ありますので一概にお答えすることは難しいですが、当社では環境依存を排すためクラウド実行を基本としています。
クラウドの場合ネットワークの速度や可用性に影響されますが、環境依存を抑えることが可能です。ローカルの場合、環境依存が激しいといった欠点がありますが、テストに限定していえばE2Eテストは一般的に遅いので、高速で実行できるという利点もあります。
伊藤：開発用のIDEはまだしばらくローカルに残ると思います。テスト実行環境は、クラウドのが優位性あって、長期的にはクラウド有利と思います。
小田：テスト製品の設計思想によると思います。
手元で動くか確認するためにローカル実行は活用するべきとも思いますが、継続的な品質の改善にはクラウド実行で過去貯め込んだデータとの比較を行っていくことが重要とも感じます。
あるデプロイ以降、読み込みが遅くなったことを過去データと比較して検知する機能があります。これは従来勘や感覚に頼っていた方も多くいるところです。
（Q）各社さんに一番得意分野、PRポイントはお聞きしたいですね
松浦：ノーコードで極力コードを書かなくてよく、直感的に使えるユーザインタフェースを指向してサービスを作っていますので、エンジニアはもちろんエンジニアでない方々にも広く使っていただけるものになっています。また、同じく使いやすさと言う点でAIの利用にも積極的で、Step Suggestionsはその1つですが、今後も人間がテストを行うのを補助してくれる・代わってくれるAIの開発を進めていきます。
伊藤：モバイルアプリとWebアプリのテストが高い品質でできます。
小田：各社が提供しているE2Eテストだけでなく、APIテストやパフォーマンス(負荷)テストが強みです。平行で1000件の同時実行も可能で、エンタープライズユースも想定したスケーラビリティのあるプロダクトになっています。直観的なインターフェースも推しポイントです。
E2Eのパフォーマンステストやネイティブモバイルアプリテストも2024年にかけてローンチされる計画が進んでいるので、ご期待ください！
（Q）テストシナリオの作成自体をAIのほうで自動作成してくれる機能はないのでしょうか？
松浦：今回のStep Suggestionsはあくまでもテストのステップを提案しますが、これはあくまで第1歩でしかありません。シナリオ作成自体も代わりにやってくれるような機能もあり得ると思っています。
伊藤：現時点ではありません。
（Q）AIサポートというのはこの先完全に主流という感じなのでしょうか？プログラミング側もAIサポートの時代ですし。このあたり、テスト自動化での世界標準も今は「AIあたりまえ」でしょうか？
松浦：テストは手動で行われる場面も多いですし(特にE2Eテスト)、その手動作業の一部を代替するため、あるいは手動作業をサポートするためにAIを使うことは増えていき、その意味では当たり前になっていくのではと思います。ただし、AIにも得意不得意があるので、適材適所で使い分けていくことになるでしょう。Step SuggestionsはAIが得意とする人間をサポートする機能の1つであり、このような機能は積極的に活用していくべきだと考えています。
伊藤：なんらかの形でどんどん増えていくと思います。
小田：現在時点では要素の変更を検知したり、ウェイトタイムを自動で適切な値に設定したりの自動修復機能でAIを活用しています。
ChatGPTなどで話題となった生成AI関連の技術も今後組み込まれていくことになると思います。mabl blogでそれらの検証を行った記事などが公開されているので、ご興味があれば是非ご覧ください。
（Q）各社さんにお聞きしたいのは、テスト自動化で属人かを排除、絶対必要かなと思いつつ、担当者のテストスキルが育たない？という不安もありつつ、、、この辺りいかがでしょう？
松浦：Autifyなどのテスト自動化ツールに任せることが出来る部分(テストの実行など)は積極的に頼りつつ、テスト設計などの上流部分や、自動化が難しい分野にスキルの重点を移すことで、テスト自動化ツールを活用した生産効率性の高いスキルの形成が可能になると思います。
伊藤：自動化は継続的にメンテナンスがやはり発生しますので、スキルは鍛えられると思います。また、繰り返し作業が減りテストケースや業務を考えることに時間を使えるので、スキルはむしろ育つと思います
小田：クラウド環境が浸透してオンプレミス環境で培ってきたハードウェアの知識が不要になったかと言えば、実際は基本的な知識や技術の理解がアドバンテージになることと同じだと考えています。
（Q）内緒にしておくので各社自動化ツールでできないこと・苦手なことを聞きたい
松浦：Captchaのような機械かどうかを判定する仕組みを突破するのは苦手となっています。
伊藤：「ロボットですか？」の確認機能
小田：MFA苦手だったのですが、最近サポートを開始しました。とはいえ、当たり前ですが認証系は自動化と相性悪いですね。
（Q）ノーコードということは未経験者でも作れる分 今度はそのテスト自体に対しての品質保証が担保できるわけではないというような問題も出てくるのかなと考えますが 品質保証も担保するために考えていることとかはありますか
松浦：Autify社内でAutifyを使ってテストする際には、開発者がテストを作成し、QAチームがそれをチェックするという流れを経ることで、テストの品質を担保するようなワークフローにしています。また、QAチームが開発者にテストスキルを伝授するハンズオンを行ったり、ドキュメントを作成するなどして一定以上の品質のテストが作られるようにしています。
小田：良い包丁があるだけでは料理が上手くならないのと同じで、使い手のスキルやマインドセット、チームや組織でどのように活用するかのルール化は必要だと考えています。QAエンジニアを中心にどのようにテストすれば品質の向上に寄与できるのか、またその基準をどう設定するのかについて、データを取得しながら目標設定することが重要と考えます。
（Q）ハチのマスコットかわいい
松浦：ありがとうございます！ 名前はHatty(ハッティー)です！
はじめまして、Hattyです‼︎
小田：ゆるキャラ運動会やりたいですよね！！
（Q）CI連携は、今はGithub Actionsが一強なんでしょうか？個人的にはCircle CIがすきなんですが。。。
松浦：AutifyではGitHub Actionsはもちろん、CircleCIでも簡単に使えるようOrbを提供していますし、他のツールも連携できるように仕組みを提供しています。また、Autify社内では場合によってGitHub ActionsとCircleCI Orbを使い分けてAutifyでテストしています。詳しくはドキュメントをご覧ください https://help.autify.com/docs/ja/cicd-with-autify
伊藤：うちもCircleCI使ってます。
小田：CircleCIとのインテグレーション、もちろん可能ですよ！CircleCIのエバンジェリストの方が昨年のアドベントカレンダーでmabl連携の記事を公開しているので、是非ご覧ください！
mablによるE2EテストをCircleCIから呼び出す
（Q）仕様の変更があった際のテスト側のメンテナンスについてはどのように行うのでしょうか？
松浦：Autifyでは、独自に開発したAIを使用した「Self Healing」というAIによる自動テストメンテナンス機能を提供しています。
軽微な変更であれば、セルフヒーリングの機能でメンテナンス可能ですし、大きく変更があった場合も追加レコーディングが簡単に行えます。
伊藤：AIの自動修復、UI画像の再アップロード機能、ロケーターの手編集、などを使う形です。
小田：自動修復機能をご活用ください。変更の程度によりますが、ローコードツールなので作り直すことも検討して良いかもしれません。
テストに使用するデータセットの追加変更なども場合によっては必要かもしれないですね。
（Q）素朴な質問ですが、テスト自動化ツールは、そのまま社内のRPAとして使うことも可能でしょうか？
松浦：テストに特化した仕組みになっているのでRPAツールとしては少々使いにくいのではと思います。ただ、Autify社内でもブラウザ上の作業を自動化するのに使うこともあります。
伊藤：できなくもないですが、ローカルインストールされたツールは触れないとか、不便も大きいので、RPAの専用ツールを使う方がいいと思います
小田：設計思想が異なるので、使用自体は可能だと思いますが、専用ツールの方が良いかなと思います。
（Q）テスト自動化のコミュニティやカンファレンスなどはありますか？ （伊藤さんが登壇とか言ってような気がしたので質問しました）
松浦：Autifyでは定期的にテスト自動化に関する最新情報やAutifyの使い方をお伝えするセミナーを開催しています。こちらのURLをぜひご覧ください。https://autify.com/ja/webinars
伊藤：「ソフトウェアテスト自動化カンファレンス」などがあります。
小田：全国で開催されているJaSSTソフトウェアテストシンポジウムやJaSST nanoと称した月1回のオンラインコミュニティが開催されていますね。
他にもソフトウェアテスト自動化カンファレンスや、ソフトウェア品質シンポジウム、mabl関連であれば、外部のQAエンジニアの皆さまが中心となって運営しているmablers_jpがあります。隔月開催の夜イベントと、毎月昼開催の「めいぶるカフェ」の2つのスタイルで開催しているので、ご都合が付くタイミングで是非ご参加ください！11/22にはmabl Experience'23 Japanという弊社主催のカンファレンスもあります。
（Q）メンテナンスは長期的に使用するうえで重要なファクターと思いますが メンテナンスをしやすい機能を考える上で一番に考えることって何でしょうか
松浦：テストを短く保つこと、共通したステップはできるだけ再利用すること(Autifyにはステップグループという機能があります)、こまめにメンテナンスすること(Autifyではなんらかの変更を検知した際は「要確認」という表示が出ますが、これが出たらすぐ確認してテストシナリオを修正すると、結果的にメンテナンスが楽になります)
伊藤：日常業務で忙しい中でもいかにそれと並行でメンテナンスできるようにするか
小田：定型で使いまわすテスト内容をまとめられるFlowという機能があります。
ある程度ブロック化しておくことでメンテナンスコストも下がると考えます。
（Q）testability (テスト容易性)という考え方がありますが、test automatability (テスト自動化容易性）について、そもそも開発時に自動化前提で開発を進めるということは増えてきているようにおもうのですが、そういった背景を踏まえても、ここは、どうしても自動化が難しいという部分、そして、それに対して今後それを乗り越えるための各社のアプローチ案など参考までお伺いしたいです。
松浦：テスト自動化ツールを開発している当社ですら、すべてのテストを自動化しているわけではありませんし、どうしても自動化の得意・不得意があります。また、ユニットテストなど開発のより早い段階でテストした方がよく、かつそうしていればE2Eテストをしなくても十分な場面も多いです。これを踏まえて、自動化に向いたところを自動化し、そうでないところは手動あるいは違うツールを組み合わせると割り切るのが大事だと考えています。
小田：全てを自動化しないことです。本質的にはユニットテストが一番多く、次いでAPI(結合)テスト、E2Eテストは左記2つと比較すると数は少なく設計するべきです。
どうしても自動化できないテストで代表的なものには探索的テストがあります。少なくとも現在時点では自動化を無理に行うことに注力するべきではなく、品質を向上させるベストな方法の視点でテストを設計することが重要です。
（Q）各社さんにお聞きしたいです。 E2Eテストの導入に失敗する組織・やり方の特徴など有りましたら、教えて頂きたいです。
松浦：成功の可能性が高い組織にはいくつかの特徴があると考えております。まず組織に品質を大事にする文化があること、導入をリードする人(責任者)がいること、またリードする方だけでなくチーム全体で品質保証を行うと言う意識があること、ステージングに入ったらデプロイを回すなど作ったテストが必ず実行される仕組みにすること(CI/CDパイプラインに組み込むなど) が大切となります。
小田：(手軽に価値を感じていただくためには良いと思いますが、) 単純にテスト工数の削減を目的に導入すると本来の価値を発揮できないと考えます。
開発手法をよりモダンに変革していく過程でシフトレフトなどを行っていき、バグが早期に検出できるようになるなどの本質的な価値を感じていただきたいと思っています。
（Q）各スピーカーに、他社ツールの良かった点についてコメントを伺いたいです。
松浦：mabl : 痒いところに手が届く細かい設定ができる
MagicPod: 文章を組み立てるようにシナリオが作れる
伊藤：Autify: 物体認識を入れていたところ
mabl: 細かい機能がめっちゃ多い
小田：Autify: 生成AI関連サービス
MogicPod: モバイルテスト
（Q）今日はこのまま寝ずに午前2時までおきてますか？
伊藤：寝ます
小田：2時開始なので、4時まで見て、5時まで公式サイトの詳細なリリース文書を読んでいましたね。今年は銀座で優勝して5連覇（？）を達成しました！ありがとうございます！！
（Q）iOSに申請するときに、アカウント停止ボタンがみつからないとかある程度のパターンでリジェクト食らうので、最低限の決まりがあるのでそういったテストはAIで自動検出してほしい。
松浦：まさにそう言った、みんながやってるテストを提案できるのがStep Suggestionsなどで実現していきたいことなので、頑張ります！
伊藤：興味深い情報ありがとうございます！
（Q）今、ChatGPTを代表するLLMが注目を集めています。もちろん限界はありますが、マルチモーダル対応や、各社の競争、OpenSourceの急速なキャッチアップなど、パラダイムシフトの真っただ中にいるように感じています。 各社、そういったビッグピクチャーに対してのビジョンのようなものをお聞きしたいです！
松浦：Autifyでは創業当初からAIによるUI要素の認識技術に注力しており、シナリオを自動的に修復するSelf Healingや、スクリーンショットの差分を検出するVisual Regression機能の提供をしてきました。
この9月にAutifyが提供するAIに関する新情報や開発者ブログをお読みいただける「Autify AI Labs」を公開いたしました。（Autify AI Labs）
今後もAI技術の開発を進め、テストケースのデザインから、テスト作成、実行、そしてテストシナリオのメンテナンスに至るまで、全ての過程においてAIを活用した機能を随時リリースしていき、ソフトウェア開発プロセス全体の最適化を実現していきます。
伊藤：ノーコードとコードを融合していきたいです。生成AIも大きなテーマですね。
小田：ロードマップを常に公開していて、皆さまからのご意見も受け付けています。
特にニーズの高い機能は優先して実装していくので、是非[Product Portal]をご覧ください！
（Q）生成AIが進化するとUIもパーソナライズされ、画面そのものが自動でカスタマイズされるようなUXになる可能性もあるのではと勝手に思っています。 もし、そうなった場合には、テスト自動化もAI対応が必須のような未来がくる気がします。そのような自動化ツールへの備えを意識したことはありますか？
松浦：考えさせられる質問ありがとうございます。UIはどんどん動的になっていき、自動テストはその点で難しいものになっていっているので、その延長ではあるのではと思います。画像認識、Step Suggestionsなどの既にAI/MLを活用した機能をさらに強力に改善していきたいと考えています。
伊藤：興味深いです。考えたことなかったです。AI製品をテストするにはどうテストするか、という研究をしている方がいますが、そういう分野に近いなと思います。動的に答えが変わるものをどうテストするか
Q&Aコーナーは以上です。
次回のイベントレポートもお楽しみに♪
