MagicPod Blog

http://magicpod.com/blog/

MagicPod Blogでは、ソフトウェアテストや品質保証、開発効率化に携わる方向けに、日々の業務に役立つ情報やテスト自動化の最新知見を発信しています。

フィード

記事のアイキャッチ画像
E2Eテストはどこまでやるべき? 「テスト全体像」から範囲を決定する2つのヒント
MagicPod Blog
こんにちは。MagicPodでエバンジェリストをしているYoshiki Itoです。MagicPodに限らず、E2Eテストの自動化に取り組み始めた方が疑問に思うのが「E2Eテストってどのくらい/どこまでやればいいの?」という点です。かつてシステムテストやE2Eテストの自動化がいまほど普及していなかった頃には、なんでもかんでも自動化!100%の自動化率!といった、それまで行っていたたくさんの手動テストケースを片っ端から自動化するようなチームもあったようです。しかし、テストピラミッドの考え方をはじめ、テスト自動化に関するさまざまな情報・ナレッジが普及するとともに、上記のような「E2Eテストをたくさん自動化しよう」というやり方はアンチパターンだと認識されるようになりました。
5日前
記事のアイキャッチ画像
「AI Agentで変わるモバイルアプリ開発におけるテスト 実践事例4選」ウェビナーレポート
MagicPod Blog
こんにちは、MagicPodメンバーのIkariです。目次 -->目次イベントについてこのイベントは、AIエージェントを活用してモバイルアプリ開発のテストをどう効率化できるのか、5名の登壇者に最新の事例を集めて共有していただく場として開催しました。AIがどのような可能性を開いてくれるのかがテーマでした。セッション内容ダイジェスト1. AIが書いたコードをAIが検証する!自律的なモバイルアプリ開発の実現登壇者:今井 健太さん (株式会社デプロイゲート)2. AI AgentとMCP Serverで実現するiOSアプリの自動テスト作成の効率化登壇者:ピヨコさん (スパイダープラス株式会社)3. Firebase App Testing Agentで始めるAIベースの柔軟なE2Eテスト登壇者:Akira Shimizuさん (株式会社フライヤー)4. Claude CodeでサクサクTestコードを移行しよう登壇者:千北 一期さん (株式会社MIXI)5. ノーコード x 生成AIのMagicPod Autopilotを使ったE2Eテスト生成登壇者:伊藤 望 (株式会社MagicPod CEO)まとめ今回のイベントを通じて見えてきたのは、AIエージェントがすでにテスト領域で実用フェーズに入っているということ。AIとMCP Serverでテスト作成が大幅効率化AIの弱点(ハルシネーション)を克服する工夫不確定UIにも柔軟に対応できるE2Eテストの可能性現場の課題を解決するヒントが、各セッションにたくさん詰まっていました。今すぐ無料でご覧いただけますので、ぜひご活用ください! MagicPod Autopilotについては、ぜひ以下の資料もご確認いただければと思います。MagicPod Autopilot (ベータ版) についてAI自動テストのMagicPod、生成AIがテスト作成と実行を行う「MagicPod Autopilot」を提供開始「MagicPod Autopilotを実際に試してみたい!」というご相談も大歓迎です。https://magicpod.com/consulting/
9日前
記事のアイキャッチ画像
AI時代に輝くQAエンジニアになるために
MagicPod Blog
AIは、単純で繰り返しの多い業務を急速に代替しつつあります。もしあなたの仕事がテストの実行やバグの記録といった定型的な作業に偏っているなら、今こそキャリアのあり方を見直し、スキルを磨く時です。目次 -->目次予想を超えるAIの急成長AIはもはや実験段階を過ぎ、企業が実際に価値を生み出す手段となっています。回答者の65%が生成AIを日常的に活用しているとの結果が出ています。これは2023年の数字からほぼ倍増しており、AIがすでにビジネスの現場で当たり前に使われ始めていることを示しています。最初に置き換えられるのは繰り返し作業私自身、QAエンジニアとして働く中で、AIにより一部の作業はすでに代替されました。その結果、私はより高度な思考を必要とするタスクに集中できるようになりました。テスト設計・実行の自動化です。MagicPodのようなAIテスト自動化プラットフォームを使えば、ノーコードでテストケースを自動生成し、リグレッションテストやE2Eテストを効率的に実行できます。不具合の記録テストデータ管理AIはパターン認識に優れているため、こうした繰り返し型・定型型のタスクに強みを発揮します。日々の業務の大半は、リグレッションテストの実行やバグ報告といった定型作業に費やされていないか?それとも、テストの目的やシステムの背景を理解した上で、優先度を判断しながら取り組んでいるか?AIでは代替できない力 ―クリティカルシンキングとリスク感覚AIと人間を分ける最大の要素は「クリティカルシンキング」と「リスクを状況に応じて判断する力」です。その問題がどの程度ビジネスに影響するのか、どのリリースで優先的に修正すべきかといった判断は苦手です。ここは、製品やユーザーの利用シーンを理解している人間が介在する必要があります。システムの仕様、製品の特性、利用する顧客の背景を踏まえて、どの機能を重点的にテストすべきかを見極めることです。AIはマニュアル通りのチェックは得意でも、こうした「何をどの深さで検証すべきか」という判断までは苦手です。AI時代に生き残るためのQA戦略QAエンジニアが今すぐ取り組むべきことは以下の3つです。製品の専門家になるリスク感覚を磨く優れたコミュニケーション能力を持つもし現在の役割が単純作業に偏っているなら、上司に相談し、より高度な責任を担えるように動いてみましょう。もしそれ
15日前
記事のアイキャッチ画像
MagicPodを本番環境のシステム監視にも使ってみよう
MagicPod Blog
こんにちは。MagicPod カスタマーサクセスのIshiiです。脆弱性診断のシナリオ作成をMagicPodで自動化した話を紹介しました。目次 -->目次MagicPodで監視を自動化しているお客様事例早速ですが、実際のお客様の事例をまずご紹介いたします。また、MagicPodによる定期的な死活監視によって本番環境での不具合を早期に検知できるようになったことも大きな成果です。以前、外部サービス側の設定ミスでCoincheckの一部ページが非公開になってしまったことがあったのですが、MagicPodが定期チェックですぐに検知してくれたため迅速に対処することができました。▼お客様事例リグレッションテストの自動化で実行工数を50%削減!暗号資産取引サービスの品質と安全性を支えるQA改革とは他のユーザー様からも、リグレッションテストだけでなく、本番サービスの外形監視に活用しているというご報告を複数いただいております。システム監視とはシステム監視とは、ITシステムが正常に稼働しているかを継続的にチェックし、問題が発生した際に迅速に検知・対応するための仕組みです。システム監視には様々な種類がありますが、MagicPodでも同等の監視が可能なのは以下二つです。死活監視サーバーやサービスが稼働しているかを確認する最も基本的な監視です。一般的な方法としてはpingやHTTPレスポンスチェックで監視します。Ping監視HTTPレスポンスチェック外形監視ユーザーの視点からシステムが正常に動作しているかを確認する監視手法です。WebサイトやWebアプリケーションが外部ネットワークからユーザーと同じようにアクセスできるかどうかを監視します。ユーザーにとっての使用可能性を確認します。サーバーが稼働していても、アプリケーションエラーやデータベース接続問題でユーザーがサービスを利用できない状況を検知できるのが外形監視の強みです。監視にMagicPodを使うメリットMagicPodではいわゆる外形監視に近いことができます。​単純な稼働確認を超えて、実際の各機能が正常に動作しているかを包括的に監視できる点が大きなメリットです。監視用のテストケースを作るそれではMagicPodのこちらのページを監視するテストケース作成を例に説明します。確認コマンドを使う方法XXが表示されているのであれば、この画面は表示
15日前
記事のアイキャッチ画像
WebViewとは?WebViewの仕組みからテスト方法まで徹底解説
MagicPod Blog
こんにちは。MagicPod カスタマーサクセスのIshiiです。目次 -->目次今すぐ無料でご覧いただけますので、ぜひご活用ください! WebView(ウェブビュー)とはWebView(ウェブビュー)とは、モバイルアプリ内でWebコンテンツを表示するための仕組みです。簡単に言えば、アプリの中に埋め込まれた小さなブラウザのような存在です。WebViewの使い所WebViewは「頻繁に更新が必要」「外部サービスを統合したい」といったシーンで特に力を発揮します。 利用規約・プライバシーポリシーの表示 法的文書は頻繁に更新される可能性があるため、WebViewを使用することでアプリを更新せずにコンテンツを変更できます。 ヘルプ・FAQ画面 検索機能や階層的なナビゲーションが必要なヘルプコンテンツに最適です。 ニュース記事・ブログコンテンツ テキスト中心のコンテンツで、豊富な装飾やレイアウトが必要な場合に適しています。 決済画面の統合 PayPalやStripeなど、外部決済サービスの画面をアプリ内で完結させたい場合に使用されます。 ソーシャルログイン Google、Facebook、Twitterなどの認証フローをアプリ内で実現するために活用されます。 サードパーティサービスの組み込み チャットボット、地図サービス、動画プレイヤーなど、外部サービスのUIをアプリに統合する際に使用されます。 この記事の執筆にあたり、WebViewが使われているかという観点で普段使っている様々なアプリを触ってみたのですが、私が使っているアプリの8割以上ではWebViewで構築された画面が組み込まれていました。特に利用規約などのポリシー系やヘルプコンテンツは特にWebView率が高いです。最近増えている「ガワアプリ」とは最近は、いわゆる「ガワアプリ」と呼ばれるアプリも増えています。ガワアプリとは、アプリの外枠(ガワ)だけをネイティブで作り、中身はほぼWebViewで構築されたアプリのことです。短期間でリリースできる開発コストを抑えられるアップデートが容易WebViewの仕組みWebViewはiOS、Androidともに公式でサポートされています。WebView画面の見分け方モバイルアプリのコーディングをしないQAエンジニアなどにとって、「この画面がWebViewで構築されているか」の判断は難し
15日前
記事のアイキャッチ画像
「ブランチ機能でQAチームのコラボレーションを加速しよう」ウェビナーレポート
MagicPod Blog
こんにちは。MagicPod カスタマーサクセスのIshiiです。目次 -->目次MagicPod CSウェビナーについてMagicPod CSウェビナーとは当社のCS(カスタマーサクセス)メンバーがMagicPodの機能について解説する、誰でも参加可能なウェビナーです。初回は2025年9月に開催しました。ブランチ機能でQAチームのコラボレーションを加速しよう&MagicPod最新アップデート紹介つきということで、メインとしてはブランチ機能に焦点を当ててご紹介しました。 今すぐ無料でご覧いただけますので、ぜひご活用ください! ブランチ機能とはブランチ機能とは、同じプロジェクトの中にいくつかの並行した作業スペースを作る機能です。この図の緑色の矢印線が、いつも使っているあのプロジェクトとテストケースたちです。それをデフォルトブランチと呼び、そのデフォルトブランチから複数のブランチ(作業スペース)を作成できます。ブランチ機能がない世界・ある世界ブランチがないと、この図のような困ったことが発生します。ブランチがある世界では、これらのお困り事をブランチにより解決することができます。ではどのようにブランチを使うのかここから学んでいきましょう。ブランチ機能の使い方「こう使ってもらえると一番有効活用できるだろう」という私たちが推奨する構成があります。「テスト環境ブランチ」「本番環境ブランチ」「作業用ブランチ」の3つのブランチを用いる構成です。テスト環境ブランチ(緑色の矢印)「いつも使っているあのプロジェクトとテストケースたち」です。このブランチはテスト環境(開発環境)でのテストに使用してください。作業用ブランチ(青色、黄色の矢印)作業用ブランチとは、修正や検証など作業したいときに作成するブランチです。作業後にデフォルトブランチにマージ(変更を反映)します。作業用ブランチはこのようなシーンで活躍します。今のテストケースの内容をみたいけど、意図せず編集してしまいそうで心配クリックがたまに失敗するので、ロケータを安定するものに変えたい。でも既存のテストが壊れると困るなぁ...例えば不安定なロケーターを変更したい時には、この流れで行いましょう。作業用ブランチを作成する(ブランチ名の例:ishii作業用)作業用ブランチにて、対象テストケースを編集、実行して動作確認テスト環境ブランチにマージす
15日前
記事のアイキャッチ画像
テスト自動化の成功・失敗を分けるのは「継続性」
MagicPod Blog
こんにちは。MagicPodでエバンジェリストをしているYoshiki Itoです。システムテスト自動化は、関連書籍が複数出版されるなど、以前と比べて普及が進んでいるように思います。毎年年末ごろに行われているテスト自動化カンファレンスのアンケート結果でも、システムテスト自動化の経験がない方は2024年末で29%と、41%で最多となった2017年から減少傾向にあります。
15日前
記事のアイキャッチ画像
Playwrightで書いたソースコードをMagicPod Autopilotに読み込ませてみた
MagicPod Blog
こんにちは。MagicPodカスタマーサクセスの滝口です。「Playwrightで書いたソースコードをMagicPodで使うことはできますか?」といったお問い合わせをいただくことが増えております。PlaywrightのソースコードをMagicPod Autopilotに投げたらテストケースが作れた!・・・・なんだって👀Playwrightを導入しているけどMagicPodが気になっているすでにどちらも導入しているが、MagicPodへの移行方法に悩んでいるそんな方に読んでいただけると嬉しいです!いざ検証!今回は、簡単なテストが移行できるのかを検証します。Hotel Planisphereを使っていきます。Playwrightで書いたテスト内容予約画面に遷移おすすめプランの「Reserve room」をクリック必要項目を入力「Confirm Reservation」をクリック予約確認画面の日付がSeptemberになっていること予約確認画面に日付が表示されていること実際のPlaywrightのソースコード(汚いですごめんなさい)import { test, expect } from '@playwright/test';test('test', async ({ page }) => { await page.goto('https://hotel-example-site.takeyaqa.dev/en-US/'); await page.getByRole('link', { name: 'Reserve' }).click(); const page1Promise = page.waitForEvent('popup'); await page.locator('.btn.btn-primary').first().click(); const page1 = await page1Promise; await page1.getByRole('textbox', { name: 'Check-in required' }).click(); await page1.getByRole('link', { name: '22' }).click(); await page1.getByRole('checkbox', { name: 'Breakfast'...
22日前
記事のアイキャッチ画像
プロジェクトごとのCICDパイプライン設計でリリースを加速する方法
MagicPod Blog
ソフトウェアをリリースするたびに「なぜこんなに時間がかかるのか」と感じたことはありませんか?今すぐ無料でご覧いただけますので、ぜひご活用ください! 目次 -->目次カスタマイズされたCI/CDのメリットとは?CI/CDを導入した当初は「ひとつのパイプラインで十分だ」と考える方も少なくありません。時間の短縮問題の早期発見こうした工夫によって、効率と品質を両立しながら、リリースをより速く、より安定させることができます。プロジェクト要件に合わせたパイプライン設計アプリケーションの特性を無視したままパイプラインを作ると、重要な検証を見落とすリスクがあります。モノリシックアプリケーションモノリシックアプリはコンポーネントが密に結合しているため、変更の影響範囲が広がりやすいのが特徴です。統合テストを重視する必要があります。また、データベーススキーマ変更に伴う本番環境での障害を防ぐために、移行テストも欠かせません。カナリアリリースを導入して段階的にリリースするのも有効です。まず一部のユーザーに変更を適用し、問題があれば即座にロールバックできる仕組みを用意しておけば、大規模な影響を避けられます。マイクロサービスアーキテクチャマイクロサービスでは、各サービスごとに専用のパイプラインを設計することがカギです。これによりフィードバックが早まり、変更の影響範囲も最小限に抑えられます。サービススタブを使ってシミュレーションし、さらにE2Eテストで複数のサービスが連携し、ユーザーフロー全体が期待通りに動作するかを検証します。これにより、各マイクロサービスごとの品質とシステム全体としての整合性を両立できます。テンプレートの活用も効果的です。チーム全体で一貫してベストプラクティスを適用できます。パイプラインを高速・安定化させるプロジェクトに合わせたパイプラインが整ったら、次は処理速度と信頼性をさらに高める工夫を加えましょう。ボトルネックの特定と解消GitHub ActionsのメトリクスやCircleCI Insightsなどのツールを活用して、処理が遅いステージを特定します。そのうえで改善すべき箇所に集中しましょう。テスト結果やコードカバレッジを基準とした自動ゲートに置き換えると効果的です。さらに、ビルド成果物(例:コンパイル済みバイナリやパッケージ)や依存ライブラリをキャッシュしておくことで、
22日前
記事のアイキャッチ画像
タイムトラベルテスト ─ ユーザーより先に時間依存のバグを発見する
MagicPod Blog
日付や時刻に関するテストは、時間に依存する機能の正確性と信頼性を守るうえで欠かせません。例えば、予約システムや決済処理のような機能は、日付や時刻を正しく扱えて初めて期待通りに動作します。タイムトラベルテストです。テスト自動化において見過ごされがちですが、実は非常に重要なアプローチなのです。目次 -->目次タイムトラベルテストが必要な理由2012年、ナショナルオーストラリア銀行の医療支払いシステムで、うるう年の「2月29日」に対応できずシステムがダウンし、15万人の顧客が医療カードを使って支払いを行えなくなるという大規模な障害が発生しました。効率化:実際のイベントを待たずに、即座にシナリオを再現できる。コスト削減:うるう年対応漏れや期限切れキャンペーンなど、見落としやすいバグを事前に検出。ユーザー体験の向上:不具合を早期に修正し、安心して使えるサービスを提供。コンプライアンス対応:厳格な法規制や業界標準を確実に満たすサポート。タイムトラベルテストの仕組みタイムトラベルテストでは、システム内部の時計を変更することで、さまざまな時間をシミュレーションできます。これにより、実際に時間が経過するのを待たずに効率的にテストを進められます。サブスクリプション更新年末レポートサマータイム(DST)うるう年タイムトラベルテストに使えるツールシステムクロックを直接変更するのはリスクが高く、特にクラウド環境では推奨されません。代わりに、以下のような専用ツールが利用できます。TimeShiftX:システムクロックを変えずに過去・未来・タイムゾーンをシミュレーション可能。DB連携対応。Delorean:Python向けの日時操作ライブラリ。Timecop:Ruby製のテスト用時間制御ツール。MockTime:Node.js向けの時間モックモジュール。FakeTime:システム時間を低レベルでエミュレート。これらを使えば「半年後の更新処理」「過去の取引履歴検証」「うるう年の2月29日テスト」といったシナリオをすぐに再現でき、手作業での調整やリマインダーは不要になります。タイムトラベルテストのベストプラクティスタイムトラベルテストを効果的に活用するためには、いくつかのポイントを押さえておく必要があります。ここでは主なベストプラクティスをご紹介します。テストを自動化する境界ケースを重視するタイムゾ
1ヶ月前