Jenkins, Seleniumを使った自動テストの課題とこれからの取り組み
Uncategories Jenkins, Seleniumを使った自動テストの課題とこれからの取り組み こんにちは。QAの井上です。 今回は現在QAチームで行っている自動テストに関する課題、それに対する取り組みについて紹介します。 まだまだ詰めが甘いところがあると思うで、フィードバックいただけるとうれしいです。 早速ですが、QAチームではCIツールにJenkinsを使用していて、約8割がSeleniumによるテストケースでできています。 テストケースの作成から実行まではざっくりですが、以下のようになっています。 - テストケースはFirefoxのIDEを使用して作成 - 作成したテストケースはSVNに保存 - 毎日夜中に最新のソースコードに対してテストを実施 - テストの実施は、Jenkinsのseleniumhqプラグインを使用して、複数台のクライアント(Windows)上でSelen
PHPカンファレンス2011 で"PHPとテストとCIと私〜愛するあなたのため〜"というタイトルで発表してきました - Yamashiro0217の日記
PHPカンファレンス2011 で"PHPとテストとCIと私〜愛するあなたのため〜"というタイトルで発表してきました。 当日は、ほとんど寝ず、午前中は #nekkonという結婚式に参加してからの発表だったから辛かった。実質寝てねーからつれー。発表つれー。 内容としては架空の某システムの裏方に入った、 架空の人が、いかにレガシーコードと戦い、TDDやCIを適用していったか、 また、適用するにあたりどういう便利なツールを使ったか、 また、チームにそれらの文化を浸透させるためにどうしたか。 などといった内容となっています。 以下がプレゼンのスライドを Slideshareに上げたやつです。あとUSTの録画もありました。 http://www.ustream.tv/recorded/17177077 PHPカンファレンス2011 PHPとテストとCIと私〜愛するあなたのため〜View more pr
新人 テスター が思ったテスターの心得（チラシの裏）① - SEブログ
現在テスターをやっています。今の案件にはいって二ヶ月半。新人が思った持論です。 ■ スピードスピードそうだスピードだ テストだけではなく設計や開発全てにおいて、この業界はスピードをとても重視していると思う。それもただ早くやるではなく、質が良くてかつスピーディということ。つまり質だけではだめ、スピードだけではだめ、両方できないとだめなのである。だめというのは語弊があるが。求められている能力なのは間違いない。 ■ 風のテスター 某有名なエンジニアさんのブログで、わたしは風のプログラマーを施行していると書いてあったが。風のテスターなんていうのがあっても面白い笑 今回はテストのお話でした。テスターもスピードに差があります。それゆえとても大事なファクター。ではどうやってスピードを上げるかというと、ぱっぱと適当にやれというのではありません。実質、テスト実行と結果の確認にはベテラン新人とも大きな差はない
コードやテストを保存したら自動でPHPUnitを実行しGrowlへ通知する環境 | Act as Professional
TDDやってますか？テストを書いて、実行。コードを書いて、テストを実行。PHPUnitコマンドを1日に何度も叩いているPHPerに朗報です。コードとテストを修正して保存をすると、それを検知して、自動的にPHPUnitを走らせて、結果をGrowlで通知する環境をつくりました。これで、TDD Boot Camp in Tokyo #tddbcもテンポ良くすすめられますね。 gem watchr インストールPHPerには申し訳ないのですが、Rubyのgemを使います。 gem install watchr growlnotify インストールGrowlへの通知をするgrowlnotifyをインストールします。 Growlをダウンロードして、Extraディレクトリに含まれている、growlnotifyをインストールしてください。 環境をcloneする hirocaster/phpunit-sta
なぜUnitTestは理解されない？
TwitterでこんなTweetが流れた… エビデンスとしてNUnitのGUIのスクリーンショットと、対応するテストコードが含まれている部分のVSのスクリーンショットを取る作業が終りません・・・ UnitTestのエビデンスって…なに？ 一般的にテストのエビデンスというと、次の2点を指す。 テスト手順を明らかにするもの（ex. テスト設計書、テスト仕様書、...） テスト結果の証拠（ex. 画面ハードコピー、DBスナップショット、...） UnitTestでは、これはこのように解釈できる。 テスト手順を明らかにするもの ＝ テストコード テスト結果の証拠 ＝ 今実行すればテストが全てグリーンになること これがなぜか理解されず、軋轢とストレスと大きな工数追加になっている現場がずいぶんある。 なぜUnitTestはいつまでも理解されないのだろう。 余談。これらのことは、Seleniumなどを使
知るだけで天地の差が出る、テスト仕様書の必須項目＆表現方法
テスト仕様書で絶対に必要な項目リスト テスト仕様書に記述すべきものとして、以下の事項があります。 テストを実施した環境 実施するテストの内容 テストを実施するためのシステムの操作手順 テストの実行結果 個々のテスト項目を識別するための番号や記号（通し番号など） テストを実施した年月日 テストを実行した担当者 障害報告票番号（発生した障害の詳細を開発グループに報告する帳票の識別番号） まずはテスト環境について明記する テスト仕様書の先頭には、「テストを実施した環境」を記述します。ここでは、ハードウェア環境やソフトウェア環境、ネットワーク環境など、「どのような環境でテストを行ったか」を説明します。 ただし、テストを実施した環境を記述するだけでは十分ではありません。「顧客にとって必要な情報は何か」を考えるのです。ここで必要なのは、「要件定義書で規定した環境」との関係が分かることです。 なぜなら、
単体テストを“神速”化するQuick JUnitとMockito
単体テストを“神速”化するQuick JUnitとMockito：ユカイ、ツーカイ、カイハツ環境！（16） Quick JUnitプラグインの3つの大きな特徴 近年、JUnitとHudsonを利用した継続的インテグレーション（CI）によるテストの自動化や、テスト駆動開発（TDD）の普及などにより、ユニットテスト（単体テスト）のテストコードの作成が重要視されています。 今回紹介する「Quick JUnit」プラグインは、JUnitによるテストコードの作成と実装を支援するEclipseプラグインです。Quick JUnitプラグインは石井勝さんにより開発されていましたが、石井さんが不慮の事故により死去後、Quick JUnitプラグインプロジェクトにより開発が継続されています。優れたオープンソースプロジェクトの模範のようなプロジェクトです。 訂正のお知らせ 故人のお名前について間違いがあり、修
「バグ数には興味ないのだよ」――顧客が喜ぶテスト仕様書とは？
「バグ数には興味ないのだよ」――顧客が喜ぶテスト仕様書とは？：誰にでも分かるSEのための文章術（11）（1/2 ページ） 「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 メーカーが機械を納入する際は、耐久試験や性能試験などの結果を添付して、問題がないことを顧客に確認してもらいます。同様にシステム開発においても、テスト結果を顧客に提示してシステムに問題がないことを確認してもらう必要があります。 今回と次回の2回にわたって、「テスト仕様書」の書き方と表現のポイントを説明します。 今回は、「顧客にとって良いテスト仕様書」とは何か、「顧客にとって良いテスト仕様書」にするためには何を記述すればよいのか、テスト仕様書のおおまかな
世の中のソフトウェアテストは“間違いだらけ”!?
世の中のソフトウェアテストは“間違いだらけ”!?：情報マネージャとSEのための「今週の1冊」（2） ソフトウェアテストにはあらゆる“誤解”が渦巻いている!? テストに何らかの課題を抱えている場合、テスト計画やツールなどを疑うよりも、あらためてテストの本質と基本を見直すことが、解決への1番の近道になるのかもしれない。 ビジネスや社会にITが深く浸透している近年、ソフトウェアの品質に対する要求は年々高まっている。その品質に問題があれば、機会損失や信頼性低下、ひいては多くの人を巻き込む社会問題にも発展しかねないためだ。これに伴い、ソフトウェアテスト（以下、テスト）も品質担保のカギを握る重要なプロセスと認識されているが、その一方でテストに対する理解不足から効率的に実施されていなかったり、納期やコストの問題に押されて「出荷の妨げ」などととらえられているケースも少なくない。 そうした「ソフトウェアテス
テストファーストでユーザーも開発者も幸せに
いかに生産性を上げつつ、高品質なソフトウェアを開発するか。この究極の課題に応えるのが、「テストファースト」だ。「＠IT ITアーキテクト塾」第2回では、テストファーストの概要、メリットおよびその実践について、会場と講演者を交えてディスカッションを展開した 通常のテストと「テストファースト」の違い セミナーの第1部は、アークウェイの黒石氏による講演「テストファーストの実践」。黒石氏はマイクロソフトのコンサルティング本部を経て、現在は.NETを中心とするコンサルタントとして活躍している。マイクロソフトに所属していたとき、顧客企業が先行して実践していた「テストファースト」に衝撃を受け、これがコンサルタントとして独立する契機になったそうだ。 では、そのテストファーストとはいかなる手法なのか。黒石氏は冒頭で「一般的なテストとは、システムに何らかを入力し、バグを見つけ出すこと」と説明し、「こうした一般
テストを書くこととテストをすることの違い - 未来のいつか/hyoshiokの日記
会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、１０回くらいで完走したことになる。 一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。 テストがないコードはレガシーコードだ！というキャッチフレーズはわたしの心をとらえた。 参加者の皆さんとその価値観を共有できた事はうれしい。 現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://designaholic.cc/2011/08/15-1.html