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対象の増加により、テストの拡張性が求められた そんな背景から、「そろそろ別のアプローチも必要では？」と話し合うようになりました。 理想とする状態を設定する 闇雲に自動化を進めても意味はないため、まずは理想像を明確にしました
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
