わたし的棚ぼた一万円選書 急に千葉さんに手渡された封筒、開けてみたら1万円札が1枚。何ごとかと思えば、同期の出張を代わったお礼をもらったらしい。 「葵はワンオペで育児してくれたから」と半分わけてくれました。 泡銭の1万円 これはもう、わたし的1万円選書をしろという思し召しなのでは……
![はてなブログ | 無料ブログを作成しよう](https://cdn-ak-scissors.b.st-hatena.com/image/square/06a15c64ba0ceec233d86d71001ebb29a9dcbf5d/height=288;version=1;width=512/https%3A%2F%2Fcdn.blog.st-hatena.com%2Fimages%2Ftheme%2Fog-image-1500.png)
わたし的棚ぼた一万円選書 急に千葉さんに手渡された封筒、開けてみたら1万円札が1枚。何ごとかと思えば、同期の出張を代わったお礼をもらったらしい。 「葵はワンオペで育児してくれたから」と半分わけてくれました。 泡銭の1万円 これはもう、わたし的1万円選書をしろという思し召しなのでは……
blog1.mammb.com では CoreMatchers についてでしたが、こちらでは org.hamcrest.Matchers についてまとめます。 org.hamcrest.Matchers JUnit についてくるのは org.hamcrest.CoreMatchers で基本的な Matcher が提供されています。org.hamcrest.Matchers は CoreMatchers を機能拡張したものとなってます。CoreMatchers にあるメソッドは、Matchers にもあります。 hamcrest-core − org.hamcrest.Matchers が入ってる hamcrest-library − org.hamcrest.Matchers が入ってる hamcrest-library は以下のようなパッケージ構成となっており、各用途に応じた Ma
自動改札機の運賃計算プログラムはいかにデバッグされているのか? 10の40乗という運賃パターンのテスト方法を開発者が解説(前編) ふだん何気なく使っている鉄道。改札を降りるときにICカードを自動改札にかざすと、「ピッ」という音と共に一瞬のうちに運賃を計算してくれます。けれど、複数の路線を乗り継いだり、途中で定期券区間が挟まっていたりと、想像しただけでもそこには膨大な組み合わせがあります。それでも運賃計算プログラムはわずか一瞬で正しい運賃計算が求められ、バグがあったら社会的な一大事にもつながりかねません。 爆発的な計算結果の組み合わせがあるはずの運賃計算プログラムは、どうやってデバッグされ、品質を維持しているのでしょうか? 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡
Grailsのテストについて,いくつかまとめておく。Grailsが標準で用意しているテスト環境は単体テスト(unit test)と結合テスト(integration test)の2つあって,それぞれこんな違いがある。 単体テスト(unit test) コンテナ外テストなので,幾つか制約事項あり。 たとえば,GORMのダイナミックメソッドは,モックで処理する。 結合テスト(integration test) コンテナ内テスト(正しくはJettyを起動しているワケではないみたい)。 GORMの制限はないし,データベースも使える。 ...ってな違いは実はどうでもよくて,どっちも「grails test-app」で実行するんだけど,これの使い勝手がすこぶる悪く,かつ遅い。そのためテストのリズムが良くない。せっかくテスト環境持ってたり,モック作れたり,TDDを行うには十分な条件を持っているのだけれど
Robot Frameworkは受け入れテストや受け入れテスト駆動開発(ATDD)に使えるテスティングフレームワーク。 http://code.google.com/p/robotframework/で開発が進められている。 プレインテキストやHTML形式でテストケースを記述できること、pythonまたはjavaによってテストライブラリを作って拡張できることが特徴だ。 ここではRobot FrameworkとSelenium2(WebDriver)を組み合わせて、受け入れテストを自動化する方法について説明する。 WebDriverを単独で使ってWebアプリケーションのエンドツーエンドテストを作る場合、どうしても画面ができてからしかテストケースが作れないというのが大きな問題だ。そのため例えばPHPであればBeHatと組み合わせしたりするのだが、今回の方法は更に簡単だ。 例えば、アジャイルな開
入社2年目QAエンジニアのkuramochiです。 今回は、私が今勉強していることについて書きたいと思います。 また、その主な内容としてJSTQB(Japan Software Testing Qualification Board)のFoundationLevel試験(http://www.jstqb.jp/)の内容をもとに進めたいと思います。 内容は、以下の内容です。 (参考書は、JSTQBのHPで公開されているシラバスですが、偶然、弊社技術部の本棚で見つけた“JSTQB(FoundationLevel試験)教科書”です) [1]:テストの基礎 [2]:ソフトウェアライフサイクルを通じてのテスト [3]:静的技法 [4]:テスト設計技法 [5]:テストマネジメント [6]:テスト支援ツール この中から、いくつかの内容を抜粋して紹介していきたいと思います。 [1]テストの基礎 (1)テス
瀬良 @shela_ @irof publicからprivateを含めて検証するのと、private単体だけで検証するのであれば、先にprivate単体で検証しておいた方が安心感があると思う 2012-08-25 16:38:24
こんにちは、エンジニアの岡崎(@watermint)です。今回はGREEにおけるJenkinsをつかった品質管理について紹介します。 hourlyビルド 岡崎がGREEに入社したのは1年半前ですが、そのときから感じているのがGREEの開発速度は非常に速いことです。ソースコードレポジトリには多くの優秀なエンジニアが日々数百以上のコミットしています。 GREEのシステムは多くのサブシステムを組み合わせたものですが、手元の些細な変更が全く予想しない別のプロジェクトで問題を起こすことがあります。こういった問題は通常、リリース前の結合テスト等の段階で検出します。 リリース前のテストで問題が発覚すると、当然その修正をして再度修正をリリースプロセスにのせるということになるのですが、これには他のエンジニアの作業を止めてしまったりリリースの順序を調整が必要になることがあります。 こういった事態を防ぐために単
リッチなユーザインターフェースを備えたWebアプリケーションでは、Ajaxやアニメーションなどの非同期処理はよく用いられます。こういったWebアプリケーションをSeleniumでテストする際、従来の静的なユーザインターフェースを持つWebアプリケーションと同じようにテストを作成していると、実際にテストを動かした時に次のような問題が発生することがあります。 存在するはずの要素が見つからない(あるいはその逆) 画面全体、もしくは特定の要素の内容が更新されていない 例えば、以下のようなソースコードです。 ajaxButton.click(); WebElement fooElement = driver.findElement(By.id("foo")); 非同期処理を伴うボタンをクリックした後にfooというIDを持つ要素を探していますが、この要素が非同期処理の完了後に表示される要素であった場合
EasyMockとの違い Eclipse での利用に際して org.mockito.Mockito モックの利用と妥当性検証 スタブメソッドの定義 引数の照合 メソッド呼び出しの妥当性検証 voidメソッドから例外を返却 API的に EasyMock と大きな違いはありませんが、使用感としては格段に心地良い Mockito。 [:W150] 本家 http://mockito.org/ のドキュメント(というかJavaDoc)をベースにメモ。 EasyMockとの違い Mockito では record モードと replay モードを切り替える必要がない Mockito で作成するモックは常に、EasyMock で言う NiceMock となる スタブメソッドの妥当性検証が常にオプション扱い 大きくは以上となります。具体的に、EasyMock では import static org.e
This document contains links and snippets of text on various Agile topics including Scrum, continuous delivery, iterative development, inspection and adaptation. It discusses priorities of satisfying customers through early and frequent delivery of valuable software. It also includes questions about release cycles and mentions that organizations tend to design systems that mirror their own communi
テストケースくらいはなるべく特定のフレームワークに依存させたくないという気持ちはあるものの、さすがに Hibernateやらといったヘヴィな奴をインスタンス化する長い道のりを手でコーディングしたり、単一責任の原則に基づいて真面目に分割されたコンポーネント群のワイヤリングを手でコーディングしたりするのはかなり厳しいものがあるので、そこは目をつぶってテストケースもやはり Springの助けを借りて実装するのが現実的だ。 なお JUnitと Springを連携させるには、spring.jarの他に spring-test.jar が必要となる。 Eclipseについてる JUnitを捨てる Eclipseについている JUnitはちょっと古くて、Springに対応するために必要なインターフェイスJUnit4ClassRunnerが存在していない。なので Eclipseに標準で付属している JUn
ここ数日 ruby をやってるんですけど、ruby といえばテストらしいので Test::Unit やら RSpec やらを調べてました。しかし僕はこれまでまともな TDD をやってこなかったので、先にテストとは何ぞや?TDD とは何ぞや?ってのを調べたりしていました。 この記事は、ずぶの TDD 素人がテストについて知り始めたまとめです。 1. きっかけは RSpec のドキュメント そもそも RSpec の↓紹介文の冒頭から意味不明に感じたんです。 FAQ:「RSpec って、要は Test::Unit でやっていることを別の書き方にしただけでは?」 この FAQ への短い答えはイエスです。 『スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)』 Rubyist Magazine えっ... じゃあ要らんやろソレ。いちいち手作業でチェック
要求に対する妥当性確認のような、ブラックボックスでテスト設計を行うテストでも、製品のコードや開発のコミットログは大変重要な情報になります。 理由はいくつかありますが、例えばコミットログからは以下のような情報が得られます。 単純に、コミットログ確認による変更レビューでバグを見つけられることがある。事前レビューでのバグ検出は、実際にテストを始めてバグを見つけた時より手戻り工数を削減できることが多い。またテストすべき危ない変更もレビューで検出できる。 変更の影響範囲の予測材料になる。例えば割り込み関数の変更を見つけることで割り込み発生時のタイミングの変化を予測する、といったことが可能になる。一般的に、タイミング・非同期処理・並行処理・ハードウェア起因といった、ごく稀な条件に依存するバグについては、テスト全体の網羅性を底上げするだけでは検出が難しい。そこではある程度怪しい箇所を絞り込んで探索的テス
2011年ももう終わりなのでふりかえりというかまとめをしておく。 ちなみに昨年のKPTをみたら、だいたい達成してましたね。 1月 ジェフサザーランドさんの認定スクラムプロダクトオーナーの裏方をしつつ認定スクラムプロダクトオーナーを取得。 前年のコプリエンさんのCSMのお手伝い以降、事務の人として認識される。 認定スクラムプロフェショナルの申請書を提出した DevLove TestDayに登壇してテストについて話した。ディスカッションの際に@ShiroKappaさんと@t_wadaさんと同じテーブルになって色々話す。その5ヶ月後くらいから仕事をご一緒させて頂くようになる。縁ってすごい。 2月 認定スクラムプロフェッショナルになった。当時日本人3人目。 デブサミで「チケット管理システム大決戦 JIRA vs Redmine vs Trac 〜ユーザーが語る、なぜ私はこのツールを使うのか」に登壇
これは、「Software Test & Quality Advent Calendar 2011」の12/15分のエントリーです。ソフトウェアテストや品質に関するAdvent Calendarという事で、前のエントリーは@kz_suzukiさんの「それでもやはり、品質を「予測」したい」になります。 Developer Test と Customer Test Developer Test と Customer Test とは、和田さんの講演の中で出てくる誰が何のためにテストを行うのかという観点で分類したテストの2つです。書籍「実践アジャイルテスト」の中でもテストの4象限モデルとして、ビジネス面/技術面の軸とチームの支援/製品を批評の軸によるテストの分類が紹介されていますが、ほぼ同じものと考えて良いでしょう。 Developer Testとは、開発者が開発者の為に、開発を行いやすくするため
Android SDKでビジネスロジックのテストを自動化するには:Androidアプリ開発テスト入門(2)(1/3 ページ) ビジネスロジックのテスト自動化から始めよう 本連載ではAndroidアプリを開発している方のためにテストの基本的なノウハウを解説しています。前回の「Androidアプリ開発でテストを始めるための基礎知識」では、Androidアプリ開発におけるテストの課題を解説し、EclipseとJUnitを使った単体テストのやり方を環境構築やコードの書き方を含め紹介しました。今回は「ビジネスロジック」のテストについて説明していきます。一口にビジネスロジックといっても読者の皆さんが持つ定義は、さまざまかと思います。 Android開発におけるビジネスロジックとは 本連載ではビジネスロジックを「Androidのシステムに依存しない独立した処理」と定義します。具体的には文字列処理や日付・
鈴木三紀夫 @mkoszk @kyon_mm TEFへの返信の前にツイートで。要求工学の基礎では要求のスコープというのが定義されています。ビジネス要求、システム要求、ソフトウェア要求がそれに当たります。これを僕は社内研修でずっと「要求のレベル」と読んでいたんです。テストレベルとの対比で言っていたんですね。 2012-01-03 02:31:09 鈴木三紀夫 @mkoszk @kyon_mm 対比すると、受け入れテスト、システムテスト、単体/統合テストになるからです。でもね。それは要求のレベルじゃなくて、要求のスコープだと指摘されて、最初は何を言っているのか分からなかったんだな。だけど時間が経つにつれて分かる部分が増えてきたんだ。 2012-01-03 02:33:33
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く