こんにちは。MagicPod カスタマーサクセスのIshiiです。テストケースレビュー観点ワークショップで紹介している観点をもとに、実践的なレビューアイデアを10個まとめました。本記事の内容はMagicPodに限らず、自動テストツールを使う場合は参考になるかと思います。なお、本記事ではテストケース実装前のテスト設計書のレビューについては触れておりません。整理されたテスト手順や期待結果が存在することを前提として読んでください。目次 -->目次自動テストケースレビューの4つの軸テストケースのレビューには、以下の4つの軸があると考えています。目的を達成しているか安定性メンテナンス性可読性この記事では各軸に沿ってレビュー観点を整理しています。紹介する観点はあくまでアイデアなので、チームの規模や状況に合わせて取捨選択してください。レビュー観点アイデア10選本記事で紹介する10個のレビュー観点を表にまとめました。1つ1つの観点に関して、なぜこの観点が大事なのか、そして具体的にどのようなことを確認すべきかを説明していきます。目的を達成しているか観点1: 目的を達成するテストになっているか確かめたかったことを確認できるステップが実装されているかを確認しましょう。観点2: 不具合が発生したときに検知できるアサーションになっているか確認コマンド（アサーション）の選び方によって、不具合の検知力は変わります。MagicPodには確認コマンドが36種類（2026年3月時点）あります。（参考ヘルプページ：コマンド一覧）URLが一致するか確認画像差分がないか確認UI要素の値が一致するか確認UI要素が表示されているか確認ページのタイトルが一致するか確認どのコマンドをどの場面で使うか、チーム内で大まかに認識を合わせておくと、レビュー指摘が減り品質が安定します。「正常に画面が遷移したことは、このコマンドで確認する」といった共通理解が品質の底上げにつながります。安定性が高いか観点3: 不安定になりやすい箇所に待機コマンドが入っているか「ここ、待機ないと失敗しがち」という共通認識がある箇所には、必ず待機コマンドを入れるようにしましょう。画面の読み込みが遅い箇所や、外部API呼び出し後の表示更新など、タイミングに依存しやすい処理が主な対象です。テストの安定性を向上させるには観点4: 固定時間待機するコマンド

こんにちは、MagicPodメンバーのIkariです。目次 -->目次パネルディスカッションパネリストshutty（首藤 義景）さん｜テックタッチ株式会社 QA ManagerMAX（北村 駿）さん｜エン株式会社 QA Lead / Staff QA Engineerモデレーター伊藤 由貴 ｜ 株式会社MagicPod エバンジェリスト 1. 現在のポジションに至るまでの経緯まずは、お二人がどのようにして現在のポジションに至ったのか。「最初からQAマネージャーを目指していたわけではなくて、気づいたら“やるべきこと”が増えていった、という感覚に近いですね」（shuttyさん）「品質の課題に対して“誰かがやらないといけない”という場面で、自分がやるようになっていったのがきっかけでした」（MAXさん）役職としてのリーダーではなく、課題に向き合う中で自然にリーダーシップが形成されていくプロセスが印象的でした。2. 現在の業務内容QA Manager / QA Leadの業務は、単なるテスト管理にとどまりません。「テストだけを見ているというよりは、“プロダクト全体の品質をどう担保するか”を常に考えています」（MAXさん）「QAの仕事って、気づいたら開発やビジネスの話にも踏み込んでいることが多いんですよね」（shuttyさん）主な役割として挙げられたのは：テスト戦略・品質方針の策定品質リスクの可視化開発チームとの連携メンバー育成組織としての品質文化づくりQAは単なる実務ではなく、プロダクトと組織を横断する存在であることが強調されました。3. QA Manager / QA Leadの心掛けディスカッションの中で繰り返し語られたのが、「言語化」の重要性です。「『なんとなく不安』ではなくて、何がリスクなのかをちゃんと説明できることが大事だと思っています」（MAXさん）また、ステークホルダーとの関係性も重要なテーマでした。「品質を守るだけだと、どうしても開発のスピードと衝突するので、どこで折り合いをつけるかは常に考えています」（shuttyさん）さらに、リーダーとしての視点についても：「自分が全部やるのではなくて、チームとしてどう成果を出すかを考えるようになりました」（MAXさん）QAリーダーには、技術だけでなく“調整力”や“伝える力”が求められることが浮き彫りになりました。4. 大

