Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
こんにちは。メルカリのテストエンジニアとして、スマホアプリのテスト自動化をぶりぶりしている@daipresentsです。 テスト自動化をすすめるにあたり、効率のよいテストを作るために、既存のテストケースについて調べる機会がありました。その過程で現状のQAプロセスも確認したのですが、以下のようなテストケース管理の課題があることがわかりました。 それぞれのテストエンジニアが、それぞれの方法で、それぞれのテストケースを管理しているため、ナレッジが横につながりにくい。 共有されているリグレッションテスト項目の更新が追いついておらず、情報が古くて使いにくい。 人数が増えてきて、ふりかえりや改善がやりにくい。 １については、現在、職能横断的なチーム構成になっているため、プロジェクトやプロダクトに集中できる環境である反面、それぞれのチームにいるQAエンジニアどうしのつながりが薄れてしまうことが原因に感じ
何年も前、SeleniumやWebDriverの話で盛り上がった記憶があります。ただ、その当時はまだRailsなどバックエンド中心の文脈でした。今、フロントエンドに軸足が移る中、ブラウザテストの状況はどうなったのでしょう? 不思議なことに、フロントエンド界隈でそれほど話題に上がって来ないですよね (私の周りだけ?)。結構大事なのに。実は皆さん、「Seleniumアレルギー」なんじゃないですか? 公式サイトに漂う ゼロ年代感(下図)。Javaへの躊躇、「めんどくさい」と聞かされ続けた過去、無意識に避けてしまうのがSeleniumです。 ただ、フロントエンドの文脈でこそ、ブラウザテストは重要度を増しています。そこで「Selenium触りたくない病」の筆者が、 四苦八苦した背景 と、2016年だからこそ 見えてきた落とし所 を書いてみたいと思います。 註: 思ったより長文になってしまいました。先
WebサイトやWebアプリケーションの文脈(フロント寄り)で、E2E関連ツールを整理してみます。いろいろありすぎるようでいて、「結局Seleniumかよっ」ていう話ですが...。ただ、クロスブラウザテストが不要であればNightmareは簡便な選択肢としてオススメです。個人的な見解はまとめ参照。 (当初『E2Eは「End to end」の略ですよ。まとめ』と題したのですが、「E2E」という用語がそれほど浸透していない?ようなので、改題しました) 以下、目次を兼ねて並べてみました。E2Eの文脈でないものも一部含みますが、全体像を把握するために入れてあります。変なところあれば、コメントでご指摘くださいませ。 E2Eテストツール | 使っているもの | 開発言語 | GitHub★ :-- | :--: | :--: | --: | --: Nightwatch | WebDriver | Ja
骨折しました。@kyo_agoです。 今日はTravisCI上で実ブラウザ環境のテストを行う方法を紹介したいと思います。 弊社ではこれまで実ブラウザ環境のテストではTravisCIからProtractorを使ってSauceLabsへ接続してテストを行っていました。 しかし、これには以下のような問題があったため、ProtractorとSauceLabsを使用しない構成へ移行しました。 テストが高頻度で失敗するテストに影響しない部分の修正ですらテストが失敗し、コードの修正よりテストを通すほうが難しい状況になっていました。 （これは社内では「e2eガチャ」と呼ばれ、レビュー依頼のコメントには「e2eガチャ 1/5」と成功率が書かれていました。ちなみに「1/5」はわりといい確率です。悪い時は「1/12」くらいになります） 遅いSauceLabsへの接続時間、WebDriver経由のテスト実行などは
こんにちは、QAエンジニアの井上恵一です。好きな飲み物は一番搾りと韃靼そば茶です。 初回からニッチなネタではありますが、昨年入社した直後に行った、 iPad アプリのテスト仕様書の管理方法を見直したときの話を紹介しようと思います。 見直しのきっかけ トレタは飲食店向けの予約/顧客台帳アプリです。だれでもかんたんに使いこなせるシンプルさを追求してはいますが、製品の進化に伴ってそのテストケース数はすでに数千という単位にまで膨れあがっています。 製品の品質を安定させるためには、テストの内容自体をブラッシュアップすることが重要なのは言うまでもありません。ただ、安定した製品を永続的に提供していくためには、それに加えて、膨大なテストケースを効率よくメンテナンスし続けるためのプロセス作りも欠かせません。 入社のタイミングでトレタのテスト設計を担当することになったので、テストケースの管理方法についてもいち
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 DZoneという海外のサイトで “The 20 Best Software Tester Interview Questions” (テストエンジニアの採用面接の際にすると良い20個の質問)がまとまっていたので紹介します。 ここにあがっている質問を必ずすべきかという話ではありませんし、完全な網羅性があるわけでもありません(カバレッジの話やブラックボックス・ホワイトボックスの話のような基礎的な質問も入っていないです)。 一方で、ある程度の規模になった組織においては、採用面接の質を向上させるために自分たちの組織で共通の質問集のようなものを用意しておくのはベストプラクティスの1つと言えます
Java テストツールのトレンド 2014/1～2016/5版 1. エコシステムに乗っかるべし 継続的インテグレーション（CI：continuous integration）は、もはや必須のプラクティスとなりました。ＣＩを実施するにあたり、できるだけ世の中でよく使われているツールやフレームワークを使うことが、エコシステムにスムーズに乗っかっていく鍵になります。マイナーなツールやフレームワークを採用してしまった場合の問題点を挙げてみます。 採用したツールの開発が停滞していてバージョンアップによる恩恵が受けられない。 他のツールのバージョンアップに採用したツールが追従できず、他のツールのバージョンアップの恩恵が受けられない。 足りない機能があり社内で色々作りこんだものの、社内のスピードよりも、世の中のスピードのほうが速く、システムの改修が世の中に追従できななくなってしまう。 CIシステムの維
概要 Property Based Test を実装するためのライブラリ「QuickCheck」の Java 移植版を試してみました。 Property Based Test とは 以前の渋谷Javaで @gakuzzzz さんがおっしゃっていたのによると下記のようなものだそうです。 テストデータを半自動生成……テストデータを管理する必要がない すべての値について性質を満たすことをテスト 機能変化や仕様変化に強い Java にも QuickCheck ファミリーのライブラリがある テストデータを作るのが面倒な場合や、あらゆる値を網羅的にテストしたいケースで役立つようです。なお、境界値テストのような固定の値を必要とするものは、通常通りの JUnit Test を書けばよいとのことでした。 Java の QuickCheck 実装 QuickCheck は Haskell のライブラリです。今
Selenium IDE(Firefox Plugin)で記録したテストスクリプトをSIT-WTで実行する方法を紹介します。 これにより、エビデンスの取得やテストケースの複製が簡単にできるようになります。 セットアップ SIT-WTのクイックスタートにある実行環境の準備を行ってください。 次に、以下ソフトウェアの最新バージョンをダウンロードしてインストールします。 Selenium IDE LibreOffice ※拡張子が「xlsx」のエクセルを編集できるソフトウェアがあれば、LibreOfficeはインストール不要です。 上記ソフトウェアの準備ができたらmyprojectというディレクトリを作成し、その中に下記pom.xmlをダウンロードして配置してください。 pom.xml myproject - pom.xml Selenium IDEでテストスクリプトを記録する Selenium
はじめに Selenideを触ってみたら簡単なUIテストがサクッと書けて感動したので、使い方をまとめました。 Selenideとは SelenideはUIテストのためのSeleniumラッパーです。 Selenide: concise UI tests in Java http://selenide.org/ Java界隈でUIテストといえばSelenium(WebDriver)が有名で、大変優れたツールです。ですが、SeleniumはUIテストのためのツールではなく、ブラウザ操作のためのツールです1。 一方、Selenideは初めからUIテストのために設計されていて、UIテストを「スラスラ」書いて実行できます。ブラウザの閉じ方とか、タイムアウトとか、StaleElement Exceptionsの扱い方などを考える必要はなく、ユーザはテストに集中できるのが売りです。 Three simp
AssertJ Core site has moved to https://assertj.github.io/doc/ This site is still maintained for AssertJ modules (until their documentation is migrated) Rich and easy to use AssertJ provides a rich set of assertions, truly helpful error messages, improves test code readability and is designed to be super easy to use within your favorite IDE. Get started right away with the one minute starting guide
ソフトウェアのテストはたいへんだなあ ソフトウェアのテスト、きちんとしてますか？最近は、スマートフォンやタブレットの普及に伴って、ユーザが使うデバイスの種類が多様化しています。 使われるOSやブラウザ、画面サイズの種類が増える中、プリキュア1の多様化も著しいですね。「プリキュアで学ぶワンライナーWebスクレイピング」で検証した通り、昨年までは43人、今年は「魔法つかいプリキュア」が加わることで、プリキュアの数は総勢45人になりました2。プリキュアはキャラクターによって専用デバイスを持ったり3、感情が昂ぶると常識を覆す事象を起こしたりするので、ITサービスを提供するエンジニアの方々は、ユーザ満足度向上のため、当然プリキュアがユーザになった場合も考慮した動作テストをされていると思います。 とはいえ、プラットフォームとプリキュアの組み合わせの数は、既にかなりの数です。全てのパターンを試すととても
テス太郎 @Tesutaro_JaSST 今日はJaSST Tokyo一日目。基調講演のテーマは今、トレンドのIoT。みんなビックなウェーブに乗りにいこう pic.twitter.com/1Yw6JByOgq 2016-03-08 10:06:57 テス太郎 @Tesutaro_JaSST セッション紹介の前にセッションIDの説明だよ。 セッションはABCDEFと6つ並行で開催されます。そしてチュートリアルはG。 どのセッションがどの会場になるかは参加希望人数によって決まるため、当日掲示します。会場がわからなかったら最寄りの実行委員をつかまえてね。 2016-03-01 08:15:58 テス太郎 @Tesutaro_JaSST そしてセッション番号はアルファベットと数字で示しています。 数字は時間帯を表しています。 2：1日目午後 13:10から90分 3：1日目午後 15:10から60
この記事の対象者 プロジェクトでテストを書いている。(書いたことある) テストが重要らしい事は知っているが、テストの恩恵をそこまで実感できていない。 結局手動テストに依存したバグフィックスをしている。 はじめに 私はテストの設計手法、実装に関する知識は多く持っていましたが、知らなかったことはテストの考え方でした。 テストが重要らしいことを知っている人は多いと思います。 しかし、実際に恩恵を実感できていない人もいると思います。 事実、 テストが重要だと発信している人 と、 テストが重要らしいことを知っている人がいます。 後者の人は、とりあえずテストを書く事ができます。しかし、テストに時間を割く割りに、最終的には手動テストでバグを発見することに依存している事も多いかなと感じます。 世間ではテスト書くのが当たり前、テストは重要！という風潮であるのに、何故テストが重要であると実感できないのでしょう
The 5th major version of the programmer-friendly testing framework for Java and the JVM User Guide Javadoc Code & Issues Q & A Support JUnit JUnit team’s statement on the war in Ukraine As human beings, we stand with Ukraine and condemn the Russian government’s war against the Ukrainian people, including our own colleagues and their families. Donate to UN’s Ukraine Humanitarian Fund About JUnit 5
徐々にテスト自動化していく場合のニーズ コンポーネントテストや統合テストなど開発者主体の自動テストの場合最初から自動テストのみを管理して、特に手動テストと管理をまとめたいというニーズはありません。 しかし、システムテストレベルの場合、全自動化がされていることは少なく、また現実的ではないので、現状手動のテストを徐々に自動化していくというのが良くあるパターンではないでしょうか？ そのような徐々に自動テスト化していく中では手動テストと自動テストを同時にリグレッションテストやスモークテストとして行ったりするので、両方をまとめて管理したい、まとめて状況を見たいというお話をマネージャーさんからリクエストされることが度々あります。 私にそんな話が来るぐらいと言うことは世の中でもそういうニーズがあるに違いない、そもそもHPのQuality CenterやIBMのRational Quality Manag
# yum install java ================================================================================================================================== Package Arch Version Repository Size ================================================================================================================================== Installing: java-1.8.0-openjdk x86_64 1:1.8.0.71-2.b15.el7_2 updates 217 k Install
技術部の taiki45 です。 現在のクックパッドでは、cookpad.com 内のデータを利用するようなプロダクトでも、cookpad.com を提供しているアプリケーション(本体アプリケーション)とは別に新規のアプリケーションとして設計・実装しています。また、すでに本体アプリケーションの一部として実装されているプロダクトについても、トレードオフを考慮しながら場合によっては、本体アプリケーションから独立した別のアプリケーションとして設計・実装することが増えてきています。これらの本体アプリケーションや、新規にあるいは本体アプリケーションから独立させて設計・実装したアプリケーションのことを「サービス」と呼んでいます。また、この本体アプリケーションから独立させることを「サービス分割」と呼んでいます。 制御できないほどの巨大な複雑なまとまりを制御するために、その巨大なまとまりと単純なまとまりに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
