ウノウラボ Unoh Labs: バグの状態でプロジェクトの状態を知る
こんにちは！やまもと＠テスト番長です。 以前バグのステータスというのを書いたのですが、その最後の方で続きがあるようなことを申したら、気になるから教えろという奇特な方がいらっしゃいましたので今回は続きを書いてみましょう。 BTSはバグを管理するだけの道具ではありません。バグを追いながら適切に記録をつけて統計を取ることで、プロジェクトやチームの状態を知ることが出来ます。例えば、以下のような事象です。（なお、WEBアプリが前提） ・バグの報告数が増えず、結果がVERIFIEDになることが多い。 →まだデバッグが始まったばかりのプロダクトか、慎重過ぎるテスターがアサインされています。 ・バグの報告数が少なくなり、VERIFIED以外の結果が目立つ。 →デバッグは最終段階を迎えています。もしもまだ納期前ならば、それなりに上手く行ったプロジェクトでしょう。 ・NEWが発生してからRESOLVEDに
例外を思いのままに発生できる「DevPartner Fault Simulator」レビュー（1/4） - ＠IT
.NET Tools 例外を思いのままに発生できる 「DevPartner Fault Simulator」レビュー ―― 面倒な異常ケース／例外処理のテストを強力サポート ―― 株式会社ピーデー 川俣 晶 2006/06/10 プログラミングで厄介なもの、それは異常ケース 筆者が.NET Frameworkベースで（主にC#による）プログラムを書き始めてから遭遇した思い出深いトラブルは2つある。 その1つは、外部からの通信を処理する機能で発生した問題だった。通信を受け付けると、その通信を処理するスレッドを走らせる仕様だったのだが、どういうわけかスレッドの数が異常に増え、スレッド数の上限に達してそれ以上のリクエストを受け入れられない状態に陥ることがあったのだ。しかし、開発用の環境で問題を再現することができなかった。外部に公開された実運用サーバでのみ発生したのだ。 そこで、.NET Fram
【中級】無駄なく確実にテストする I 単体テスト
図5●静的解析の効果は高い<BR>静的解析とは，プログラムを実行せずにソースコードの内容をチェックする作業。バグを生みやすいコーディングはしていないか，可読性や保守性が下がるコーディングはしていないか，などの観点から解析する。コーディング終了時にレビューとして実施することも多い。レビュアのスキルが高ければ，メモリー・リークやマルチ・スレッドのバグも発見できるなど，より効果が高まる テストの最初に位置する「単体テスト」（モジュール・テスト，ユニット・テスト）は，すべてのシステムで実施されるべき基本的なテストである。実装された関数やメソッド（以下，プログラム）の内部構造のバグを取る。通常，コンパイルした直後に実施され，デバッガなどを用いるケースもあるため，プログラマ自身が実施することも多い＊2。後工程になるほどバグの修復コストが高くなることを肝に銘じて取り組みたい。単体テストで実施するテストに
テストを金額にするといくら？ ― ＠IT
テスト駆動開発（Test Driven Development：TDD）。最近この言葉を聞く機会が多いと思いますが、実際のプロジェクトでTDDを取り入れているというケースはあまり聞きません。本稿は、テスト駆動開発に興味はあるけれど、いまだ導入に踏み切れないという開発者のために、その効用や実際の運用方法について、具体例を交えながら述べたいと思います。前半はテスト駆動開発の意義と、導入に当たっての説得材料について検討します。後半では実際にテスト駆動開発を進めるに当たって具体的にやるべきことについて、事例を踏まえながら説明していきます。 テスト駆動開発（TDD）とは テスト駆動開発は一般にエクストリーム・プログラミング（XP）の1プラクティスとして紹介されることが多いと思います。しかし、テスト駆動開発自体は決してXPの開発手法に特化したものではなく、さまざまな開発手法とともに有効利用が可能なもの
[ThinkIT] 第4回：自動ビルドによるプログラムの品質・保守の有効性 (1/4)
ソフトウェアにおいてバグはつきものです。1人のプログラマが一度に書けるバグのないコードは最大で数十ステップといわれています。当然、業務システムは数万から数十万ステップにもなるわけですから、バグは存在していて当然です。 そしてバグは、できるだけ早く見つけるに越したことはありません。早期に発見できたバグは、問題の追及が比較的楽になるからです。逆にかなり前から潜んでいたバグは、考慮すべきソースコードの範囲が広くなるために問題の追及が困難になってしまいます。 そこでXP（eXtreme Programming）などのアジャイル開発プロセスでは、常時結合（Continuous integration）というプラクティスが提唱されています。 これは、「最新のソースコードを常に自動テストし、常に動作するソースコードを入手できる状態にしておく」ことです。これにより開発の早い段階からバグを発見することができ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://homepage2.nifty.com/software/vbunit/index.html
javaworld.jp
BDDIntro - 生きてま2 改 - Trac - A NEW LOOK AT TEST-DRIVEN DEVELOPMENT
オブジェクト倶楽部 - TOPページ