WACATE 2011 夏に申し込んだので、おさらいしましょう。ということでテスト手法、テスト技法を中心としたリンクをまとめてみました。 なので今回はTDDとかテストツールとかはあまり含まれていません。 いくつかかぶっているものもありますが、多面的な表現って大切だと思うので、多少のかぶりは気にせずに選択しました。 これを読めば良いソフトウェアエンジニアとして一歩階段を上れる気がしています。 他にも参考になるものがあったら、コメントやTwitterで@kyon_mmまで教えてくださるととっても嬉しいです! 次の形式で書いています。 WEBサイト名、資料名:発表者(敬称略):URL カテゴリー分けしたんですが、不適切であるかもしれません。間違い等あればご指摘ください。 また、ここでのリンクに問題がある場合は削除致しますので、その場合もご指摘ください。 TwitterID:kyon_mm mai
_ テストコードを作らない文化が浸透している現場へRuby/Railsが導入された結果への対策を考えてみる まず、導入された結果は以下のようになっております。信じられないものもありますが、事実です。 1. マージが頻繁に行われる開発中はNoMethodErrorや文法エラーが続出。必要なコードのマージ漏れまで発生 2. 修正の度に人力テストが必要となり、コスト増大 3. これまで以上に責任論が追求される現場となる 4. コスト増加を恐れるあまりリファクタリングはおろか、巨大な迂回処理やコピペが横行する 本プロジェクトには、以下のようなテストコードを作(らない|れない)様々な原因があります。 問題分類 現場への影響
グーグルが行っているビルドとテストの種類。続々、グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか? グーグルでTest Engineering Directorを務めるJames A Whittaker氏が、ブログ「Google Testing Blog」に書いているグーグル社内のソフトウェア品質に関するノウハウ。最近の記事「How Google Tests Software - Part Four」「How Google Tests Software - Part Five」では、ビルドの種類とテストの種類について紹介しています。 One of the key ways Google achieves good results with fewer testers than many companies is that we rarely attempt to sh
開発とテストの融合こそゴール。続、グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか? グーグルでTest Engineering Directorを務めるJames A Whittaker氏が書いたエントリを紹介した先日の記事「グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか?」が非常に好評で、「続きがあれば読みたい」というコメントをいただいていました。 Whittaker氏がそのエントリの続き「How Google Tests Software - Part Threeを公開していますので、ご要望に応えて紹介することにしましょう。 品質は開発の問題であってテストの問題ではない 品質とはどのように実現するものなのか? という問いに対して、Whittaker氏は次のように書いています。 The simple solution to this con
グーグルは検索エンジンだけではなく、メールソフトのGmail、オフィス系ソフトのGoogle Apps、WebブラウザのChromeやOSのAndroidなど、さまざまな種類と規模のソフトウェアを開発しています。 それらはどのようにテストされ品質管理されているのでしょうか? グーグルのブログGoogle Testing Blogに、Test Engineering DirectorのJames A Whittaker氏による「How Google Tests Software」がポストされ、その概要を伝えています。 3つのチームからなるEngineering Productivity Whittaker氏はまず、グーグルにはテストの専門部隊はいないのだ、という組織構造の説明から始めます。 There isn't an actual testing organization at Googl
IE6, IE7, IE8などIEの異なるバージョンをテストするアプリケーション・環境のまとめとそれぞれの特徴を紹介します。 Internet Explorer 7のキャプチャ [ad#ad-2] 「Sandboxed IE Browsers from Spoon」から各アプリケーション・環境のまとめと特徴をピックアップし、いくつか追加しました。 IETester Virtual PC IE Super Preview IE Collection マルチPC環境 IETester IETester 対応するIEのバージョン IE5.5 IE6 IE7 IE8 IE9preview 主な特徴 異なるIEのバージョンをタブで同時に表示することが可能なアプリケーションです。 プリントプレビューのテスト、ポップアップによるインタラクション以外のテストは万事良好に動作します。FlashとCSSのフィ
Java Programming Language Googleの20%プロジェクトからJava向けの新しい技術「cofoja (Contracts for Java)」が公開された。既存の実装に大きく手を加えることなく、デバッグをより簡単にしてくれる効果が期待できる。バグは些細なコードが起こすものだったりするが、それを追跡して発見するのは時に困難を極める。これは問題が発生した箇所と、実際にバグがある箇所が大きく離れていることが理由になっていることもある。問題発生箇所とバグ発生箇所を近くにまとめることができれば、それだけバグ発見も取り組みやすくなる。 cofojaはこれを簡単に実現するための技術。インタフェースに制約表現を追加可能にするところがポイントとなっており、クラスの実装に手を加えなくてもインタフェースに制約表記を追加することで実行時にチェックできるようになる。ブログに掲載されている
*はbiac氏のご指摘により「TDD採用により増加した工数」から修正した。 欠陥密度はリリースが近いフェーズでのテストで検出された欠陥にもとづいているそうだ。 また、次のような知見が紹介されている。 途中でTDDをやめたり、途中からTDDをはじめてもうまくいかない。プロジェクトの開始時からやるべき(既存のソフトウェアの次バージョンから始める場合には言及がない) テストコードの実行速度に気を配り、速く実行できるようにする。それぞれのテストコードの実行は短くても結合すると膨大な時間になってしまう場合がある。 テストケース数、テストコードの行数、コードの行数、カバレッジ、発見されたバグと修正されたバグの数、を計測し、傾向を把握する。 開発開始、終了時には開発者の意向に耳を傾ける場を作る。今後も継続してTDDしたいかどうか。 どのプロジェクトもTDDを採用されなかったと想定した場合と比較して、工数
システム開発において「品質の向上」という標語がしばしば掲げられますが、 「品質の属性」については無頓着なケースが多いのではないでしょうか。 ひとくちに品質といっても多様な属性があります。 顧客と品質の話で揉めたことはありませんか? 品質には多様な属性があり、単一の軸で良しあしを決められないという側面があります。 そのため、単に「品質」と言ってしまうと認識に齟齬が生じるのです。 Karl E. Wiegers氏が著書 「ソフトウェア要求」 で挙げた、すべてのプロジェクトが検討すべき12の属性は以下のとおりです。 可用性availability 動作可能時間の指標。システム故障までの平均時間MTTF(Mean Time To Failure)を 平均修復時間MTTR(Mean Time To Repair)とMTTFの合計で割った値。稼働率とも呼ばれる。 効率性efficiency 同じ処理性
「ビジネス上のコミュニケーションを、メールの不便さから解放したい」という思いから2009年にサイボウズがスタートした無料コラボレーションツール「サイボウズLive」。その開発現場は、Webアプリケーション開発の流行をうまく取り入れたアジャイルなものでした。その様子を、はてなチーフエンジニアの大西康裕がインタビューしました。テーマは、プログラミング言語の選び方から、自動ビルドと自動テスト、リファクタリング、チーム内コミュニケーションなど。大西自身も「面白かった」と語る取材の様子をぜひお楽しみください。記事の最後ではプレゼントもご案内しています。ところでこの取材には、サイボウズ・ラボの竹迫良範氏が、なぜか大量のレッドブルを抱えて登場したのですが……。 http://live.cybozu.co.jp/ (※この記事はサイボウズ株式会社提供によるPR記事です。) 大西 はてなチーフエンジニアの大
テストについて考える 1. テストにつ いて考える 2010/11/30 Ryutaro “Ryuzee” YOSHIBA http://www.flickr.com/photos/nicolas-hoizey/2693162677/ 2. 自己紹介 Ryuzee @ryuzee http://www.ryuzee.com/ http://www.flickr.com/photos/adforce1/2539903964/ 3. アジャイルコーチ 認定スクラムマスター オープンソース開発者、翻訳者 Shibuya.tracのスタッフ TIS,野村総合研究所を経てベンチャーのCTO http://www.flickr.com/photos/royskeane/413103429/ 4. 今日の話のコンテキスト • ゕジャルな立場から話をします • がウォーターフォールでも適用可能 です.(
単体テストを“神速”化するQuick JUnitとMockito:ユカイ、ツーカイ、カイハツ環境!(16) Quick JUnitプラグインの3つの大きな特徴 近年、JUnitとHudsonを利用した継続的インテグレーション(CI)によるテストの自動化や、テスト駆動開発(TDD)の普及などにより、ユニットテスト(単体テスト)のテストコードの作成が重要視されています。 今回紹介する「Quick JUnit」プラグインは、JUnitによるテストコードの作成と実装を支援するEclipseプラグインです。Quick JUnitプラグインは石井勝さんにより開発されていましたが、石井さんが不慮の事故により死去後、Quick JUnitプラグインプロジェクトにより開発が継続されています。優れたオープンソースプロジェクトの模範のようなプロジェクトです。 訂正のお知らせ 故人のお名前について間違いがあり、修
卒業研究にご協力のお願い 現在、卒業研究でテスト駆動開発(以下TDD)の初心者と経験者(上級者)のプロセスについて研究しています。 しかしながら、私のまわりにはTDD経験者・上級者がほとんどおらず、データを集めるのが困難です。 そこで、TDDに自信がある方にはデータ収集にご協力いただければ幸いです。 内容など JUnitLogGetを導入した状態で、4つの課題についてTDDで作成してください。課題に関しては後述します。 「課題」と記述している理由は、これらのプログラムが佐賀大学理工学部知能情報システム学科3年次実験科目「システム開発実験」の演習課題の一部だからです。 課題はすべて30分~1時間以内で作りあがる程度のプログラムです。 JUnitのバージョンはどちらでも構いませんが、できればJUnit 3でお願いします。 作成が完了したら、JUnitLogGetによって出力された
テストの基本的な知識は、あまねくITエンジニアが持つべきだ。しかし実際には、本当に基本的な知識でさえ浸透していないのが現状である。そこでこの記事では、ITエンジニアが最低限知っておくべきテストの基本知識と、その活用方法を解説する。 社会的なインフラとして構築された大規模システムで,大きな障害が多発している。こうした問題を防ぐためにも,高品質なシステムを開発する必要性がますます高まっていることは言うまでもないだろう。 システムの品質を向上させるためには,しっかりと設計を行い,それに基づいて正しく実装する必要があるのはもちろんだが,最終的にはシステムを動作させてテストするしかない。 テストで品質を検証するためには,周到なテスト計画やソフトウエアの特性に合わせたテスト設計,効率的なテスト管理が必須となる。そのためには,品質管理の担当者だけではなく,プロジェクト・マネジャーやリーダー,SEにも,テ
フリーウェア [ScreenSaver] - 星雲紀行 - MLXS [Tools] - WPGen 曲 - 自作音楽 紹介等 - 自己紹介 - 寄付受付 - 音楽募集 - リンク集 - 注意・免責事項 - ライセンス - 著作権 グラフィックス - ジオメトリ - モデル - OFLライブラリ - モデリング - テクスチャ - テクスチャマッピング - 画像形式 Tech - memo 音楽 - 音楽 - DTM プログラミング [c] -- 最適化 - ライブラリ - DirectX - OpenGL -- 座標系 -- 行列演算 -- ツール - ODE - Windows [作法/スタイル] - 仕様書 - 作法 - Doxygen - Graphviz - UI - テスト - メンテナンス - Design Pattern [スクリプト] - ShellScript -- 文
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く