こんにちは、MagicPod広報・コミュニティマネージャーの田上です！2025年度 ノミネート作品のご紹介結果発表の前に、今回ノミネートされた6つの素晴らしい記事を改めてご紹介します。MagicPodを活用したテスト自動化とQAフロー改善の道のり 手動テストを中心とした運用から、MagicPodを導入してQAフロー全体をどう再構築したかを解説。単なるツールの導入に留まらず、組織として「品質」に向き合うプロセスが丁寧に描かれています。QAエンジニア不在の状況下で自動E2Eテストツールの運用改善のために個人・チームで行ったこと QA専任者がいない環境において、開発チーム全体でMagicPodを運用していくために積み重ねた創意工夫の記録。現場ならではのリアルな試行錯誤と、一つひとつ着実に改善を進めていくプロセスに、多くの読者が勇気づけられました。MagicPod × FlutterでAndroid/iOS自動テストを一本化して自動化コストを約50％削減した話Flutterによるマルチプラットフォーム開発において、MagicPodを活用して両OSのテストコードを一本化した事例。メンテナンス工数を劇的に削減した具体的な手法は、全アプリ開発者必見です。E2Eテストの失敗要因をAIで特定するSlack botを作った話 「テストが失敗した原因はバグか、それとも環境か？」という判断をAIに一次解析させる仕組みを構築。MagicPodの情報とAIの知能を連携させ、人間がつきっきりで見守らなくてもスムーズに仕事が進む「未来のテスト運用」を体現した非常に高度な実践記録です。MagicPod導入で実現！enechainにおけるE2Eリグレッションテスト自動化の全貌 複数のツールを比較検討した末にMagicPodを選定し、手動テストを劇的に効率化した事例。テストケースの選定基準からCI/CDでの自動実行まで、「スピード」と「安心」を両立させるための濃密なノウハウが凝縮されています。 自動化の「理想の形」をどう具現化していくか、その全貌を網羅した圧倒的な情報量に多くの注目が集まりました。TIS AIChatLab：MagicPodをつかった自動テスト導入戦略 手動での確認作業をMagicPodによる自動テストに置き換えることで、1週間かかっていたテスト負荷を大幅に削減した事例。 社内の実績を活

こんにちは！MagicPod広報の田上です。 2026年2月27日に開催した「MagicPodミートアップ」の様子をレポートします！1. 初の試み！参加型アイスブレイクセッションに先立ち、今回は初の企画としてメンチメーター（Mentimeter）を使用した参加型のアイスブレイクを実施しました。 スマートフォンを使って、リアルタイムに回答が画面に反映される仕組みに、会場（オンライン）は大いに盛り上がりました。職種：QAエンジニアが最も多かったものの、開発者やカスタマーサクセス、さらにはCEOまで、幅広い層の方々にご参加いただきました。自動化歴：3年〜5年未満の方が中心でしたが、中には10年〜15年以上のベテランもいらっしゃいました。MagicPod利用状況：ほとんどが既に利用中のユーザーさんでしたが、「使ったことはあるが未契約」という検討中の方も3名ほどいらっしゃいました。期待すること：「Autopilotの活用法」「他社の導入事例」、さらには「MagicPodのゆるキャラ」にまで興味が寄せられました。このアイスブレイクを通じて、登壇者の皆さんも「どんな層が聞いているか」を把握でき、リラックスした雰囲気でセッションをスタートさせることができました。2. 「2025年の開発サマリー＆今年の展望」 MagicPod エバンジェリスト 伊藤 由貴伊藤からは、2025年の振り返りと、2026年に向けた「ワクワクする」開発ロードマップが発表されました。「MagicPod Autopilot」のリリースです。 チャット形式でテスト作成や編集が可能になり、自動化のハードルが大きく下がりました。 2026年の展望としては、以下の強力な機能が開発予定であることが明かされました。TypeScript/JavaScript実行ステップ：より複雑なテストロジックが実装可能に（開発はほぼ完了！）。モバイルとブラウザテストの相互連携：1つのプロジェクトで両プラットフォームを横断したテストが可能に。Playwrightへの実行エンジン移行：パフォーマンス向上と全画面スクリーンショットへの対応。失敗原因分析エージェント：テスト失敗の原因をAIが分析し、具体的な修正案を提示。3. 「AutopilotによるMagicPodの導入範囲拡大と運用中の失敗事例」 株式会社くふうカンパニー 岡 浩司さん岡さん

