マイクロソフトは、Webアプリケーションのテスト自動化ライブラリ「Playwright」を用いた、Microsoft Azure上のテスト自動化サービス「Microsoft Playwright Testing」のプレビュー公開を発表しました。 Microsoft Playwright Testingに使われている「Playwright」は、マイクロソフトが中心となってオープンソースで開発しているWebアプリケーション向けテスト自動化ライブラリです。対応環境が幅広く柔軟で、精度の高いテストを特長としています。 具体的には、Chrome、Edge、Firefox、Safariの主要なWebブラウザのすべてを対象にしたテスト自動化が可能で、ヘッドレス、ヘッドありのいずれにも対応。モバイルエミュレーションを用いたAndroid版Google ChromeとMobile Safariのテストも、実
こんにちは、辰巳です。 第3回は「スナップショットテスト」をテーマにお送りします！ 「組織が拡大する中で、十分な設計情報がない状況でも、複雑に改修が積み重なったソフトウェアをいかに安全かつ正確に変更できるか？」 本記事では、数多くの大幅なシステム変更の経験を経て、この課題に対してモノタロウがいま実践しているグッドプラクティスを紹介します。 本記事の初出は、 Software Design2021年10月号「Pythonモダン化計画（第3回）」になります。過去の連載記事は以下を参照ください。 第1回 Software Design連載 2021年8月号 Python製のレガシー＆大規模システムをどうリファクタリングするか 第2回 Software Design連載 2021年9月号 「テストが無い」からの脱却 スナップショットテストの可能性を追求する モノタロウは、事業者向けの間接資材を販売
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
くっ、名前だけ知ってたけどこんなの便利だとは…！！ marketplace.visualstudio.com Azure API Management の Visual Studio Code 拡張機能で API のテスト呼び出しに REST Client が使われてるので使い始めてみたのですが「あっ、ハイ。便利っすね…」という感想しか出てこないくらい便利でした。 普通に HTTP のリクエストをテキストで用意しておくと Send Request 押すだけでレスポンスを出してくれる…。 先人の方々が沢山紹介してくれてる記事があるので詳しい使い方とか推しのポイントはそちらを見るとわかりやすいと思います！ qiita.com 私の推しポイント 上記記事にも書いてありますが、1ファイルで複数のリクエストを書いておいて、個別に実行できるので特定の API をテストで叩くためのファイルを 1 つ用意
はじめに 最近、意図的に「単体テスト」「結合テスト」という呼び方を避け、Google Testing Blogで紹介されてるTest Sizesによる分類（small / medium / large）に従った呼び方でテストを呼んでいる。 この分類方が自分の身の回りに徐々に浸透してきて、実際のチーム内のテスト戦略も一歩進んだ議論ができるようになってきたので、改めてまとめる。 ちなみにこの記事の話は手動で行われるテストではなく、自動テストを対象としているが本質はあまり変わらないと思う。 続き書きました。 akito0107.hatenablog.com 「単体テスト」「結合テスト」という呼び方について ソフトウェア開発に従事していれば必ず聞く言葉だと思う。改めて他のサイトから引用する形で定義をまとめておく。 単体テストとは *1 単体テストとは、プログラムを検証する作業の中でも、プログラムを
Test Engineers Meetup #2 https://test-engineers-meetup.connpass.com/event/50496/
最近、ソフトウエア開発にて、テスト技術者が要件定義からレビューに入る件について、いろいろ話を聞いたので、まとめておきます。 これは、ちょっとかっこよく言うと「Wモデル」という、テスト担当者の作業と開発の作業を同時並行で行っていくVモデルの進化した開発モデルが目指すゴールの一つです。ただ、話をしてくれた人は、Wモデルという言葉を知っているわけではありません。 その人の組織では、1980年代後半から、独立したテストを行っているとのことです。開発したものの統合テスト以後のテストだけを請け負うテスト専門部隊です。 Windowsが出る前はCOBOLで作った会計プログラムを対象にしていて、それがWindowsが出たころに全てWindowsアプリになり、それが今では全てWebアプリになり、クラウド上で動くようになっているという感じです。今では、そこの組織では、要件定義の段階からドキュメントをテストチー
2017/02/03 JaSST’17 Tokyo
Qiita:Teamに投げた社内ドキュメントだったけど、特に問題ないのでQiitaにも投げる。 前提として browserify-rails とbabelify が導入されている状況を想定してる。 基本方針 新規コードはES2015で書く 本番はbrowserify(-rails)でコンパイルする。 単体テストは node 環境下で走らせる テスト環境下では jsdom で window, document をモックする 単体テストでは ブラウザ特有の挙動はテストしない 裏側の環境(browserifyやspec-helper)は難しくして良いが、利用者からみえる範囲は複雑にしない(npm install; npm testで走る) Universal JavaScript に寄せることでコードのポータビリティを上げる 事前準備 browserify-railsを導入する。 .babelr
開発のボトルネックはどこだ？―迷えるマネージャのためのプロジェクト管理ツール再入門 第12回テストにもっと光を！ 言うは易く行うは難し。テスト工程を改善しよう！（後編） みなさんはソフトウェア開発においてどのようなテストを実施されているでしょうか。単体テスト、結合テスト、総合テストなど、さまざまなテストを実施されていることと思います。では、これらのテストをどのように計画・実行し、管理されているでしょうか。 ソフトウェアの品質を向上・維持していくうえで、テストは非常に重要です。今回も前編に引き続き、その重要性が指摘されながら、あまり取り上げられることがなく、開発の花形である設計やプログラミングに比べて少々地味な役回りのテストについてお話したいと思います。 Zephyr流のテスト ソフトウェアの品質を向上・維持していくうえで重要なテスト。前編でお話したテストを管理する難しさについては、みな
こんにちは。リスペクトの木村です。 今日は、「MailCatcher」というRubyで使うGemライブラリの話をお送りします。 MailCatcher とは Samuel Cochran氏が開発した、シンプルなSMTPサーバーです。特に細かい設定は不要で、起動するだけでSMTPサーバーが起動します。(ポートは1025番) これだけであればよくあるSMTPサーバーなのですが、MailCatcherの特徴は「SMTPサーバーを経由したメールをブラウザ上から確認できる」という所にあります。送信しようとしたメールはMailCatcherのSMTPサーバーから先には送信されません。 Webサーバーが同時に起動(ポートは1080番)するので、ブラウザからアクセスすると下記のような画面が表示されるので、そこから確認できます。 届いたメールはほぼリアルタイムで受信トレイに表示されるため、リロードの必要はあ
Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode
5. 前職で実際にあった出来事 マネージャ 今回はテストファーストでやります ぐるぐる はい！ マネージャ なので、実装に入る前に テスト仕様書を完成させます ぐるぐる はい？ マネージャ テスト仕様書は実装開始までに Fix され、以降の変更は認めません ぐるぐる はいぃぃぃぃ？
『システムテスト自動化 標準ガイド』の翻訳を引き受けた経緯 テスト自動化研究会（略称：STAR）の森 龍二と申します。『システムテスト自動化 標準ガイド』（以下、ギア本[1]）の第1章の翻訳を担当しました。 ギア本の原著『Software Test Automation』が書かれたのは1999年。筆者はちょうどそのころ、あるプロジェクトで製品品質の問題を経験しました。それ以降、テストや品質について独自に調査したり、セミナーやWACATEなどのコミュニティに参加したりしてきました。テスト自動化研究会に参加するようになったのも、そうした活動の中でのことです。 筆者の現在の主な仕事は、開発成果物（仕様書、ソースコード）の第三者レビューです。テスト自動化は直接の業務ではなく、アドバイスを求められる程度です。そのため、デモや事例紹介という形でテスト自動化研究会にお返しすることができません。後ろめたい
こんにちは、やまもと@テスト番長です。 このエントリーは「GREE Advent Calendar 2014」13日目の記事です。 最近はグリーのQuality Assurance部のテストエンジニアリングチームを担当しています。 品質管理を行う部署のため、エンジニアブログに顔を出すのは初めてなのですが、 今回はグリーのQA体制のご紹介および、テストエンジニアリング面からの 取り組みをご紹介させて頂きたいと思います。 グリーのQA体制について QAチームは、2011年の夏にカスタマーサポートチームから派生する形で組織されました。 2012年に起きたカード複製の不具合や未成年課金の問題など、多くのトラブルを経験・奔走しつつも徐々に体制を整え、現在は社員20名・協力会社の方々も加えると50名ほどのグループとなっています。 ネイティブゲーム、ウェブゲーム、ガレージスタジオ＆プラットフォーム、テス
ご利用の皆様にはご迷惑をお掛けして、大変申し訳ございません。 メンテナンス終了まで今しばらくお待ちください。
WEB+DB PRESS の Vol.85 で、E2E テストの記事を書いたので是非読んでくださし。 2015/2/24 発売ですので、既に購入頂いてる方も多いと思います。 電子書籍版もありますので物理的な媒体に興味がない方は PDF を買って下さい。 WEB+DB PRESS Vol.85@Gihyo Digital Publishing 今回の記事における対象読者について Selenium は知ってるけど WebDriver の API 辛すぎﾜﾛﾀという方を対象に記事を書きました。僕もそうです。 WebDriver の API は本当に本当に使い辛いのですが Geb なら、それが大きく低減されますので是非一度さわってみて欲しいですね。 jQuery に似てるけど所々違う様な感じがする API 越しに DOM を検証するのは便利ですよ。それによって大切な何かを失ってる感は確かにありま
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか？もしくはコードカバレッジだけにとらわれすぎていないでしょうか？ 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く