質とスピード(2022春版、質疑応答用資料付き)
テストの学習へようこそ! コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 このコースでは、ウェブ用のテストの概要と探索について説明します。 このコースで学習する内容は次のとおりです。 テストの基礎 自動テストと手動テスト テストを実施する場所と方法 ベスト プラクティス 何をテストすべきか、誰に責任があるのか、目的そのものとしてではなく、目的を達成するために手段をテストすることを検討する方法など、テストの理念。 このコースには、学習に役立つ簡潔で実用的なサンプルコードも含まれています。 コースのスコープには、Node.js などの環境で実行される、フロントエンドの JavaScript とドキュメント モデル、バックエンドでのライブラリ テストが含まれます。テストの経験はありませんが、JavaScript の基礎知識と Node.js などに関する経験が必
というのを使っていて思ったのでレポを書いていきます。 mabl とは - 基本的な機能 ざっくり言うと E2E テストをお手軽にメンテできるツールです。 こんな感じでポチポチ画面を操作していくと、それで実行したアクション(ボタンやリンクをクリックするなど)を自動で記録してくれて、E2E のテストを作成することが出来ます。 コードを書かずに E2E テストをサクッと作れちゃうのが魅力な訳ですが、それだけではありません。そんなすごいところを紹介していこうと思います。 mabl のここがすごい Auto Healing 何やら回復魔法みたいな感じでかっこいいですが、何かというと E2E テストがコケるようになった時に自動で修復してくれる機能です。 例えばボタンの位置が変わってしまっても、同じ文脈であろうボタンを自動で探して修復したりしてくれます。 E2E での辛さといえば、やはりテストのメンテナ
テストとは人によって反応が分かれるものの1つであり、大喜びする人もいれば、見ないようにして去ろうとする人もいます。あなたがどちらの側であるにせよ、ここではフロントエンドのテストは皆のためのものであるということを説明します。実際、テストには多くの種類があり、それがテストに対して初めに恐れや混乱を感じる一因なのかもしれません。 この記事では、特に有名で広く利用されている種類のテストを扱います。なかには目新しいものはないと感じる読者の方もいらっしゃるかもしれませんが、少なくとも復習にはなるでしょう。どちらにせよ、筆者の目標は、この記事を通じて世の中のさまざまな種類のテストについて理解を深めてもらうことです。ここではユニットテスト、統合テスト、アクセシビリティテスト、ビジュアルリグレッションテストなどを一緒に見ていきます。 さらに、Mocha、Jest、Puppeteer、Cypressなど、各種
こんにちは、Software Engineer in Qualityチーム(通称SEQチーム)の @teyamagu です。 私たちのチームは普段自動/手動テストの基盤開発や開発フィードバックサイクルの高速化に向けた開発をおこなっています。 その一環で、先日、社内でfreeeの自動テストシステム全体像を共有したのですが、この辺りのことを社外の友人達と話したところ、自動テストの具体的な構成や普段の運用など事例が少なく、どんなことをやっているのかイメージしにくいとの話を伺ったので、社内向け原稿をちょっと手直しして、おすそ分けと言うことで、ここで紹介します。 特に変わったことをおこなっているわけではありませんが、自動テストの関係性の理解に参考になれば幸いです。 基本的な考え方 自動テストが既存のデプロイ・リリースのブロッカーではなく、開発のフィードバックを加速させるために、自動テストそのものが高
GitHub Actions で Windows IE11 と Mac Safari を selenium-webdriver で動かすSeleniumselenium-webdriver 最近得た天啓で、 「GitHub Actions はコンテナを windows / mac / ubuntu から選べるということは、 本物の safari と ie11 を selenium-webdriver で動かすことができるのでは?」 と思ってガチャガチャやってみたら、なんとできてしまったので、紹介します。 今回は node で。 name: xbrowser on: [push] jobs: e2e-ie: runs-on: windows-latest steps: - uses: actions/checkout@v1 - uses: warrenbuckley/Setup-Nuget@
この記事では、Playwright の VSCode 拡張を使って GUI 操作のみでテストの記録や実行する方法について紹介します。 Playwright の VSCode 拡張とは? Playwright の VSCode 拡張は、Playwright の作成元である Microsoft が公式に提供している拡張機能で、VSCode 内で直接ブラウザテストの記録や実行を支援するための便利なツールです。 GUI 操作を中心に、テストの記録や実行を手軽に行うことが可能となります。 VSCode 拡張のインストールは、以下のリンクから行うことができます。 VSCode 拡張を活用してテストを書く 本記事では、シンプルな ToDo アプリを例にテストの作成方法を説明します。Playwright のインストール方法は、公式ドキュメントをご参照ください。その後、VSCode に Playwright
新しい UI テストの手法を提供するテストライブラリ SafeTest 2024.02.25 SafeTest は Playwright と Jest/Vitest を組み合わせた UI テストライブラリです。特定のライブラリに依存せず、React, Vue, Angular, Svelte などのフレームワークに対応しています。SafeTest は単体テストと Playwright を使った E2E テストの手法を組み合わせることで、それぞれの手法が抱える欠点を補うことを目指しています。 SafeTest は Playwright と Jest/Vitest を組み合わせた UI テストライブラリです。特定のライブラリに依存せず、React, Vue, Angular, Svelte などのフレームワークに対応しています。 従来のフロントエンドのテストの手法は Testing Libra
Chrome DevTools: Record tests with the puppeteer recorder Last updated: 25th November 2020 Introduction The Puppeteer Recorder feature in Chrome DevTools can monitor your webpage interactions and generate the code to automate a browser. For example, if you click on an element and type an email address into an email field, the recorder can generate the following code: await page.click("aria/Login")
こんにちは。SmartHR プロダクトエンジニアの sasaki (@s_sasaki_0529) です。 今回は、私が開発に携わっている届出書類機能における E2E テストを、Capybara + Selenium の構成から Playwright に移行し、開発プロセスに組み込んだお話をします。 扱う話題 E2Eテスト基盤を移行する具体的な背景と理由 移行における提案から、合意形成までの流れ 移行後の開発プロセスがどう変わったか 扱わない話題 Playwright など、記事内で扱う技術要素自体の詳細説明 移行作業自体の詳細 テストコードの設計・実装に関する具体的なテクニック なお、本記事では便宜上、移行前の E2E テストを「旧テスト基盤」移行後を「新テスト基盤」と呼称します。 届出書類機能について E2Eテストに限らず、テストというのはプロダクトの特性によって最適な手法は大きく変わ
はじめに こんにちは。ソーシャル経済メディア「NewsPicks」の QA/SET チームの海老澤です。 先日 弊社で E2E テスト実行するために Playwright を導入したため紹介させてください。 E2Eテストとは E2Eテスト(エンドツーエンドテスト)とは、ソフトウェア開発におけるテスト手法の一つで、アプリケーションが実際の運用環境と同様の条件下で正しく動作することを確認するためのテストです。 システムの開始点から終了点までを通じて、ユーザーの視点でアプリケーションのフローを追い、機能全体が連携して期待通りに動くかを検証します。具体的には、ユーザーが行うであろう一連の操作をシミュレートして、データがシステムを通じて適切に流れるかや、最終的なアウトプットが正しいかどうかを確認します。E2Eテストにより、部分的な単体テストや統合テストでは見逃されがちな問題を発見することができます。
こんにちは。AutifyのSET(Software Engineer in Test) 、末村(@tsueeemura)です。 皆さん、E2Eテストしてますか?以前はほぼSelenium一択みたいなところがありましたが、最近はPuppeteerやCypress、TestCafeなどいろいろなフレームワークがあり、ついつい目移りしてしまいますね! さて、どのフレームワークを使うにせよ、E2Eテストを書く上で共通で意識しないといけない重要なファクターがいくつか存在します。 その一つが ロケータ です。操作や検証の対象となる要素を指定するためのキーのことです。 ロケータにはCSSセレクタやXPathが利用でき、idやclass、name といった属性を利用するのが一般的です。 今回はこのロケータについての話を書こうと思います。 ロケータとは 要素を一意に指定できさえすればロケータに使うものは何で
こんにちは、辰巳です。 第3回は「スナップショットテスト」をテーマにお送りします! 「組織が拡大する中で、十分な設計情報がない状況でも、複雑に改修が積み重なったソフトウェアをいかに安全かつ正確に変更できるか?」 本記事では、数多くの大幅なシステム変更の経験を経て、この課題に対してモノタロウがいま実践しているグッドプラクティスを紹介します。 本記事の初出は、 Software Design2021年10月号「Pythonモダン化計画(第3回)」になります。過去の連載記事は以下を参照ください。 第1回 Software Design連載 2021年8月号 Python製のレガシー&大規模システムをどうリファクタリングするか 第2回 Software Design連載 2021年9月号 「テストが無い」からの脱却 スナップショットテストの可能性を追求する モノタロウは、事業者向けの間接資材を販売
最近MailosaurというSaaSを使ってメール送信機能をテストしてみましたので、備忘がてら紹介メモを残しておきます。 Mailosaurとは? Mailosaurとは Email and SMS testing platformだそうです。 mailosaur.com メールがちゃんと送れているか?だとかメール本文/添付ファイルなどは意図通りか?をテストするのに便利な機能が提供されています。 Mailosaurってなんて読むの? 以下の動画をみたところ、カタカナだと「メイラソー」のように呼ばれていました。 www.youtube.com どんなことができるの? EメールやSMS関連のテストを行うための様々な便利機能が提供されています。 詳細は以下のドキュメントに記載されています。 mailosaur.com 例えばEメール関連ですと以下のような機能が提供されています。(上位プランのみの
インターネットやAIを駆使しながら、領域に捉われずにさらなる挑戦を行うDeNAの取り組みを紹介する「DeNA TechCon 2023」。ここで認証認可システムのリノベーションチームの岸直輝氏が登壇。Shift Leftの考え方を基に実践している静的解析や自動テスト、挙動の差分を自動で発見するための取り組みについて紹介します。全2回。後半は、各フェーズにおける、静的解析・ユニットテスト・E2Eテスト、それぞれの取り組みについて。前回はこちら。 静的解析のメリットとデメリット 岸直輝氏:では、ここからは今お話ししたShift Leftの具体的な取り組みについて見ていきましょう。ここでは、各フェーズごとに対応する取り組みを、静的解析、ユニットテスト、E2Eテストの3つに分けて紹介します。 まずは静的解析について。静的解析は、プログラムを実行することなく、静的にさまざまな異常を検出する手法です。
runn is 何? 3行まとめ 今回はAPIシナリオテストツールのrunnをプロジェクトに導入し、一部機能のコントリビュートしながら3ヶ月間触ってみておすすめだと感じたことを記事にまとめたいと思います。 runnとの出会い 4ヶ月ほど前にスキーマ駆動開発を行っているプロジェクトでいい感じのAPIのテストをしようと色々 調査 をしていました。 その当時はOpenAPIでスキーマ定義してswagger-uiからポチポチ手動テストをしていましたが、APIの数も増えるし同じAPIでもパターンが結構あり、流石に手動でのテストでは限界があるなーと考えていました。 パラメータ数も多いのでControllerテストで書くにしてもコード量が多く、レビューが辛いと感じていました。 APIをE2Eでテストしたい、最終的にはCIで自動テストまでもっていきたいと思いました。 しかし、いざ調べてみると案外ニーズにマ
特によく使われる上二つのサービスでは”Webアプリケーションのテスト環境"を提供しており、インターネットに公開されたWebアプリケーション、開発中のローカルのWebアプリケーションのテスト環境が揃っています。 テスト環境 = テスト用アプリケーションがデプロイされ、ホストされている環境 テスト実行環境 = 上記テスト環境にアクセスし、テストを実施するためのデバイス・ブラウザ・OSを含む環境 BrowserStackはクラウド上で後者の「テスト実行環境」を提供しています。 BrowserStack Live (手動テスト) BrowserStackにホストされている様々なデバイスを利用し、マニュアルテストすることが可能です。画像ではiPhone13のデバイスを立ち上げ、Webのダッシュボード上で操作を行っている様子です。シミュレータではなく、実機デバイスをブラウザ上から操作できます。 Bro
こんにちは。QA Engineerの@testtattoです。 今回はE2Eテストの自動化にあたって、どういった考えでツール選定を行ったのかを話したいと思います。 対象読者 以下に興味や関心を持つ方を対象読者として想定しています。 E2Eテスト自動化によって課題を解決したいが、どういった技術があるのか分からなくて困っている人 E2Eテストの自動化は実現できているが、継続に課題を抱えている人 テスト自動化なら何でも興味がある人 まえがき 読んでもらう前にいくつかの前提を共有します。 リリースサイクルについて 当社のwebプラットフォームのリリースサイクルは一部のマイクロサービスを除いて基本的には週次です。 決まった曜日で各プロダクトのプルリクエストを取り込んで、リグレッションテストを実施し、リリースブロッカーがなければリリースしています。 流れとしてはこんな感じです。 月 火 水 木 金 特
Mercari Advent Calendar 2019も、この記事を入れてあと3個となりました。最後まで読んでくださいね。 23日目はAutomation&QAグループで、Webのテスト自動化を行っている@AHA_oretamaがお送りします。 今回はWebの自動テストについて、この1年やってきたことを振り返ってみようかと思います。 Webのリアーキテクチャ 現在、Webではリアーキテクチャを進めています。 進め方としては既存のモノリシックなWebアプリケーションを残したまま、パス(例えばトップ /jp/ や検索ページ /jp/search/ )ごとに新しいWebアプリケーションにマイグレーションする方法をとっています。 影響範囲を小さくしつつその範囲の中でチャレンジが行えることがこの方法の利点です。 詳しくは去年のMercari Tech Confの資料をご覧ください。 speaker
こんにちは!フロントエンド開発課のkoki_matsuraです。 この記事では、僕が開発に携わっている製品のE2Eテストに取り入れたページオブジェクトモデル(POM)という実装パターンの概要と取り入れたキッカケ、POMへリファクタリングする簡単な例をご紹介させていただきます。 僕と同じようにE2Eテストに関わっている方、E2Eテストに興味を持っている方などに読んでいただけると幸いです。 目次は下記のようになっています。 POMとは なぜPOMを使い始めたのか POMへのリファクタリング ログイン画面 テスト内容 POM導入前のテストコード ページオブジェクト作成 POM導入後のテストコード 終わりに POMとは Webアプリケーションのテスト自動化において、テストコードとWebページを分離して管理する手法です。 POMを使わない従来のテストコードはWebページと分離しないため、どうしてもD
これは Livesense Advent Calendar 2022 DAY 20 の記事です。 はじめに 株式会社リブセンスの転職会議事業部Webエンジニアの @ishitan-liv です。 今回は、過去に転職会議でも導入しようとして挫折してきたE2Eテストについて書きます。 E2Eテストを自作するか、SaaSを使うのかで比較した結果と、Datadog Synthetics Testsの使い方を軽く紹介したいと思います。 なお、この導入については完全に個人プロジェクトとしてやっております。 リブセンスではエンジニアの権利として毎月10%の技術投資枠確保というものがあり、Googleの20%ルールのようなもので、約20日勤務だと想定して2日間は興味のある技術的なことに使えます。 grow.google はじめに このブログ記事を読むと得られる(と思われる)もの 今回書かないこと 導入検討
こんにちは。 『マネーフォワード クラウド経費』のフロントエンドエンジニアをしている木村(@kimromi)です。 Ruby on Railsを利用してサービス開発を進めているプロダクトのフロントエンドの環境を整えていき、UIの改善やフロントエンド側の開発効率アップなどにつなげていくような動きを現在やっています。 なぜクロスブラウザのE2Eテストが必要になったか ある日、IE11のみでJavaScriptエラーが起こり動作しないとの連絡が入り、慌てて対象のプルリクエストをリバートしたということが起こりました。 原因としてはライブラリの追加によるものでした。 現在フロントエンドの改修を行っていく中で、ライブラリの追加やビルド方式の変更などドラスティックな変更をすることが多くなってきています。 そのたびにMicrosoftからダウンロードできるVM環境を立ち上げ手元で確認するのは手間がかかり確
こんにちは。BacklogのGit機能の開発を行っているテリーです。 今回はGitチーム(後述する僕の所属するチーム)でAutifyによるリグレッションテストの自動化を進めてみて感じたメリットと工夫したところ、苦戦したところを紹介したいと思います。 スモールチームの規模感とテストの現状 BacklogのGitチーム 長らくBacklogは固定のチームが専任で固定の機能をみるような体制になく、アプリケーションエンジニアが比較的流動的にBacklog全体の機能を担当しており、なんとなく“この人”は“この機能”が得意というような体制でした。 ですが最近のチーム編成により固定のチームが固定の機能を開発するようなフィーチャーチームがいくつかできました。Gitチームはその中で生まれたBacklogのGitの機能についての開発責任を持つチームです。チームメンバーは3人で、そのメンバーでインフラからフロン
こんにちは、フロリアでQAエンジニアをやっている中園です。 現在サイボウズではkintoneのフロントエンドリアーキテクチャプロジェクト(フロリア)と称して、Closure Tools から React へと置き換えるプロジェクトが進行中です。 今回は、フロリアのチームの1つであるMiraチームのテスト手法について紹介します。 フロリアの詳細については次の記事をご覧ください。 フロリアについて フロリアでは、次のような構成でそれぞれのチームがオーナーシップを持って活動しており、テストの方針はチームごとに決めています。 プロダクトオーナー: 1名 エンジニア: 3-4名 QA: 1名 スクラムマスター: 1名 フロリアのチーム構成 チームのミッションに合わせたテストの目的 Miraチームでは、kintoneのデザインやふるまいを変えずに、利用者に気づかれない形でReactに置き換えるというミ
TestCafe で E2E テストを始めよう #1 - 概要説明 と Hello World wakamsha 2020.03.06 132 1516848 TestCafe とは? TestCafe とは、Developer Express Inc. というアメリカのシステム開発会社が開発している E2E テストツールです。 A node.js tool to automate end-to-end web testing | TestCafe 同社はもともと TestCafe Studio という IDE(E2E テストケースオーサリングツール)を商用として提供していましたが、2016 年に TestCafe Studio のコア部分を OSS として提供するようになりました。今回ご紹介するのは、このコア部分についてです。 シリーズ一覧 概要説明 と Hello World 👈 こ
はじめに こんにちは。QCの佐藤です。 月日が経つのは早いもので、QCメンバーも増え、多くのメンバーがブログを書いてくださっており嬉しい限りです😊*1 ANDPADで韻を踏む - ANDPAD Tech Blog アンドパッドラップの作り方 - ANDPAD Tech Blog QAがGoで始めるテストデータ作成の自動化 - ANDPAD Tech Blog ANDPADのQualityControlを紹介します!2023 - ANDPAD Tech Blog 私がブログを書いたのはもう2年前...(徐々に間隔が長くなっている...) 今回は私の担当しているプロジェクトでの、E2Eテスト管理・運用方法についてお話します。 以下のような課題ってE2Eテストあるあるですよね (´;ω;`) E2Eテストの運用が属人化してしまっている... むか~しに作ってからはただ回しているだけ... テス
はじめに こんにちは。SRE部BtoBチームの田村です。BtoBチームにてECサイトの購入テストや会員登録等のテストを行う際には、これまでSeleniumを利用して毎日LinuxのChrome環境にて実行しておりました。しかしながらフロントエンドが変更された場合に、ソースコードの調整をしたりサーバー保守対応も必要で、運用コストを割かれることもしばしばありました。テストにおける自動化やテスト品質の向上及び運用コストの削減を目的として、今回AutifyというE2E自動テストツールを導入しました。 BtoBチームのE2Eテスト BtoBチームのE2Eテストは、Seleniumを用いて会員登録や購入テストを毎日実行しており、Slackにテスト結果を通知しています。エラー時には、サーバーに入ってログ閲覧し問題ないかを確認していました。そして、新しいテストパターン追加の要望があった場合にはソースコード
npm init playwright@latest 実行すると @playwright/testがインストール playwrightの設定ファイル(playwright.config.ts)が追加 サンプル用のテストコードが追加 が行われます。 テストコード自動生成 playwrightにはブラウザ操作でテストコードを生成する機能があります。 package.jsonのscriptsに以下を追加してnpm run test:genするか、 "test:gen" : "playwright codegen" npxでも実行できます。引数のURLは任意です。 npx playwright codegen http://localhost:3000/
前職である株式会社はてなの最終出社を2月19日に終え、本日 Autify に入社しました! Autify は、同名のE2Eテスト自動化のSaaSプロダクトを開発・提供しています。 autify.com さきほど初日としての業務を終えたところです。ありがたいことに、非常に高い期待を掛けてもらっていることをひしひしと感じていて、初日にインプットしてもらえた情報量も半端ないのですが、自分としては慌てず落ち着いてひとつひとつキャッチアップし、できるだけはやめに大きな成果を上げたいなと思っています。 職種は "カスタマーサクセスエンジニア" としての入社です。これまでの経歴で ソフトウェア(サーバーサイド)エンジニア セールスエンジニア Customer Reliability Engineer ......などの肩書で業務に取り組んできた自分としては、「事業の成長に貢献できることで自分ができること
こんにちは。N 予備校 Web フロントエンド開発チームの berlysia です。 N 予備校の Web フロントエンド開発に、 Storycap + reg-suit による Visual Regression Testing を導入しました。設定の工夫から、設定中や運用してしばらくの間に実際に発生したハマりどころを挙げ、簡単に注意点や対処例を紹介します。 背景 N予備校について N 予備校はドワンゴが提供するオンライン学習サービスです。大学受験対策、プログラミング、Webデザイン、機械学習など多様なコースがあります。オンラインでの利用に合わせた教材や、講師が生放送で行う授業、受講者同士でも質問し教えあえるフォーラムを備えています。 www.nnn.ed.nico 周辺状況 N 予備校の Web フロントエンド開発とそれを取り巻く状況には、次のような特徴があります。 React による
こんにちはかみむらです。 SPAの登場で状態管理が複雑化するに連れて、よりフロントエンドのテストが重要になってきました。 しかし、なかなか導入できていないところが多いのではないでしょうか。その中でもE2Eテストは工数の兼ね合い、優先的にテストできない工程ですよね。 そこで、今回は導入コストが低いCypressで、フロントエンド(React)のE2Eテストについてご紹介します。 Cypressとは? Cypressはブラウザでのテスト作業を自動化するテストフレームワークです。オープンソースできています。 これまでのE2EテストはSeleniumが主流でしたが、最近はCypressも勢いを増しています。 また、Cypress DashboardというSaaSもあるので、これらをうまく組み合わせることでチームでのテスト効率をあげることに繋がります。 今回はCypressを使ってフロントエンド(R
ウェブサイトやモバイルアプリの、エンドユーザーからみた動作を確認するテストはE2Eテスト(End-to-End Test)と呼ばれ、このE2Eテストの自動化ツールは、アジャイル開発の普及もあって、今では多くの開発現場で活用されるようになりました。ブラウザ操作の自動化ツールSelenium(セレニウム)は日本でも有名になり、ご存じの読者も多いでしょう。しかし近年、E2Eテスト自動化の世界では、Seleniumに代わる新たなツールがたくさん登場し、急速に利用者を増やしています。この記事では、これらの新しいE2Eテスト自動化ツールのトレンドについて紹介します。 E2Eテスト自動化トレンドの変遷 筆者はテスト自動化ツールを作る仕事にもう15年近く関わっていますが、これまでのトレンドを見ていくと、「非OSS(非オープンソースソフトウェア)の時代」「Seleniumの時代」「多極化の時代」の3つに分け
はじめに ZOZOMO部プロダクト開発ブロックの木目沢です。 ZOZOMOで提供しているZOZOTOWN上での「ブランド実店舗の在庫確認・在庫取り置き」APIの開発に携わっています。 今回は、開発当初から現在に至るまでのユニットテスト戦略についてお話しします。 意識してテストを書いていたのにカバレッジが低い問題 2021年11月にリリースされたブランド実店舗の在庫確認・在庫取り置きの機能ですが、開発当初のユニットテスト方針は以下のようなものでした。 モデルのユニットテストは必ず書く モデル以外の箇所は可能な範囲でユニットテストを書く 当時は実装のコードよりテストコードを先に書くといった文化はなく、レビューでテストの有無や内容を指摘する程度のものでした。 カバレッジも取っており、GitHub上では見える化していたものの、いつの間にか確認する機会も失われていきました。 もちろん、リリース前には
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く