Playwright を触って気づいた、MagicPod のありがたみ
こんにちは！メドレーで QA エンジニアをしている @Daishu です。所属チームのプロダクト (Web) の E2E テストで MagicPod を運用して 3 年になります。 最近よく「AI を活用して Playwright で自動化した」という話を聞く機会が増えました。先日の STAC2025 でも Playwright の話題はホットでしたね。AI × QA を推進している身としては Playwright が気になっていたので、MagicPod の一部シナリオを Playwright で実装してみました。 やってみて「確かに使える」という手応えは感じた一方で、MagicPod の良さにも改めて気づきました。この記事では、Playwright を触ったからこそ見えた MagicPod の良さを紹介します。 Playwright を触ってみて 基盤設計の 0→1 込みで AI がサポ
PlaywrightとMagicPodの二刀流でリグレッションテストの改善に挑戦 - UPSIDER Techblog
UPSIDERでテスト自動化を担当しているQAエンジニアのeriです。 この記事では、PlaywrightとMagicPodを併用しながら自動化を進めてきた1年間の試行錯誤を、包み隠さず紹介します。 冗長なテストと膨らむ実行時間 当初、MagicPodを中心に自動テストを構築していましたが、テストケースの増加とともに以下のような課題が出てきました。 テストシナリオが冗長化し、実行時間が長くなる傾向 30項目のテスト実行に約5時間かかっていた より細かい制御が必要になるケースが増加 MagicPodのGUIでは表現しづらい、条件分岐などの細かな処理 テスト対象の拡大 E2E対象の増加により、テストの拡張性が求められた そんな背景から、「そろそろ別のアプローチも必要では？」と話し合うようになりました。 理想とする状態を設定する 闇雲に自動化を進めても意味はないため、まずは理想像を明確にしました
MagicPodヘルススコアの全社統合分析用ダッシュボードを作成してみた
背景 株式会社MIXI（以下、MIXI）は2021年8月にMagicPodを導入し、2024年12月現在3年と4ヶ月が経過しました。 今までMagicPodの運用は各事業部に任せっきりで、全社横断的に運用状況を把握することができませんでした。 インプロセスQAとして実務を行なっていた私ですが、2024年10月より横断的にMagicPodに関する支援を行うことになったので、まずは全社把握を行うことにしました。 自動テスト評価に関して、MagicPodでできること・できないこと MagicPodの「プロジェクト」について 前提として、MagicPodには「プロジェクト」という単位があります。これは、1つのアプリ、Webサイトに対し1つのプロジェクトという単位です。なので、1つの事業に対して複数プロジェクトが存在する場合が多いです。 また、プロジェクト毎に必要なメンバーだけを招待する仕組みなので
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