こんにちは。MagicPod カスタマーサクセスのIshiiです。React Tokyoフェス2026にスタンダードスポンサーとして参加しました。目次 -->目次React Tokyoフェス 2026とはReact Tokyoは東京を中心に、オンラインとオフラインの両方で活動するReactコミュニティです。React Tokyoフェス 2026は初の大規模オフラインイベントとなり、浜松町の会場に約500名が集まりました。会場のいたる場所にのぼり旗があり、お祭りムードを演出していました🏮スポンサーセッションスポンサーセッションで技術トークをする機会をいただき、MagicPodエンジニアのTakahashiが登壇しました。MagicPodは5年以上続いている大規模サービスであるゆえ、いわゆるレガシーコードが存在していました。jQueryの話題については業界に長く携わっている方々の琴線に触れたようで、反響を多くいただき嬉しく思います！セッションにご参加くださった皆様、ありがとうございました！スポンサーブース出展MagicPodのスポンサーブースでは、MagicPodでバグハント！を開催しました。具体的には、Reactチュートリアルでお馴染みの三目並べアプリに仕込まれた、MagicPodでバグハント！は本フェスが初開催となり、楽しんでいただけるだろうか、、とドキドキしながら準備をしてきました。MagicPod Autopilotを用いて、自然言語でサクッとテストケースを作成する体験をしてくださった皆様から「Autopilot便利！」「MagicPodのUIはわかりやすい」といったフィードバックをいただけて嬉しかったです。また、一部時間帯にはイベント出展時にお馴染みのまちがい探し！を開催しました。ブースにお立ち寄りくださった皆様、ありがとうございました！その他イベントポスター発表会場を取り囲むように多彩なテーマについて40件のポスターが展示されていました。多数のサブイベント激突！AIライブコーディングやUI コンポーネント分解ゲームなどの様々なサブイベントが多数開催されていました。AIコーディング横丁というイベントに参加し、AI開発の知見が得られて嬉しそうでした。React Hooks魚釣り🐟🎣に挑戦しました。かなり苦戦しましたが、無事釣ることができました。私が釣ったの...

こんにちは。MagicPodでエバンジェリストをしているYoshiki Itoです。先日、株式会社ベリサーブ・株式会社MagicPod共催のオンラインセミナー「テスト自動化とQAの事業貢献～3社で語る攻めの品質創造とは～」にて、LINEヤフーコミュニケーションズ野原さん・広瀬さん、ベリサーブ髙田さん・長橋さんと一緒に「QAの事業貢献」についてパネルディスカッションをしてきました。【オンラインセミナー】テスト自動化とQAの事業貢献～3社で語る攻めの品質創造とは～当日は時間の制約もあって話しきれなかった内容がいくつかありました。本記事では当日話しきれなかった部分——「QAの事業貢献を、開発生産性という軸でどう整理するか」——について、私なりの考えをまとめてみたいと思います。そもそも「事業貢献」とはどういうことか「QAの事業貢献」やこれに類するトピックについて、最近よく聞くようになったと感じています。とくに「QAエンジニアとしてこの先どう生き残るか」といった文脈において、単純に日々目の前のテストやQA活動を行うだけではなく、それがどう事業にとってメリットをもたらしているのか説明できるようにならねば、というQA側の内発的なモチベーションから来ていることが多そうです。私自身も経験がありますが、例えば一人目のQAエンジニアやQA組織のリーダー・マネージャーとして体制強化や組織を拡大していこうと考えたときなどは、QAによる事業貢献の説明が求められることが多いでしょう。「事業貢献」をごく単純に捉えると、「売上や利益の向上に寄与すること」と言えます。ただ、QAの業務が直接的に売上や利益の向上につながる、という説明はしづらい部分が多いです。バグを減らすことで機会損失を防ぐ、リリーススピードを上げることで競争優位に寄与する——こうしたロジックは成り立ちますが、「QAがこれをやったから売上がこれだけ上がった」と言い切れる場面というのは、多くはないでしょう。今回のイベントで「QAの事業貢献とは何か」というテーマのディスカッションが成り立つのも、ある意味ではその説明しづらさゆえ、という面もあると思います。そこで、QAによる事業貢献を考えるうえでのヒントとして「開発生産性」という切り口を用いて、「直接的な売上・利益への貢献よりも、開発組織における開発生産性の向上を通じて、結果として事業に貢献する

