テスト自動化研究会 - テスト自動化の8原則
1. 手動テストはなくならない 2. 手動でおこなって効果のないテストを自動化しても無駄である 3. 自動テストは書いたことしかテストしない 4. テスト自動化の効用はコスト削減だけではない 5. 自動テストシステムの開発は継続的におこなうものである 6. 自動化検討はプロジェクト初期から 7. 自動テストで新種のバグが見つかることは稀である 8. テスト結果分析という新たなタスクが生まれる これらの原則は、どのようなドメイン、プロセス、ツールの現場におけるテスト自動化であっても共通して言える、テスト自動化に取り組む前に留意しておくべきことがら＝原則を、テスト自動化研究会のメンバーによる議論のうえ、絞り込んだものです。これからテスト自動化に取り組まれる方、現在取り組まれている方、これから見直しをされたい方にご参考いただければ幸いです。 解説 1. 手動テストはなくならない ユーザビリティテ
Android/iOSアプリのテストの区分戦略 - クックパッド開発者ブログ
技術部の松尾(@Kazu_cocoa)です。 クックパッドのモバイルアプリ開発では、どのようなテストを書き、どのようなタイミングで、どのようなテストを実施するか？に関してエンジニア各位が意識を合わせるためにテストサイズを定義し運用してきました。ここでは、そんなテストサイズに関して簡単ですがまとめておこうと思います。 テストサイズとは ソフトウェアテストに関わったことがある方なら テストレベル という言葉には出会ったことがあるかと思います。JSTQBでは、このテストレベルは"管理していくテストの活動のグループ"と定義しています*1。 そうでない方も、俗に言う単体テスト/統合テストなど聞いたことがあるかと思いますが、その区分がここで示しているテストレベルとなります。 一方、このテストレベルはV字型と言われる開発工程と合わせて世の中で広く使われているため、社内における共通認識を構築するにあたり個
Android Studio で Unit Test - Qiita
alt + enterで、 Create Testメニューを実行すると、 このようなダイアログが表示されまして、 必要に応じて、setUp/tearDownにチェックを入れます。 またすでに実装されているメソッドの一覧が表示され、 チェックを入れると、自動的にtest用メソッドが追加されます。 OKを押し進めると、 Test用クラスが生成されます。 ##Test実行 メニューの Run → Edit Configurations.. から +ボタンを押し、 Android Tests を選択 初期状態は、 Module が no moduleになっているので、 所定のものを指定。(今回でしたら、app) Testを実行したい場合は、 ツールバーにて先ほど作成して、Android Testsを指定し、 実行。 ##結果 仮にSampleTestに以下のようなコードを書いた場合 public
Bash用ユニットテストフレームワーク作りました - Folioscope
Bash用テストフレームワークに、Batsやshunit2がありますが、イケてないなーと思ってたら、気づいたら自分で作ってました。 github.com テストの結果はモダンなテストフレームワークのように、カラフルに表示します。 またFAIL時は、FAILしたテストの結果を表示します。 自分の Arch Linux 上の Bash 4.3.42 および、Travis CI 上で動作することを確認しています。 インストール curl -o ~/bin/bashtub https://raw.githubusercontent.com/ueokande/bashtub/v0.1/bin/bashtub chmod +x ~/bin/bashtub です。ただし~/binはパスが通ってるとします。 これでターミナルから bashtub と打つことで実行できます。 bashtub テストを書く 各
Testing in Swift
About the content This content has been published here with the express permission of the author. Software tests are great for verifying software behavior and improving the quality of your code. In this talk, we learn from Jeff Hui about tooling, techniques, and writing tested code with the Quick testing framework. He also talked about generative testing, a prevalent functional programming approac
『ソフトウェアテスト技法ドリル』読んだ - ✘╹◡╹✘
ソフトウェアテスト技法ドリル―テスト設計の考え方と実際 作者: 秋山浩一出版社/メーカー: 日科技連出版社発売日: 2010/10メディア: 単行本購入: 7人 クリック: 153回この商品を含むブログ (19件) を見る 『知識ゼロから学ぶソフトウェアテスト』読んだ - ✘╹◡╹✘ を書いたところ、知り合いのテストエンジニアにこれオススメだよと勧めてもらい『ソフトウェアテスト技法ドリル』を読んだ。読みながら、どこでテストを書くのを満足すれば良いのか、このトレードオフはどんな条件下でどういう状態になるのか、テストについて常に信じられるものは何なのか、ということを考えていた。 なんでテスト書いてるのか まあ四年前の本なのでググればレビューも沢山出てくるしとりあえず本のことは置いといて、テスト書くときにいかに雑な仕事してるかという話でもしたい。日々コードを書いていると、たまに「なんでテスト書い
JSTQB認定テスト技術者資格
JSTQB（Japan Software Testing Qualifications Board）は、2006年5月にJTCB（Japan Testing Certification Board）から名称を変更いたしました。これからもよろしくお願い申し上げます。 自動車、携帯電話、社会インフラ、企業システムなど、我々の身の回りは、ソフトウェアで占められています。すなわち、我々の身体や財産の安全はソフトウェアに委ねられているのです。しかし昨今の状況を鑑みると、ソフトウェアの品質や信頼性、安全性が十分に確保されているとは言えません。ソフトウェアの品質や信頼性、安全性の確保は急務なのです。 そのための重要な技術として、ソフトウェアテストがあります。システムトラブルの報道でしばしば目にする「テスト不足」というキーワードは、テストの工数の不足を示唆しているだけではありません。業界全体で、テストの技
テスト自動化の3つの目的とROIの必要性、定義
テスト自動化の導入理由や効果測定をROIという観点で説明できるように、テスト自動化のROIの概念から実際の計算式までを解説する連載です。 連載目次 はじめに：本連載について 本連載を担当しますテスト自動化研究会（STAR）の太田健一郎と申します。本連載では、読者の皆さまがテスト自動化の導入理由や効果の測定をROI（return on investment、投資利益率、投資収益率、投資回収率）という観点で説明できるように、テスト自動化のROIの概念から実際の計算式までを数回にわたって解説させていただきます。 連載の流れは以下の通りです。 テスト自動化とROI ROIの試算式の構成要素と試算式 ROIの試算式の詳細と実際 本連載の対象読者は以下を想定しています。 テスト自動化を推進するエンジニア テスト自動化の定性的な効果は理解しているが、定量的な説明がうまくできないエンジニア 本連載で取り上
Android のテストで設計をイイカンジにしよう - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Android フレームワークは、あまり強力とはいえないものの、ある程度のテストフレームワークを内包しています。 ベースが JUnit3 なので、記法が古かったりすることもありますが、とりあえず JUnit3 の作法を身に付ければある程度のテストは書くことが出来ます。 Android のテストケースフレームワーク Android がもつ各種のコンポーネントをテストするためのフレームワークが有ります。 いろいろな種類がありますが、おそらく最も頻繁に使うのはAndroidTestCaseでしょう。 AndroidTestCase Andro
ユニットテストを書こう！ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ユニットテストを書こう！ ソフトウェアエンジニアにとって、ユニットテストは重要です。僕はなるべくユニットテストを書くようにしており、ソフトウェアエンジニアはもっとユニットテストを書くべきだ、と考えています。ここで言及している「ユニットテスト」は、単なる「テストコードによる自動化」全体を指すのではなく、「テストから見えてくるグーグルのソフトウェア開発」で登場した用語である「Sテスト」を指します。 「テストから見えてくるグーグルのソフトウェア開発」では、テストコードが対象とするプロダクションコード(製品コード)の規模、S、M、Lとサイズごと
iOSエンジニアといいかんじなテストの話 - laiso
Consumer Service Engineer MeetUp Vol.1 ~iOS編~ - dots. に行った。 最近あんまりザ・iOSアプリ開発らしいことしていなかったので情熱的な各社の話を聞けておもしろかったし、意識の高まりを取り戻せてよかった。 時間なかったので感想書く余裕ないかと思っていたんだけど、http://ainame.hateblo.jp/entry/2014/04/25/014605 の感想なんかを読んでたら触発された。 人力テスト 自動テスト vs 人力テストの構図というよりは、デベロッパーテスト、品質管理とユーザーテストやユーザビリティテストの違いで理解していた。 テストの目的と観点、誰が何をテストするのかという部分に注目するとスッキリすると思う。 講演した各企業の担当の人はユーザビリティテストに積極的だが、デベロッパーテストはうまくいってないという話を確かにし
AngularJSのテスト(Unit Test/end-to-end test)って何が良いの？ - Qiita
AngularJSを利用したのなら、絶対にKarmaとか Protractorを活用すべきです。ちゅうか、活用しなさい。と言いたいです。システムを保守フェーズに安定的にメンテナンスするならそう考えるのがふつうになるべき。 （※Protractorについては、こちらの記事がとても参考になります） 例によって「Mastering web application development with AngularJS」を読んで書かれていたポイントを読んだ感想をこちらにまとめてますが、 2章のテスト解説部分に下記の文章があります。 There is a quote saying that writing code without a Version Control system (VCS) is like skydiving without a parachute. Today one would
テストに開発を駆動させたい! | Sapporo RubyKaigi 2012 (札幌Ruby会議2012)
概要 本トークでは、私がRSpecやCucumberのテストを書く"気分"や"考えていること"を紹介し、 テストに開発を駆動させるときの雰囲気を感じてもらいたいと思っています。 いまや、Rubyを使ったシステム開発では、TDDはやるべきこととしてすっかり定着しました。 とはいえ実際にテストを書こうとすると、"どのようなテストを書くべきなのか"を悩み かえって手が止まってしまうこともあります。 TDDの効用はいろいろ紹介されていますが、本来の目的である「開発を駆動する」様子を 紹介したいと思います。 そのため、テストを書くときに考えていることや、書き順についてお話しします。 講演者 諸橋恭介 所属 (株)永和システムマネジメント (http://www.esm.co.jp) プロフィール Ruby/Rails Programmer. Love TDD/BDD. GitHub moro 発表言
iOSでの単体テストをとてもシンプルにできる！XCTestとOHHTTPStubsを使ってAFNetworkingの単体テストをやってみた - Qiita
概要 前回の続きで今回はOHHTTPStubsを使用して単体テストを行ってみました。 (テスト対象となるソースコードの概要は前回のコンテンツを参照してください) OHHTTPStubsはサーバサイドの処理を用意することなく、クライアントのみでHTTP通信のスタブを用意できるとても便利なライブラリです。 今回はTRVSMonitorというライブラリも一緒に使用しています。 XCTestは非同期処理を待たずにテストケースを終了してしまう場合があるのですが、それを防いでくれるのがTRVSMonitorです。 手順 OHHTTPStubsもCocoaPodsでインストールします。 @interface ASHTTPStubUtil : NSObject + (void)setupResponseWithFile:(NSString *)fileName statusCode:(int)status
Objective-Cで非同期処理のテストをシンプルに書く方法 | TOKOROM BLOG
非同期処理のテストってどう書いてますか？ 標準のXCTest自体がサポートしていれば良いのですがそうではないので、非同期処理のテストを書きたい場合には、その仕組みを自作するか出来合いのライブラリを利用する必要があります。現実的な選択肢としては、 GHUnitやKiwiなど非同期処理をサポートしたテストフレームワークを利用する GHunitの非同期処理のテストの仕組みを真似て抜粋したライブラリを利用する（意外とこれが多いかも？） expectaなどのマッチャーライブラリに付属の非同期処理の仕組みを使う となるかと思います。 ただ、私が調べた時点だとどれもしっくりきませんでした。 まず、GHUnitやKiwiなどを採択している場合には良いのですが、非同期処理のテストを書くという目的だけのためにそれらのフレームワークを使うというのは冗長すぎます。 また、GHUnitの非同期処理の仕組みだけを抜き
GitHub - power-assert-js/power-assert: Power Assert in JavaScript. Provides descriptive assertion messages through standard assert interface. No API is the best API.
What is power-assert? is an implementation of "Power Assert" concept in JavaScript. provides descriptive assertion messages through standard assert interface. No API is the best API. With power-assert, you don't need to learn many assertion library APIs (in most cases, all you need to remember is just an assert(any_expression) function) Stop memorizing tons of assertion APIs. Just create expressio
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
組織にテストを書く文化を根付かせる戦略と戦術
GitHub - joshaber/KIF: Keep It Functional - iOS Test Framework
casperjsのテストをUI操作で作成する。 - Qiita
Protractor: AngularJSの次世代E2Eテストフレームワーク - Qiita
