You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
2022.01.12 何度も挑戦し挫折してきたE2Eテスト、ついにSaaSのAI自動テストが福音となるか？！の巻 D.M.です。E2E テストのツール mabl について書きます。 TL;DR ・mabl はお手軽で素晴らしい。初期設定が簡単ですぐに開始できる。テスト作成とスケジュール設定が非常に簡単。修正もすぐにできる。 ・さすがに Google reCAPTCHA は突破できない（できたらそれはそれでヤバい）。Webアプリ側で仕様上の特殊な処理を設けるしかなさげ。 ・テストメール生成機能もあり非常に便利。（今回はうまく使えず。。） ・壊れたら自動でいい感じにしてくれる Auto Healing がすごい。逆に Auto Healing されたら困る、 NG にしたいケースでは Auto Healing をOFFにしたり、 Assert で正しい値が出ているかチェックするという逃げ道もあ
2021/10/13 に Selenium 4 の正式リリースがアナウンスされました。 Selenium 4 の変更点について調べたので、まとめておきます。 後方互換性のない変更 基本的には後方互換性ありですが、一部のコードに依存していると修正が必要です。 Selenium 4 へのアップグレード方法のドキュメントが↓にあり、プログラミング言語ごとに修正例が載っているので参考になります。 大きなところでは、Capabilities 系のクラスや findElement(s)By* 系のメソッドが使えなくなっています。細かいところでは Java だと Waits や Timeout 系の引数が Duration 型になっているなどいろいろあるので、アップグレードするときはちゃんと上記のドキュメントを読んで影響範囲を把握しましょう。 新機能 Relative Locators ブラウザ上の他の
いわさです。 AWS Device FarmはAWS上でホストされているデバイスでテストを行うことが出来るサービスですが、モバイルだけでなくデスクトップブラウザでもテストを行うことが出来ます。 最近Device Farmのデスクトップブラウザ機能にアップデートがあったので試してみたかったのですが、そもそもDevice Farmでデスクトップブラウザテストを実施したことがなかったので本日はまずそこから始めてみました。 デスクトップブラウザテストの仕組み Remote WebDriver モバイルデバイスでテストを実施する場合はAppiumを使ったテストコードをDevice Farmへアップロードし、クラウドでホストされたデバイスをターゲットにDevice Farm上でテストコードが実行されます。 これについては以前ブログ記事にしています。 デスクトップブラウザの場合は、SeleniumのRe
はじめに こんにちは。QAエンジニアの佐藤です。 以前ブログを書いたのが1年以上前ですね... 時間が経つのは本当に早いです。 tech.andpad.co.jp あれからSlackのアイコンは複数回変わり、今は "ミミッキュ" ではありません。 ということで、 Autifyを1年3ヶ月使い続けてきた振り返りをしてみたいと思います。 autify.com 目標に対しての達成率 以前のブログで 現状は、当初目標としていた主要動線テストの1/3を自動化できましたが、今年中には1/2以上は自動化していきたいと思っています。 と目標を立てていました。 実際どうだったでしょうか？(`･ω･´) ・ ・ ・ 達成しました＼(^o^)／ 888 今年の4月に行われたイベントで 88% を自動化できている、と報告がありまして、 Autifyで自動化できるケースは自動化しきりました。 目標達成していますね！
というのを使っていて思ったのでレポを書いていきます。 mabl とは - 基本的な機能 ざっくり言うと E2E テストをお手軽にメンテできるツールです。 こんな感じでポチポチ画面を操作していくと、それで実行したアクション(ボタンやリンクをクリックするなど)を自動で記録してくれて、E2E のテストを作成することが出来ます。 コードを書かずに E2E テストをサクッと作れちゃうのが魅力な訳ですが、それだけではありません。そんなすごいところを紹介していこうと思います。 mabl のここがすごい Auto Healing 何やら回復魔法みたいな感じでかっこいいですが、何かというと E2E テストがコケるようになった時に自動で修復してくれる機能です。 例えばボタンの位置が変わってしまっても、同じ文脈であろうボタンを自動で探して修復したりしてくれます。 E2E での辛さといえば、やはりテストのメンテナ
メルカリの自動化＆品質保証グループ（Automation & QA Group：通称AQA）の おれたま@AHA_oretama です。 私は普段、テスト自動化やCI / CD を主に行っています。 今回は、Appium×Android E2Eテストのテスト結果の見やすさを改善し、テスト結果を可視化することで気づきが生まれた話について、紹介していきたいと思います。 テスト結果の見やすさ、可視化の重要性について いま使っているテストレポートの課題 Allure Framework 並列化した分だけレポートも分かれてしまうことへの対処 スクリーンショット、スクリーンレコード以外のアタッチメントを追加することができないことへの対処 過去のテスト結果と比較できないことへの対処 他の改善点 テストのタイムラインが見える トレンドも表示できる Looker 生まれた気づき 課題 終わりに テスト結果の
2017/02/03 JaSST’17 Tokyo
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く