ウェブアプリケーションの開発においてE2Eテストの自動化は身近なトピックです。SeleniumやPuppetter、PlaywrightやAppiumなどがブラウザ・ネイティブアプリの自動操作のOSSとしてよく挙げられます。しかし、それらの裏側はご存知でしょうか？ 本トークではこれらのツールの背後…

アプリケーションのテストなどで利用できる、リアルな架空の個人情報データ（疑似データ）を生成するツールです。

巷には今、「働き方改革」とともに「RPA」という言葉が台頭し始めている。RPAは「ロボティック・プロセス・オートメーション」のことで、普段の業務を自動化してくれるソフトだという。 こんな説明がなされているが、これまでプログラミングに触れてきた人にとってはやや疑問が浮かぶのではないだろうか。「Excelマクロやバッチと何が違うのか」と。 例えば、RPAの動作説明でよくあるのは「ファイルをゴミ箱に捨てる」という操作だ。RPAソフトがファイルをゴミ箱にドラッグ＆ドロップするという操作だが、ファイルを削除するのが目的なら、Windowsであれば「del hogehoge.txt」と書いたバッチファイルを実行すれば済む話だ。「del *.txt」とすればフォルダ内のテキストファイルを一網打尽に消すこともできる。 Webブラウザの操作であれば、「Node.js」や「Selenium」などですでに自動化

ページをどのくらいスクロールし、どこをクリックするのか、マウスやキーボードをどのように操作し、コンテンツを見るのか、ブラウザで行った操作を記録し、さらに完全再生もできるChromeの機能拡張を紹介します。 ユーザビリティテストに利用するだけでなく、操作を編集・再生することもできるので、プレゼンなどでページの操作を再現することも可能です。 Wildfire Wildfireの特徴 Wildfireのインストール Wildfireの使い方 Wildfireの特徴 Wildfireはユーザーがページをどのように操作するのか、どのように見るのか、手軽にユーザビリティテストができるChromeの機能拡張です。また、アクションをシミュレーションし、新しいデザインの確認にも利用できます。 ブラウザで表示したページのアクションを記録します。 記録したアクションは、すべて再生可能。 アクションを編集し、シミ

こんにちは、中島 (@nazomikan)です。 ※この記事は2016年に書かれた記事でver2系を対象に書いています。 ver3,4-betaで色々変わってるのでその辺についてのキャッチアップはこちらの記事をご利用ください 最近のselenium-webdriverの話 本記事は株式会社ネクスト(Lifull) Advent Calendar 2016の1日目の投稿です。 ブラウザベースのテストツールのseleniumをコードから実行するselenium-webdriverのnode版について導入からAPI紹介までしていきます。 あと手元で作業するにあたってAPIの翻訳(ソース上にうまってるdocsの翻訳)をしてたのでそれも載せておきます(むしろそっちメイン) 導入 webdriverのテスティングについて テストの書き方 よくある使い方 API翻訳 driverのAPI navigat

July Tech Festa 2015にて登壇した際の資料です。 なお後日、小河さんがOpen VASのCLI操作の解説について以下のスライドを追加投稿してくれました！ 「フリーでできるセキュリティチェック OpenVAS CLI編」 http://www.slideshare.net/abend_cve_9999_0001/openvas-cli-51048313Read less

https://atnd.org/events/66159 で実施したプレゼン資料

私は元々、株式会社 日立製作所で、主にエンタープライズ系システムの検査を生業としていましたが、昨年秋より所属が変わり、現在は組み込みソフトウェアの評価の仕事をしております。新しい職場ではテストの自動化業務も担当することになり、あらためてギア本を拾い読みしているところです。 本稿では、私が翻訳を担当したギア本の第3章「スクリプティングの技法」が、現在までにどのように変わってきているかについて述べたいと思います。 テストを自動実行するための5つのスクリプティング技法 第3章では、テストを自動実行するためのスクリプティングの「技法」として、5つのアプローチを解説しています。表現に少々一貫性がないように感じられるのですが、原書どおりなのでお許しください。 リニアスクリプト 構造化スクリプティング 共有スクリプト データ駆動スクリプト キーワード駆動スクリプト 簡単におさらいしてみましょう。詳しくは

ROI(t) = Δ手動テストに対するテスト自動化の利益 / Δ手動テスト対するテスト自動化のコスト = ΔB(t) / ΔC(t) ΔB(t) = Σ(自動テストによる固定費の削減分)(t) + Σ(n2回手動テストを実施した場合の変動費)(t) - Σ(n1回自動テストを実施した場合の変動費)(t) ΔC(t) = Σ(自動テストによる固定費の増加分)(t) + Σ(自動テストの開発費) - Σ(手動テストの開発費) + Σ(自動テストのメンテナンスコスト) (n1/N) n1 = 自動テストの実行回数 n2 = 手動テストの実行回数 N = メンテナンスが必要になるまでの自動テストの平均実行回数 今回は、この各要素を順に見ていきましょう。 自動テストによる固定費の削減分 「自動テストによる固定費の削減分」から説明します。まず、この「固定費」とは、「テスト計画」「テスト設計」など、「テ

クライアントからシステム開発案件を受注し、開発成果物を納品する際に、エビデンスとして、Excel上に貼り付けたスクリーンショット（以下、スクショ）を、成果物の仕様書や納品書と共に納品する場合がある。この作業は、クライアントに「こういったテストを実行しました」という証拠を提示するものとなる。クライアントに成果物の機能や制限事項などを説明する場合に大変に有効なものとなっているのが現状だ。 実際、Excel上に記述したテスト仕様書や納品書にスクショを張り付けて、成果物の一部として納品しておくと、後々何らかのトラブルが発生した場合も問題解決に大きく寄与することになる。 しかし現実問題として、成果物の機能のスクショを、Excel上に手作業で延々と張り付けていく作業は単純作業であることもあり、開発者にとっては苦痛この上ない作業だ。 そこで、そのような作業を自動化し手助けをしてくれるツールとして「Sel