こんにちは、MagicPodメンバーのIkariです。「QA Real Talks 〜QAの未来予想図〜」 のレポートをお届けします。テスト実行自動化にAIをどう活用するのかテスト設計・計画にAIはどこまで入り込むのかQAエンジニアのスキルはどう変わるのかQA組織はどこへ向かうのかというテーマのもと、リアルな議論が交わされました。目次 -->目次パネルディスカッションテーマ：QAの未来予想図登壇者Medley 米山 允章さんナレッジワーク かとあずさんMagicPod 伊藤 由貴モデレーター：ナレッジワーク 河野 哲也さん1. テスト実行自動化にAIをどう使うか？議論の出発点は「実行自動化」。 「実行自動化やその前後は、AI導入の“入口”になりやすい」「AIが出したものをそのまま信じるのはちょっと怖い」「自動化がうまく回っている組織ほど、実行よりも“設計”にAIをどう使うかを考え始めている」一番左：MagicPod プロダクト初期の頃からお世話になっている米山さん2. 手動も含めたテストプロセス設計にAIをどう使うか？実行の先にあるのが「設計」。「一人で考えてると詰まるけど、AIに聞くと視点が増える」「AIが答えを出すんじゃなくて、判断材料を増やしてくれる存在」AIの活用についてを語るかとあずさん3. QAエンジニアはこれからどのようなスキルを身につけるべきか？AI時代において、QAは何を磨くべきなのか。「これからは“どうテストするか”を考えられる人が強い」「QAは“テストする人”ではなく、“品質を定義する人”になっていく」「AIを使える人と使えない人で、作業スピードはかなり差が出る」今後のQAはどうなるかを語る伊藤由貴4. QAを取り巻く業務はどう変わるのか？実行工数は減る。「楽になるというより、考える時間が増える感じ」5. QA組織の未来予想図最後のテーマは組織。「QA組織がなくなる、ではなく、QAの思想が組織全体に広がる。」ネットワーキングタイム全セッション終了後は、ビールを片手に交流タイム。アツい議論があちこちで！軽食やドリンクを片手に、登壇者・参加者の垣根を越えたディスカッションが各所で自然に始まり、テスト自動化の具体的な運用方法や、組織への展開のリアルな悩み、AIの活用事例など、実践的で踏み込んだ話題が飛び交いました。今回スポンサーとしてご協力いただいた

こんにちは。MagicPod カスタマーサクセスのIshiiです。目次 -->目次クラウド実機デバイスとはクラウドなのに、実機…？どういうことだろう…？と思われた方もいるかもしれません。エミュレーターやシミュレーターではなく、本物のデバイスを使ってテストできるため、実際のユーザー環境により近い状態で動作確認ができます。Remote TestKitという日本のサービスとなります。クラウド実機デバイスの活用シーンMagicPodでクラウド実機デバイスを使った自動テストを行うユーザーの方にモバイル実機を使ってテストしたいが、実機端末の管理は大変なので避けたいMagicPodのクラウド環境でサポートされていない機種でテストを実行したい特定の機種でのテストがリリースの必須要件となっているMagicPodでRemote TestKitのクラウド実機を使ってテストする方法ここからはMagicPodでRemote TestKitのクラウド実機を使ってテストするための設定方法を紹介します。Remote TestKitのクラウド環境での一括テスト実行事前準備まずはRemote TestKitのアカウントを用意しましょう。料金プラン）こちらからお申し込みください。次にMagicPodのテストケースを作成しましょう。外部クラウドサービスは一括実行でのみ利用可能ですテスト実行方法それではクラウド実機デバイスを使ってMagicPodで自動テストを実行しましょう。Remote TestKitにログインし、アカウント名横の▼をクリックします。そしてコピーしたトークンをMagicPodの一括実行設定ダイアログのアクセストークン欄に入力します。次にRemote TestKitにログインし、レンタルする端末を確認します。レンタルする端末の機種名、OS(MagicPod上ではバージョン)をMagicPodの実行設定で指定します。実行に必要な情報を全て入力すると、上記のような設定となります。一括実行の一覧画面を確認すると、機種名、OSバージョン、Remote TestKitでの実行であることが確認できます。無事実行が成功しました🎉多端末テストを並列実行する色々な端末でテストしたい場合は、一括実行のパターンを使いましょう。注意点として、すでに端末が他のユーザーによってレンタルされている場合はRemote T...

