こんにちは！TECH Street編集部です！
2024年11月22日（金）に開催した、 「テスト自動化エンジニア勉強会」のイベントレポートをお届けします。今回は各社の開発プロジェクトにおけるテスト自動化に携わるエンジニアが集まり、それぞれの知見を発表し、学びあう勉強会を開催いたしましたのでその様子をお届けします！
登壇者はこちらの方々！
飯田 勝巳／パーソルキャリア株式会社
城本 由希／エムスリー株式会社
Daishu ／株式会社メドレー
早速、内容を紹介いたします！
最初は、パーソルキャリア株式会社 飯田さんの発表です。
「doda」におけるテスト自動化戦略
飯田：本日は、「dodaのQAチームが実現したいこと」や「テスト自動化で実現したいこと」「dodaのQAチームが大切にしていること」の3点をお伝えしたいと思います。
「doda」サイト開発の歩みとQAチームができるまで
dodaサイト開発は、2017年頃までは外部ベンダーが中心となっており、内製エンジニア組織が発足したのは翌2018年です。その頃のdodaにはまだエンジニアは数名ほどしかいませんでした。そして2020年頃に内製組織の伸長や採用強化を行ったことで人がグンと増え、dodaのエンジニアも20名ほどになりました。そうなると、触っている領域によってチームが独自の動きをしてくるようになり、結果的にそれが品質に影響してくるという課題も出てきました。
それを受けて2022年頃からQA構想を開始し、実際に2023年4月からQAグループを発足させ活動をスタートしました。そのため、私自身はずっとエンジニアとしてやってきましたが、QAに携わるようになってからはまだ1年ほどしか経っていません。
QA構想当時の「doda」サイトの開発について
当時のdodaチームでは、2019年頃にスクラム化を進めていましたが、うまくいくチームもいればそうでもないチームもいました。そして、スクラムを続けるチームや、途中でやり方を変更するチームなど、各チームで最適な開発方法を模索していました。
2019年以降はアジャイルを進める動きがありましたが、テストや品質管理は従来のウォーターフォール型で進めているところが多く、結果的に開発プロセス後半の手戻りの負担や商用での障害などが増えていました。
また、dodaでは1人1人が開発案件を持ち、それぞれが独立して開発を進めていたため、「まるで仕切りのある某ラーメン店のような感じ」で開発を進めていました。
QAチームの設立について
上記のような課題を受けて、チームリードの負担が大きすぎて、チーム横断の課題まで考えられなかったり、今後も開発メンバーは増えることが予想されるので(いま現在、dodaのエンジニアは50名ほど)、今のままの開発プロセスでは厳しいと判断。また、昨年からベトナムでの開発チームも誕生したので、そういった方々が参画してくる中で品質担保の問題も出てきたため、QAチームを作ることになりました。
「doda」の開発プロセスについて
これまでのdodaサイトの開発プロセスでは、様々な課題がありました。
まず、基本的には1つの施策を同じ人が1人で開発するため品質が不安定になること。そして、サービスを開始してからすでに17年ほどが経過しているサービスであるため古い画面なども残っていますが、それらはテストコードが一切残っていませんでした。そもそもサービス自体も複雑で、dodaという1つのサイトで紹介事業と求人広告掲載をしているため影響範囲が広いです。そのため、思わぬところで不具合に直面することもしばしばありました。
QAチーム組成にあたってのスタンス
それらを受けてQAチームを作るにあたり、どのようなスタンスにするかの基本方針を大きく2つ定めました。
・従来型の品質担保はQAチームではやらない
いわゆるテストを行ったりリリース判定などの従来型の品質担保はQAチームでは行わないことにしました。勉強会を通じたスクラムチームのトレーニングや、各数値のモニタリングなどは行っていますが、実際に手を動かして品質担保をしてもらうのはスクラムチームに依頼しています。
その背景としては、｢QAチームがいないと品質担保ができない｣という世界を避けるためです。そしてQAチームがテストをする人たちとなってしまうと、開発チームのスケールに合わせてQAチームもスケールする必要が出てきてしまうからです。
・アジャイルなQAとして自動化やプロセス改善を推進する
それでは何をするのかというと、アジャイルなQAとして自動化やプロセス改善の推進などを行っています。中でも行っていることは大きく2つあり、Scrum of Scrumsの運営やスクラムマスターへのコーチング、そしてテスト自動化などプロセス高度化の推進です。今日はテスト自動化やプロセス高度化についてのお話をしたいと思っています。
テスト自動化の目的について
まず、なぜテスト自動化を行いたいのかという目的の整理からはじめました。
テスト自動化は目的ではなくあくまで手段ですが、では目的は何かというと、「開発プロセスの高度化やチームが安心・安全にプロダクトのグロースに取り組める環境や文化づくりを行うこと」です。そのため、テスト自動化をTDD／BDDなどの開発プロセスの高度化につなげるための手段として私たちは進めています。
E2Eテスト自動化を進めるにあたって
その中でも、E2Eテストを行うにあたっての基本方針も定めました。
E2Eテストはやろうと思えばなんでも出来てしまいますが、何もかもをE2Eテストとしないということを基本方針の1つとしました。必要なものを必要な分だけE2Eテストでまかない、それ以外のところは他の方法でまかなうとしました。
また2つ目として、「全部をQAチームで持たない・考えない」ということも決めています。dodaは手動テストで行っていて、テストコードも何もない状態からスタートしているので、最初の初期運用はQAチームで考えますが、その後の整備や維持についてはスクラムチームに委ねることを前提としています。また、単体テストについてはスクラムチームに責任を持って整備・維持をしてもらうことにしました。
もうひとつ注視した部分はE2Eテストはこれまでも歴史があるため失敗事例もたくさんあると思っています。そのため、今回のテスト自動化推進が失敗する可能性も十分にあったので、維持や運用ができるかどうかということを第一優先としました。ダメであればすぐに捨てて、違う方法を検討するという前提で進めています。
技術選定について
E2Eテスト自動化方式は大きく分けてコーディング方式とノーコード方式がありますが、私たちは敢えてコーディング方式を選択しました。
理由としては、コーディング可能なエンジニアを確保できるということと、コーディングのみでのテスト自動化運用が困難な場合、ノーコードへの転換や併用は比較的簡単にできますが、反対にノーコードを前提としてテスト実装したあとのコーディングへの転換はコストが高いからです。
製品選定について
次に製品選定をするときに特に重要視していたのは機能面や実行速度です。
Playwrightを選んだ理由としては、並列実行が可能で実行速度が高速、そして機能面で充実しているためです。
構成図
結果的に上図のような構成となりました。
自動テストを進める上で出てきた課題
ただ順風満帆なわけでもなく大きく3つの課題が出てしまいました。
・自動テスト運用開始前にテストコードを大量に作ってしまった
・自動テストシナリオをレビューする体制を事前に考えていなかった
・実際の構築や実装は海外の開発拠点で進めたが、連携面で不足があった
まず1つ目に、自動テスト運用開始前にテストコードを大量に作ってしまいました。
実行環境の構築の調整が難航したこともあり、先行してテストシナリオやテストコードを量産した結果、テストコードの修正が大量に発生してしまいました。→まずは、運用できる最小のパッケージを作ることを最優先すべきだったと考えています。
そして2つ目に、自動テストシナリオをレビューする体制を事前に考えていませんでした。手動テストと自動テストで、シナリオとして考慮すべきポイントが異なるということを考えていませんでした。
そして3つ目として、実際の構築や実装は海外の開発拠点で進めましたが、連携面での不足がありました。海外拠点が発足間もないということもあり、ドメイン知識や社内ルールを日本側が伝えきれていませんでした。→日本側の有識者をもっと巻き込む必要があったと考えています。
これからテスト自動化をはじめるなら
そこで、これからテスト自動化をはじめるならば、以下のことを念頭に置くことをおすすめします。
- まずは小さく、可能な限り早く自動テストのサイクルを回す。→これが一番大事だと思います。
- 自動テストシナリオの粒度、作成方針は事前に決めておく。
- 維持や継続ができることはとても大事ですが、それと同じくらいにダメだったときのことを考える。
以上の3つが大切です。
この先やりたいこと
E2Eテストの自動化で終わるのではなく、まだまだ改善の余地がある状況なので、まず1つ目に、テストデータ作成自体の自動化を行いたいと思います。
今はまだテストデータを作ってもらって実行している状況なので、テストデータ作成自体の自動化も進めています。
そして2つ目は、テスト設計やシナリオ作成の自動化です。できればテストコードの作成までを考えています。こちらは生成AIを利用して、仕様書から設計書からテストケースを自動生成する製品の導入を検討しています。そちらにはPlaywrightの自動生成機能も備わっているので、E2Eテストへの組み込み可否もあわせて判断したいと思っています。
まとめ
私たちQAチームが実現したいこととしては、継続的かつ迅速なフィードバックと、チーム全体で品質を担保する仕組みをつくることです。
そしてテスト自動化で実現したいことは、テスト自動化はあくまで手段であり、目的はチームが安心安全にプロダクトのグロースに取り組める環境や文化づくりをすることです。
最後に、QAチームが大切にしていることは、全チームが安心してプロダクトのグロースに取り組める環境づくりや、主体的に改善し続ける組織・文化づくりを大切にしていて、そしてdodaに関わる全ての人がハッピーになれるようなことをこれからも続けていきたいです。
私からの発表は以上です。
飯田さんありがとうございました！
続いては、エムスリー株式会社 城本さんの発表です。
テスト自動化のアプローチ ～範囲別の採用ツールと手法
城本：本日お話することは、「E2Eテストツール導入時の課題とアプローチ」と「APIテスト自動化時の課題とアプローチ」の大きく2つです。
エムスリーのQAチームの立ち位置
まず、社内での立ち位置ですが、QAチーム自体は組織横断のチームとして存在しています。
事業システムを持っている事業チームがあり、普段は自分が担当する事業チームを持っていて、そのチームの開発エンジニアと一緒に仕事をすることが多いです。QAチーム自体は組織横断のチームなので、担当サービスで挑戦してみて良かったことなどを組織全体で展開しやすくなっています。
E2Eテストを行う上でやりたかったことは、テストをガンガン回して、それによって開発を高速に安心して進めたい、ということでした。
背景：エムスリーでのテスト自動化の状況（2020）
課題としては大きく2つありました。
- テスト実施、リグレッションに時間がかかっている
- 自動テストの作成、メンテナンスが一部の知識のあるメンバーに集中してしまうため全体展開が進みづらい
1つ目としてはテスト実施、リグレッションに時間がかかっているという点です。一部のシステムではE2Eテスト自動化に着手できておらず、手動テストで対応していたため時間がかかってしまっていました。
そして2つ目は、自動テストがあるシステムについても、自動テストの作成やメンテナンスが一部の知識のあるメンバーに集中してしまうため、全体展開が進みづらいという課題がありました。メンバー内には開発のバックグラウンドがないメンバーもいたため、一部のメンバーに集中してしまうという状況になっていました。
E2Eテストでカバーしたい範囲
E2Eテストでカバーしたい範囲は、ユースケースで通る範囲でした。
背後で複数のマイクロサービスが動いているようなユースケースをカバーしたいと考えていました。
検討内容と狙い
検討した内容としては、2020年当時に広まりつつあったローコードツールで課題に挙げたことに対応できないか、ということです。
狙いについては、まずは課題の解消です。ローコードツールのため、開発のバックグラウンドがないメンバーも全員が扱えます。また、クラウドで実行できる環境を用意してもらっているので、自前で実行用の環境を準備する必要がない、という点も魅力でした。そして副次的な効果としては、mablでは標準機能でカバーできる範囲が広がりました。標準機能で簡単なスモークテストやVRTを実施する機能がついていて、リンク切れなどの検知は自動で行えます。
アプローチ：スモールトライアル
こうして、担当するチームでスモールトライアルを開始しました。
トライアルで行ったことは、ペアプロ的な対応です。チームには開発のバックグラウンドがないメンバーや自動テストを作ったことのないメンバーもいますが、1～2ケースを一緒に作れば、経験の浅いメンバーもすぐに使い始めることができました。それによって、出来る感覚をつかんでもらうということも大事にしました。結果的に、体感では8割程度がレコーディングしたとおりに動かせるようになりました。
トライアルの結果、テスト対象システムが自動化と相性の良いものであれば、レコーディングとGUIで自動テストケースを作成することが可能となりました。
アプローチ：全体への拡大
担当のチームで成功体験を積んでから、組織全体への拡大をしていきました。
このときに行ったことは、「複数チームで運用を行うためのルール作り」です。複数チームでも扱いやすくするために、命名規則やクラウド実行タイミングのルール整備を行いました。そして並行して質問しやすい場の整備も行っています。週一での勉強会や自動テスト関連のSlackチャンネルなどを整備しました。
その結果、現在は利用チームが7チームに拡大し、mablであれば自動テストに対応できるメンバーも増えました。
mabl導入の結果
mablを導入した結果、テストをガンガン回したい、開発を高速に安心して進めたいという当初の2つの狙いは概ね達成することができました！
APIテスト自動化時の背景と課題
続いて、APIテスト自動化時の課題とアプローチについてお話します。
こちらも、やりたいこととしてテストをガンガン回して高速に安心して進めたいということでした。
そして2022年当時の背景としては、まずプロジェクトの状況が関係しています。
背景：テスト自動化の状況（2022）
リニューアルのプロジェクトが始まり、大きいサービスからパーツを分けてマイクロサービス化することとなりました。それにより大きいサービスの毎週の定期リリースから外れ、都度リリースができるようになりPDCAを回しやすくなるというメリットはありますが、リグレッションの機会は増えているという状況でした。
自動テストのカバー状況としては、モバイルアプリは自動テストがなく、PCやSPのWebアプリはmablなどでカバーされています。
そしてリリース状況としては、通常のリリース向けのテスト実施も必要で、担当のQAは開発バックグラウンドがあったので、コーディングにも積極的に取り組む姿勢がありました。
APIテストでカバーしたい範囲
テストしたかったのは、基盤と各サービスをつなぐAPIの部分です。
検討内容と狙い
プロジェクト状況に関しての狙いとしては、3つあります。
- 自動テストを整備し、増えたリグレッションテストの回数に対応したい
- 自動テストでカバーできる範囲を増やしたい
- リソース状況に関しては、外部仕様に変更がないものは開発エンジニアが自動テストを回すことでQAリソースの逼迫を防ぎたい
ここで補足ですが、事前にテスト実施について以下のようなルールを定めていました。
仕様自体の変更や、ロジックに変更が入ったものはQAチームによるテストを行う。そして外部仕様に変更が無いものや軽い変更については開発エンジニアがテストを行う、としていました。
アプローチ
行った対応としては、まずscenarigoを使用して1案件を実施しました。するとAPIテストを自動化する方向で解決しそう！という実感を得ることができました。そしてその後はrunnに置き換えて対象範囲を拡大していきました。こちらの方がチュートリアルが整っていて導入がしやすかったです。
結果、どのように変わったのかというと…
自動テスト整備前は手動テストを行っていたので、実行に半日ほどかかっていました。
整備後はSlackのワークフローで完結するようになったため、テスト実施の実働が短縮されました。ほぼボタン1つで済んでいます。
まとめ
APIテスト導入の結果「システムテストをガンガン回したい」「開発を高速に安心して進めたい」という当初の狙いはmablやrunnを導入したことで、おおむね達成できたと言えます！
今後は新しく出てきた課題に対応していきます。
私からの発表は以上です。
城本さんありがとうございました！
続いては、株式会社メドレー Daishuさんの発表です。
持続可能なE2E自動テストを目指して
Daishu：本日は、「持続可能なE2E自動テストを目指して」というタイトルで発表いたします。
弊社は、医療機関と患者それぞれにサービスを提供していますが、本日は医療機関が利用する「CLINICS」というWebアプリにおけるE2Eテストについて話します。E2EテストはMagicPodというノーコードテストツールを利用しています。
MagicPodで作成できるE2Eテストの例
MagicPodができることの例を紹介します。CLINICSのユーザーストーリーの例として、患者さん向けのアプリから診察予約〜CLINICSで診察して処方箋を別サービスへ送信〜患者さんに向けてクレカ決済を行うといった流れがありますが、1つのE2Eテストで1パス確認可能です。
実ブラウザで動作するので、MagicPodであれば異なるプロダクトをまたいだ一気通貫のE2Eテストをすることができます。
E2Eテストと向きあった1年間のおさらい
E2Eテストを作り始めたのは1年ほど前ですが、当時は不安定でほとんど不具合を拾えず、自動化の恩恵はあまり受けられていませんでした。
その後は自動テストも拡充されていき、最終的にMagicPodのヘルススコアで100点を取れるまでになりました。
参考：改善についての詳細はブログをご覧ください。
E2Eテストの信頼性と向き合ってMagicPodのヘルススコアが100に達した話 | MEDLEY Developer Portal
E2Eテストの充実化に伴い生まれた新しい課題
MagicPodによってE2Eテストが充実してきましたが、今度はE2Eテストの実行時間が長すぎる！という問題に直面しました。
テストケースの数が増えて実行時間が長くなるのは当然なのですが、それにしても長すぎると感じるように…。そこで、原因について考えることにしました。
E2Eテストの実行時間が長くなった（巨大化）した主な原因
主な原因は2つあります。
- 手動テストの工数削減を最優先にしてしまった
- 細かい仕様も「ついでに見ておくか」という気持ちで実装してしまった
まず1つに、手動テストの工数削減を最優先にしてしまったことです。手動テストは自動テスト用に最適化されていないので、そのまま実装するとシナリオが長くなります。そして、｢この確認項目は必要なのか？｣という精査も省略してしまっていました。
そして2つ目に、MagicPodは実装が容易にできることもあり、細かい仕様も｢とりあえず見ておこう｣という気持ちで実装していたことです。開発側の自動テストの存在も認識していましたが、QAとして自分たちの手元で管理したい、という気持ちもありました。そもそも開発側の自動テストがいつ行われているのかも確認していなかったので、それならば自分たちが管理しているところで担保したい…という気持ちがありました。
E2Eテスト実装当時の考え方
MagicPodはとても簡単に実装できるので、ついでにバリデーションの検証も入れようとなってもたった3行でできてしまいます。｢そもそも、それをE2Eテストに含めても良いのか｣という精査をしなかった点は大いに反省しています。
振り返ってみると、自動化を頑張って進めた結果、やりすぎてしまってメンテナンス不能になる…という状態になりつつあったと思います。
持続可能なE2Eテストを目指した取り組み
では、ここから本日のメインテーマである、持続可能なE2Eテストを目指した最適化の取り組みについてお話していきます。
まずはじめに、開発チームが利用する自動テストを理解しました。開発者のテストコードを調べてみると、私たちがE2Eに実装した確認内容と重複していたことがわかりました。
そこで、開発チームとSyncしてCLINICSで利用する自動テストを整理し、どんな自動テストがあるのかということをまず把握しました。実際に確認するとテストフレームワークが整備されていて充実していることがわかりました。
ふたを開けてみると、CLINICSはいつのまにかテスタビリティの高いプロダクトになっていました。しかし最初からそうだったわけではありません。
それは要するにアプリケーションが持続可能なE2E自動テストを目指して成熟していくと、テスタビリティが向上するということです。
最初はE2Eテストでしか担保できなかったものが、プロダクトに関わるメンバーの増加、基盤のリアーキテクトなどを経てテスタビリティが増して、他の領域の自動テストでもカバーできるようになってきたという流れだと思っています。
そのため、現在のプロダクトのテスタビリティを正確に把握することはE2Eテストを管理するQAにとっても重要です。
それぞれのテストの責務について確認すると…E2Eテストの役割がUnitテストと一部重複していたことが分かりました。
そして、いつテストが動いているのかについても確認すると、統合ブランチにマージされるまでに担保する仕組みがあり、それを通過したあとにE2Eテストが動くことが分かりました。私が管理しているMagicPodは毎日統合ブランチで動くので、マージされてすべてのテストを通ったものにE2Eテストを行うという流れです。つまり、E2EテストにUnitテストと同じテストがあるとWチェックにしかなりません。
開発者のE2Eテストに対する期待値ヒアリング
開発者にE2Eテストに対する期待値をヒアリングしたところ、以下の4点が出てきました。
- 主要な業務シナリオの担保
- Backendを介したFrontの担保
- 実ブラウザでしか検証が難しいもの
- CLINICSと密結合な外部サービスとの連携
そこで改めて、一般的なE2Eテストの役割について理解してみました。
E2Eテストのベースはユーザーストーリーで、テスト対象は完全に統合されたシステム全体です。そして想定されるバグはユーザーストーリーそのものの失敗。また、ロジックの網羅はUnitテストに任せて、E2Eテストはシナリオベースに特化する、といった見解もありました。
そうしてCLINICSにおけるE2Eテストの役割を再認識したことで、CLINICSにおけるE2Eテストのあるべき姿が整理され、開発とQAの間で認識を揃えることができました。
実際（診察受付）のストーリーで自動テストの棲み分けを考える
実際のCLINICSのユーザーストーリーに対するE2Eにおける自動テストの棲み分けを考えてみます。まず患者さんが来院し、病院の事務員さんが患者さんの情報をCLINICSに入力します。するとそこでまず、その患者さんが新規か既存かで分岐が発生し、登録が行われて通信が発生し、受付ができるという流れがあります。その中で確認するポイントは入力フォームのバリデーションや登録時のエラーレスポンスなどいくつかあり、それをすべてE2Eテストで見ていくのは無理があります。よって、その部分は単体テストを行うという棲み分けをしています。
実際にE2Eテストをするべきは、既存患者のパターンでも、新規患者のパターンでも受付が通せるかという2パターンのみです。
大事なことは、「開発者のテストをブラックボックスにしないこと」です。
中身を見ないでE2Eテストを実装すると｢あれもこれも｣となってしまい、棲み分けが崩れやすくなってしまいます。
E2Eテスト最適化の考え方として、開発者のテストを確認したうえでE2Eテストを実装することです。
単体レベルで入れたいものは、開発者のテストに追加依頼できるとベストですし、それが正しいフローだと思います。
E2Eテストの確認内容をブラックボックスにしないことが大切です。
私たちはマッピングシートを使って開発者と共有しています。
自動テストによる障害の再発防止の考えを改めた
そして自動テストによる障害の再発防止の考えも改めました。
障害を振り返り、再発防止を検討する際に、私は真っ先にE2Eテストの実装をしましたが、本当にE2Eテストで良いのか、という精査が必要です。
障害の再発防止は一度入れると削除しづらいため、E2Eテストの実行コストに繋がりやすいです。そのため、障害の再発防止にE2Eを利用するのは最終手段だと考えています。
まとめ
手動テストの自動化・E2EのUnitテスト相当の項目が増えていくと、
テスト巨大化→メンテコスト増→容易に流せない→E2Eテストの価値貢献の低下を招きます。
E2Eテストの巨大化を防ぐために
自動テスト全体の最適化を行うことで、高品質と価値提供のスピードアップに繋げることができます。
持続可能なE2Eテスト
プロダクトのテスタビリティを理解して、開発者とE2Eテストの役割の認識を揃えることで、メンテ不能に陥らず、持続的に価値貢献できるE2Eテストを目指せます！
こうした改善を行うことで、開発者からE2Eテストの要望を頂けるようにもなりました。
そして、全体を見据えて再発防止策を考えられるようになり「いきなりMagicPod！」ではなく、｢何が良いのか｣を話せるようになっています。
テストが増えるというのはプロダクトの成長でもあるので、今は必要であればE2Eテストを増やしても良いと考えています。しかし、他の自動テストとのバランスが崩れないことが大事なので、バランスを保って増やしていくことが大事ですね。
私からの発表は以上です。
Daishuさんありがとうございました！
続いては、Q&Aコーナーです。
Q&Aコーナー
（Q）E2Eに含める基準などがあれば教えて欲しいです
飯田：E2Eテストの対象範囲は、「単価」。売上に直接関わるような重要な仕様画面や、頻繁に改修が入る画面、ユーザーが頻繁に利用する主要な画面などを中心に選定していました。
城本：ハッピーパスのもので複数マイクロサービスを通るものを優先で入れたいと思っています（現状は過去のリグレッションテストケースをそのまま自動テストケースにしていて、ユニットテストに寄せてもいいと思われるものも入れています。どこかで整理したい）
（Q）「手動テストと自動テストで考慮すべきポイントが違う」という部分、具体的にどのようなことが違ったのか、お聞きしたいです。私自身、やるとなったら「手動でできていることを自動化する」という考えで進めると思うので、同じようなことにぶち当たってしまいそうな…
飯田：シナリオテストでは、一連のシナリオで実施できるように設計することが一般的です。自動テストでは、より細かい粒度で設計を行う必要があります。
例えば、どのデータを使用してどの範囲までテストを行うのかを明確に定義し、シナリオを細かく分解する必要があります。さらに、人が直感的に判断している「あいまいな確からしさ」を機械が理解できる形で明文化し、確認ポイントを具体的かつ機械的に判定できる基準として落とし込むことが重要です。こうした準備が、自動テストを正確かつ効率的に実行するためのポイントになります。
（Q）自動化の失敗事例はどのようなものがあったのでしょうか。
飯田：テスト自動化の導入にあたり、開発チームへの理解を得るタイミングが遅れてしまったことが挙げられます。ある程度構築のめどが立ったところで開発チームを巻き込んだため、運用面でスムーズに進まない部分が出てきました。もっと早い段階で開発チームを巻き込んでいれば、よりスムーズに進められたなと後悔したことがありました。
城本：盛り盛りのテストケースにしてしまい、膨大なテストを作成してしまったことがあります。この結果、エラー箇所にたどり着くまでに時間が掛かってしまいました。この経験を踏まえ、現在は実行時間の目標を設定するなどの対策を講じています。
Daishu：自動化が属人化してしまっています。現在、レビューの実施やコードへのコメントを入れて、属人化の解消に向けて取り組んでいます。
（Q）初自動化でオープンソースのツールから試みるのはやはり難しいでしょうか？？
飯田：Playwrightというオープンソースライブラリを使用しています。ハードルはそれほど高くなかったです。というのも、コーディングできるエンジニアを確保できていたことが大きなポイントです。Playwrightを選んだ理由は、課金が発生しないため「とりあえず試してみる」ことができたからです。そのため、オープンソーススタートでやっています。
城本：自動化の成功は、作成やメンテナンスを行う担当者のスキルに大きく左右されると思います。
私たちはサポートが付いているツールを選ぶことで、初期フェーズの運用がしやすかったと感じました。
Daishu：ゼロイチのフェーズが最も難しい部分です。この段階で適切な理解やスキルを持つ人がいれば、オープンソースでも実現可能です。弊社の場合はMagicPod のようなサポート付きのツールを活用し、初期段階からサポートを受けることで、スムーズに進められました。
（Q）QA組織がまだありません。QA組織を設立する最大のメリットを教えてください。具体的な事業インパクトもあれば・・
飯田：昨年４月にQAチームを立ち上げました。現場に近い人たちは日々の業務に追われていて、横断的な改善や将来的な課題に取り組む余裕がないことが多いです。
QAチームが関わることで、全体像を俯瞰してみれるので将来を見据えた提案が可能になり、結果として事業全体の品質向上に貢献できます。
城本：プロダクト全体を横断的に把握できるのが大きなメリットです。プロダクトが増えると、各開発エンジニアは自分の担当するプロダクトについては詳しいものの、連携している他のプロダクトには詳しくないケースが増えます。QAがそのスキマを埋め、プロダクト間の影響を適切にサポートすることで、トラブルの未然防止やスムーズなリリースにつなげることができます。
Daishu：E2Eにおけるリグレッションテストが拡充されることだと思います。QAは横断的に各チームの機能リリース状況、重要度などを把握しています。そのため、機能リリースごとにリグレッションテストとして追加必要か判断してテストケースを用意できます。
自動テストツールが導入されると、作成したケースをinputにする形でQAチームがE2E自動テストのオーナーになることもできます。E2E自動テストを拡充する役割をQAチームが持つことで、開発チームは他のテストレベルの自動テストの拡充に集中するといった分業ができます。
（Q）テスト自動化関連で「これはウチならではの変わってることだろうなー」を教えて欲しい
飯田：QAチームの立ち位置が変わっています。「品質担保をやらない」というスタンスのQAチームが自動化を推進しています。
スクラムチームや開発チームが自立して品質を確保できるよう、補助を行っていく役割を担っています。
城本：mablに対して、積極的に機能のリクエストを挙げているチームでもあります。
Daishu：テストツールの提供機能にない操作を行いたい場合、社内でAPIを作ってもらい、それをLambdaで処理する仕組みを自作しています。
（Q）みなさん、その自動化ツールを選んだ理由を聞きたいです
城本：開発経験のないメンバーもいるのでローコードで作成できる機能が欲しかった。QA環境でプロキシを利用しており、プロキシ経由でテスト実行できる機能が必要だった。これらを満たした上で料金やサポートを比較して決めました。
Daishu：iOS/Android/Webと3つのプラットフォームを提供していることもあり、モバイルに対するテストに強みがあるMagicPodを採用しました。
（Q）テスト自動化を開始したときって、各社さん障壁ってありましたか？社内文化とか体制とか予算とか。
城本：時間をどうやって工面するかが大変でした。チームによっては通常のチケットのQAを遅らせてテストケースの自動化を先にやってしまう判断をしたこともあります（大規模なリファクタ予定があったため説明しやすいという背景もありました）
Daishu：障害の再発防止がE2Eテスト一択になってしまったことです。MagicPodの社内認知を高める目的もあり、率先して再発防止をE2Eで受け持った時期がありました。その結果、Unitレベルの再発防止もE2Eで担保して欲しいという流れを作ってしまいました。発表にもあった通り、現在は解消しています。
（Q）「E2Eが必要なもの」は誰がどのように選別した（している）のでしょうか
城本：基本的にはQAチームが作って開発エンジニアにレビューしてもらう形です
Daishu：QAエンジニアが決めています。新機能リリース後、この機能のE2Eテストが欲しいと依頼をいただくケースもあります。
（Q）自動テストと手動テストで考慮すべきポイントの具体的な例を知りたいです。
城本：自動テストだと機械的にOKだと判別できるポイントの確認が必要。意外と人の目は一度にいろんなところを見ているので、自動テストで何を確認したいかはあらかじめ決めておいた方がすっきりしたケースになると思います（人の目で見てるもの全部盛り込むと長大なケースになりがちです）
Daishu：城本さんの考えと同じで、確認必須なものに絞ってAssertionを入れて、その他はE2Eなので手順が通ることで担保とすると綺麗に書けます。
E2Eの手動テストについては、私は自動化を見据えて作ることが多いので手順と期待値は分けて記載、期待値を最小限に絞るなど行います。
（Q）みなさん、いま使ってるツールへの要望（不満？）とか、今後目指したいことなんかも聞きたいですね
城本：VRT機能がついていますが、システムが自動生成するIDなど差分が出るのが正しいところまで差分として検出されるので除外エリアの機能が欲しいです。
E2Eとユニットテスト、その他のすみわけがあまり決まってないので大まかな方針決めて整理したいです。
Daishu：MagicPodの方から絶賛開発中と伺っていますが、for、whileといったループのコマンドがない (※ 2025/2/9リリースにて対応可能に！) ので、泥臭い書き方しているテストがいくつかあります。
今後目指したいことは、開発チームのようにE2Eもテスト対象の特性に合わせてフレームワークを使い分けることを検討しています。ですが、MagicPodさんが続々と新機能をリリースして頂けるので、E2EテストはMagicPodだけですべてカバーできるのでは？とも思わせて頂けています。
（Q）自動化はどの分野でどの程度できるのですか
城本：システムとかユースケースによるのですが、Webなら体感ですが7割程度は行けるのではないかと思います。そのテストは自動化したほうが効率がいいのかも考えた方がいいかとは思います。
Daishu：各レベルの自動テストの得意領域の合わせ技で、ほとんどカバーできると思っています。
弊社の自動化できていない代表例としては、オンライン診療におけるビデオ通話の疎通確認があります。これは映像や音声の識別が難しいことが理由ですが、それ以外はほとんど網羅できている印象です。
（Q）今回E2Eテストにする、と決めた範囲から、今後範囲を広げていくことは考えていないですか？
城本：あり得ます。ただE2Eの範囲を広げていくというよりかは、E2Eでやる方がよいものを整理してAPIテストやUnitTestに寄せる整理もして自動テストでカバーできている範囲を広げるという方向にしたいと思っています。
Daishu：全然あります！プロダクトのテスタビリティに応じてE2Eテストの対象は変化すべきと思うので、新規プロダクトを担当する場合はUnitレベルの確認もE2E入れるケースもありえます。
（Q）自動テストで実施したテストケースの管理はどのようにしていますか？
城本：mablを正として管理するとなっています。一応ユースケースとどのmablのケースが紐づいているかは管理してますが、時々メンテナンスが追い付いてないことがあります。
Daishu：以前は自動化した手動テストケースも仕様変更に追従する形でメンテしていましたが、Wメンテが辛いので自動の実装をテストケースとして管理しています。外から見えづらい点は機能一覧と自動テストURLをマッピングしたシートを用意して解消しています。
（Q）自分のチームだと自動テスト作成が属人化しちゃっているのですが、属人化防止とかってどうしてますか？
城本：コメントのルールなどを定めて他の人が見ても何を意図しているのか分かるようにしています。メンテナンスなどは自分が作成していないものもなるべく担当してもらうようにしています。
Daishu：自動テストのデイリーチェックを当番制にするのが良いと思っています。テストが失敗すると実装が間違っていないか見る必要があるので自然と理解が深まります。そもそもデイリーチェックが最も俗人化すると辛い部分 (休んでいる日も自動テストの確認だけしなきゃいけない等) と思っていることもあり。。
（Q）自動化導入の検討開始から導入まで、どのくらいの時間がかかりましたか？
城本：4か月くらいです。検討を2020年5月くらいから開始して、トライアル実施、ミニマムのプランでの契約が同年9月でした。
（Q）mablいいよねー！他のツールも選定しましたか？選んだ理由もお聞きしたいです
城本：操作内容を記録して、テストケースとして利用できる機能はほとんどのツールに共通して備わっています。
ただし、私たちにとって「プロキシを利用してテストに使いたい」というのが必須条件でした。この要件を満たしていたのが、当時の選定においてmablだったため、採用しました。
（Q）みなさん、採用されているテストは１種類のみでしょうか。例えば、Seleniumを使用したE2Eテストと、React Testing Libraryのようなユニット単位でのビジュアル的なユニットテストの両方を採用しているのでしょうか。
城本：mablとPlaywrightとrunn、一部既存のSeleniumを使っています。画面のあるE2Eは基本mabl、開発エンジニアが作成・メンテしているチームだとPlaywrightもあります。runnは画面がなくAPIを確認したい部分などで使い分けています。
Daishu：E2EテストはMagicPodの1種類で、UIやVRTはStoryBookやregisuitなどを導入しています。各テストレベルで利用するテストフレームワークの詳細は発表資料をご覧ください。
（Q）自動化導入の予算感はどのくらいなのでしょうか？
城本：具体的な数値はお答えできないので、ROIが明確に説明できればというところです。
（Q）やっぱオープンソースからってハードル高いですかね？（いまやろうかなって悩んでます。やっぱ優秀なツールさんに頼る方がいいのかなぁ）
城本：自動テストケースの作成・メンテナンスをする方が開発の知識があるかによると思います。あるなら初めからOSSもありだと思います。ない場合はツールに頼った方が初期の学習コストは抑えられると思います。
Daishu：テストツールも中身は何かしらのOSSを踏襲して動いていると思うので、ツール経由で自動テストの勘所を理解するアプローチも有りだと思います。そして、将来的にツールからOSSへの移行するという考え方も良いと思います。
（Q）チーム内の学習意欲が低い場合、どのようにツールの知識を共有していますか？
城本：1,2ケース一緒に作ってみる等になると思います。なるべく手を動かしてもらう機会を増やすことで対応すると思います。
Daishu：新規機能のQA担当が自動テストを作成するという流れを作るのが良いと思います。自動化しなければ、その機能のE2E領域はノーガードとなるので、必然的に自動テストと向き合うことができ、学習に繋がると思っています。
（Q）やっぱ「安心」がキーワードなのかな。これは各社さん同じですよね。第一が安心！だとしてら第二はなんですか？
城本：「気軽」だと思います。ボタン一発とかコマンド一発で済むことが分かっていると動かしたり依頼したりするのも気軽にできるという声をもらってます
Daishu：「スピード」でしょうか。自動テストのメリットの1つとしてリリース物の保証を素早く行えるので、より早く市場に出すことができます。
（Q）自動テストケース作成のしきいが低い（誰でもお手軽に作成できる）と、似たようなテストケースがいっぱい作成されて無秩序な状態にはならなかったのでしょうか？
自動テストケースの管理について、コツやポイントなどあれば、教えていただきたいです。
城本：レビュールールを設けています。作成したテストケースはチーム内でレビューを行っています。そのため、チーム全員が内容を把握できているので、似たようなテストケースの乱立は防げています。
レビューを設けたり、事前にユースケースを決めておくと、自動テストの運用がしやすくなると思います！
（Q）APIテストの実装/メンテナンスは開発 or QAチームのどちらで行っていますか？
城本：入りの実装はQAチームが主導で行い、メンテナンスや加筆等は開発に依頼する形をとっています。その際確認観点やテストケースのルールについてはQA側で作成し、品質の意識の統一を行なっています。
（Q）最後のページにあった、今後の課題とは具体的には何でしょうか？
城本：今後の課題は、チームの拡大を進めていく点です。
また、mablの利用という点だと、クラウド実行で課金が発生するため、限られたクレジットの中でどのように運用していくかが課題となっています。
（Q）自動化をする範囲と手動でテストをするべき範囲のすみ分けはどのようにしていますか？
城本：自動化の難易度と使用頻度、（もし分かれば）改修の頻度で決めてます。難易度が低くて使用頻度が高いものからカバーしてます。
Daishu：リグレッションテストでいえば「自動化できるかできないか」です。自動化できないものは手動テストになりますが、これは最小にしたいので手動テストを追加する際は「本当にこのテスト必要か？」はかなり厳しめにみています。
（Q）紹介されていた議題とは異なる内容で申し訳ありません。
MagicPodでは、「固定値」に関しては共有変数等でスケジュールを跨ぐ場合でも保持できますが現状、自動採番や時間等の変動する値に関してはスケジュール間で保持、受け渡しする方法が無いと感じていますがこちらについて何か解決策等をお持ちでしょうか？
城本：MagicPodで対応する機能があるか即答出来ないのですが、mablでは共有変数で受け渡す事ができます。
https://help.mabl.com/hc/ja/articles/17750199158804-%E3%83%86%E3%82%B9%E3%83%88%E9%96%93%E3%81%A7%E3%81%AE%E5%A4%89%E6%95%B0%E3%81%AE%E5%85%B1%E6%9C%89
（Q）自動化の導入を検討している段階ですが、ノーコード型、コード型、選定理由等聞きたいです
Daishu：iOS/Android/Webの3PFで自動テストを導入したかったため、導入までのスピードを重視したことと、対応できるQAEも1名だったためメンテコストも鑑みてノーコード型としました。トライアルした結果、やりたいテストはノーコードでもコード型でも変わらずにできたため (米山)。
（Q）持続可能な自動テストとするために心がけている事は何でしょうか？
Daishu：まさに私の発表のタイトルなのですが、開発/QAで協力して自動テストの最適化に向き合うことだと思います。様々なテストツールの出現により、E2E領域の自動テストをQAチームでカバーしやすくなったことによる工数的メリットを最大限活用すべく、両者協力して適切なテストピラミッド/トロフィーとなる自動テストのバランスを目指し続けたいです。
（Q）MagicPodめっちゃいい。弊社もユーザーです。こちらも一番の推しポイント聞きたいです。選択したポイントを。
Daishu：正直な話をすると「従量課金がない」ことが一番の推しポイントです。デバッグ実行のたびに課金が発生するような仕組みでは、コスト面での負担が大きくなるため、月額課金制は助かります。また、Slackのオンラインコミュニティが活発で、ユーザー同士の情報共有がしやすい点や、新機能が迅速に実装される点も魅力的です。
（Q）やりすぎちゃった問題、むちゃわかります。気を付けた点、乗り越えた点で生々しいお話あれば聞きたいです。
Daishu：発表した通り、開発チームの自動テストを知ってE2Eの認識を揃えることが最も重要だと思いますが、それ以外だとテストケースを定期的に見直して軽量化するなどしています。例えば、実行時間がやけに長いとかFlakyで落ちやすいとかは、やりすぎているケースが多いです。
（Q）MagicPod良いですよね！弊社もMagicPodを導入しています。そして、同じような課題に直面しております。。。
Daishu：ぜひ開発者とSyncして各自動テストの棲み分けについて考えを揃えてみるのが良いと思います！
（Q）良いツールだと作りやすいからどんどん作っちゃう（わかる）、これバランスどう取っていくか。アドバイスを聞きたいです。
Daishu：本当に確認必須なものだけAssertionを呼び出して、それ以外は手順が通ることで担保するという考えがE2Eにおいては大事だと思っています。
（Q）患者さん情報、特殊かなと思うのですが、ならではのテストの工夫とか意識ってありますか？
Daishu：弊社はドメイン知識が豊富なメンバーがCSに多いという特徴があります。患者情報は多様なパターンがあるので、実際にCSメンバーとコミュニケーションを取りながら、具体的なテストケースを作成する時間を確保しています。
（Q）機能一覧のマッピングシート素敵ですね。こういう試行錯誤とか工夫は現場からのアイデアですか？テストの体制とかも気になります。
Daishu：現場からのアイデアです。体制としては、プロダクト単位でQAチームから1〜2名アサインする形ですが、QAチーム全体で話し合う時間があり、こういったアイデアについても話し合っています。
（Q）当方は組み込み製品のため、製品ごとにWebUIの構成が変わってしまいます。結果として自動テストが一品モノになってしまい、毎回作り直すために膨大な工数がかかってしまっています。このようなケースに対応するアイディアはありますか？
Daishu：最低限、共通化できるブラウザ操作 (タブを開く、閉じる、URL遷移) などを流用するなどでしょうか・・。
いかがでしたでしょうか、レポートの内容は以上です。
次回のイベントレポートもお楽しみに♪