技術部アルバイトの鈴木(@draftcode)です。 クックパッドが内部向けに開発・運用を行ってきた、分散テスト実行システムRRRSpecをオープンソースとして公開しました。RRRSpecは時間のかかる自動テストを分散処理することで、全体のテスト時間の短縮を狙うアプリケーションです。現在クックパッドでは17000を超えるテスト項目があり、マシン一台でテストを実行すると完了まで数時間かかります。このテストを60並列程度の分散処理で行うことで、平均8分から9分程度で完了できるようになりました。また、Amazon EC2のスポットインスタンスを利用することにより、大幅なコスト削減も同時に達成しました。 https://github.com/cookpad/rrrspec 分散テスト実行とは アプリケーションが大きくなるにつれて、自動テストの数も大きくなっていきます。クックパッドでは、非常に多くの

今日は、テスト自動化と、ブラウザ自動テストツールSeleniumについて、知らない方でも分かるようイチから解説したスライドを作ったのでご紹介します。 このスライドは、2014年2月28日に開催された「Enterprise × HTML5 Conference」の発表スライドに、時間の関係で省略した多数の未発表ページを加えたものです。 イチから分かる解説についてはこれで終わりですが、せっかくですのでスライドの見どころをご紹介しましょう。

JenkinsとSeleniumでJavaScriptのテスト自動化、最初の一歩。第1回 日本Seleniumユーザーコミュニティ勉強会 1月18日に都内で開催された「第1回 日本Seleniumユーザーコミュニティ勉強会」。Seleniumプロジェクトの共同設立者であるJason Huggins氏による基調講演に続いて、有志によるライトニングトークが行われました。 本記事ではその中から、玉川紘子氏による「Jenkins x Selenium 最初の一歩」の内容を紹介します（追記：本記事のタイトルは「JenkinsとSeleniumでJavaScriptのテスト自動化」とありますが、実際の内容は「Selenium RCがJavaScriptの技術を用いて自動テストを行っている」という点がポイントという指摘がありましたので、ここに追記します）。 Jenkins x Selenium 最初の一

本記事の編集方針 ※この記事に興味をもたれた方は、 A/Bテスト カテゴリーの記事一覧 - 廿TT も、必要に応じてご覧いただければと思います。 本記事はもともとは、「A/Bテストの数理」への批判：「有意」とはなにか の続き的なエントリでした。 しかし、予想外に反響があったため Request for Comments（ご意見求む）の精神で、随時更新している部分もあります。 ただし、ベースとなる主張、Web系施策のA/Bテストに、仮説検定は向かないという部分は変化していません。 もしぼくの考えが変わり、「やっぱ仮説検定、いいかも」となった場合、本記事の存在価値はほぼ消滅します。 そのようなことがあれば、ページ最上部に「考えが変わりました」と明記します。 また、他の修正箇所も区別して明記し、差分がわかるようにします。 ただし細かい言い回しや、誤字脱字等はだまって修正します。 目次： そもそも

年々、ウェブアプリを開発するときにテストを書こうという機運が強くなっていると感じる。 これは、開発パラダイムの成熟を意味することであり、基本的に良いことだと思っている。 しかし同時に「テスト原理主義」とでもいうような極端な考え方もでてきていて、開発スタイルをめぐって摩擦が起こっている。 そして、この議論は「テストは、ないよりあったほうが良いよね」という、微視的には誰も反論できないロジックに押し通されがちで、「地獄への道は善意で舗装されている」の典型的な現象に見えて仕方がない。 テストを書かない、というと背景にどんな深い考えがあっても素人くさく聞こえ、逆にテストを書くというだけで良いプログラマーに見える、という非対称な化粧効果がある。ソフトウェア・コンサルティング会社がテスト好きなのは決して偶然ではない。 ソフトウェアというのは、結局のところ、動いてナンボ、使われてナンボである。 期待するも

テストを行っている品質保証チームや、実際にシステムを使っているお客様から不具合が報告されたとき、あなたはどう思いますか？ 悲しんだり、恥ずかしいと思い、不具合修正にすぐに着手したいと気がはやるのが人情というものです。しかし、焦っているときに行う作業はしばしば視野が狭く、一つの不具合修正が三つの新たな不具合を生んでしまうようなことになりがちです。 テスト駆動開発（TDD : Test Driven Development）は、プログラマが自分の不安を克服し、自分が書くコードに自信を持ちながら一歩一歩進んでいくための手法です。不具合の発生は、端的に言えばこれまでの「自信」を揺らがせる事態です。テスト駆動開発者は不具合にどう立ち向かうのでしょうか？ やはりテストを書いて立ち向かってゆくのです。私はテスト駆動開発を数年間実践してきた中で、心がけているひとつの「掟」があります。それは「不具合の修正時

アプリケーションの画面に対してボタンを押したり入力を行い、正しい結果や答えが返ってくるか？ ユーザーインターフェイスを含むテストコードの開発は一般に手間がかかり面倒であり、テスト用のライブラリやフレームワークが欠かせません。 Googleは、Android用のUIテスト自動化のためのフレームワーク「Espresso」をテクノロジープレビューとして公開しました。 Espresso - android-test-kit - a fun little Android UI test API - Testing Tools For Android - Google Project Hosting EspressoはこれまでGoogle社内で、Google DriveやGoogle Maps、Google+など30種類のアプリケーションのテスト自動化に使われてきました。 特徴は、軽量でシンプルな記述