こんにちは、MagicPodでエバンジェリストをしているYoshiki Itoです。テスト自動化ツールを導入したら、次は組織全体で活用できる状態にしていく必要があります。ただ、推進担当として旗振りをしていても、思うように利用が広がらなかったり、使う人が増えてきたら増えてきたで運用面の課題が出てきたり。そんな悩みを抱えている方もいらっしゃるのではないでしょうか。ツールを導入することと、それを組織全体で活用できる状態にすることは、実は別の話です。特に複数のチームでツールを共有する場合、運用のためのルール整備が重要になります。本記事では、テスト自動化ツールを社内で普及・展開する際に整備すべきルールについて、MagicPodを例に解説します。なお、整備すべきルールには大きく2種類あると考えています。1つはツールの中の話、つまりテストケースや共有ステップの命名規則、フォルダ構成といった、ツール内での整理整頓に関するルールです。もう1つはツールの外の話、つまり利用開始の手続き、担当者の明確化、テストデータの管理といった、組織としての運用に関するルールです。ツールの中の話については、MagicPodヘルプセンターの「複数人で使用する際の運用ルールについて」などで詳しく紹介していますので、ぜひ参考にしてみてください。本記事では、ツールの外の話にフォーカスしてお伝えします。目次 -->目次なぜルール整備が必要なのかテスト自動化ツールを導入して、最初のうちは順調に使えていたのに、気づいたらカオスな状態になっていた——そんな経験はないでしょうか。ルールが曖昧なまま運用を続けると、いくつかの問題が起こります。たとえば、誰かが作ったテストを別の人が知らずに編集してしまったり、退職したメンバーが作ったテストの中身を誰も把握していなかったり。費用や契約の管理がはっきりしないまま、気づいたら想定外の出費になっていた、ということもあります。（金額面もそうですが、社内の申請や手続きなどの手間が発生するのは避けたいですよね。）特にこうした問題は、複数のチームでツールを共有するようになると起こりやすいです。ルールというと堅苦しく感じるかもしれませんが、ここでいうルールは「縛り」ではなく「共通認識」です。社内のユーザーが同じ認識を持つことで、無用なトラブルを防ぎ、スムーズに運用できるようになります。ここから

テスト自動化ツールの導入ハードルは、ここ数年で大きく下がった。ツールの進化や、QA・テストエンジニア間でのナレッジ共有が進んだことで、「とりあえず始めてみる」ことは以前よりも容易になっている。しかしその一方で、「導入したものの、うまく活用できていない」「気づいたら誰も使っていなかった」という声は後を絶たない。本記事では、MagicPodでエバンジェリストを務める伊藤由貴に、テスト自動化が続かなくなる原因と、継続するためのポイント、そして生成AI時代のツール選定について聞いた。目次 -->目次テスト自動化ツールを取り巻く現状と、現場で起きている課題「以前はある種気合いを入れて導入するものだったテスト自動化が、かなり身近な、ある程度あって当たり前の世界になってきました」こう語るのはMagicPodの伊藤由貴だ。ブログ記事の執筆やウェビナーでの登壇を通じてテスト自動化の普及活動を行う傍ら、既存ユーザーからのテスト自動化やQA体制構築の相談も受けている。伊藤によれば、一昔前のテスト自動化は、費用や契約形態の都合でハードルが高く、大きな予算を組んで「導入プロジェクト」として進められることが多かった。OSSを用いる場合でも、すべて自分たちで仕組み化する必要があり、相応のパワーが求められた。しかし現在は、ツール自体の進化とナレッジの蓄積により、状況は大きく変わっている。テスト自動化を始めること自体のハードルは確実に下がった。ところが、導入のハードルが下がったことで、新たな課題も浮き彫りになっている。「導入はしたものの、うまく活用できていない」という現場が増えているのだ。テスト自動化ツールが現場で続かなくなる理由導入のハードルが下がり、テスト自動化を始めやすくなった一方で、「うまく活用できていない」現場が増えている。その背景には、推進役の不在、メンテナンス負荷の増大、周囲の巻き込み不足といった課題がある。しかし、最も見過ごされがちなのは「ツール選定の問題」ではなく「運用・体制の問題」だ。さらに最近は、一見継続できているように見えて実は成果につながっていない「静かな失敗」も増えているという。推進役の不在が招く形骸化テスト自動化がうまく活用できていない現場の共通点として、「大きな要素の一つに、主担当・推進役の不在があります」と伊藤は指摘する。「テスト自動化に限らず、なんらかのツールや方