なぜUnitTestは理解されない？
TwitterでこんなTweetが流れた… エビデンスとしてNUnitのGUIのスクリーンショットと、対応するテストコードが含まれている部分のVSのスクリーンショットを取る作業が終りません・・・ UnitTestのエビデンスって…なに？ 一般的にテストのエビデンスというと、次の2点を指す。 テスト手順を明らかにするもの（ex. テスト設計書、テスト仕様書、...） テスト結果の証拠（ex. 画面ハードコピー、DBスナップショット、...） UnitTestでは、これはこのように解釈できる。 テスト手順を明らかにするもの ＝ テストコード テスト結果の証拠 ＝ 今実行すればテストが全てグリーンになること これがなぜか理解されず、軋轢とストレスと大きな工数追加になっている現場がずいぶんある。 なぜUnitTestはいつまでも理解されないのだろう。 余談。これらのことは、Seleniumなどを使
Joel on Software - ジョエル・テスト
Joel Spolsky ジョエル・スポルスキ 翻訳: Fukushige Erika 福重 永里香 翻訳チェック: Takeda Toshiyuki 武田俊之 9.8.2000 SEMAについて聞いたことがある？かなり難解なシステムで、ソフトウェアの開発チームがどれくらい良いかを測るためのものだ。ちょっと待った！そのリンクに飛ばない方がいい。きっと書いてあることを理解するだけで6年はかかるだろう。そこで、私は自分で作ることにした。これはソフトウェア開発チームの質を評価するものだが、とっても当てにならないいいかげんなテストだ。このテストの素晴らしいところは、3分程度で終わることだ。節約した時間を使って、医学部に通うことだってできるだろう。 ジョエル・テスト ソース管理システムを使っているか？ １オペレーションでビルドを行えるか？ 毎日ビルドを行うか？ 障害票データベースを持っているか？ 新
TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等） - 千里霧中
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
ソフトウェアテストの分類
静的テスト／動的テスト （ ※↓ ） 1.静的テスト、2.動的テスト モデルベーステスト ／ モデルベースではないテスト （ ※↓ ） モデルベーステスト モデルベースではないテスト 2.1. アドホックテスト、2.2.探索型テスト ホワイトボックス・テスト ／ ブラックボックス・テスト ／ グレーボックス・テスト （ ※↓ ） ホワイトボックス・テスト （ ※↓ ） 1.制御パステスト、2.データフロー・パステスト ブラックボックス・テスト （ ※↓ ） 入力値および出力値の項目を決定する方法 1.同値分割、2.境界値分析 テストケース（テストを行う入力値と出力値の項目とその組み合わせ）を決定する方法 ディシジョンテーブルを使った方法 1.単純なディシジョンテーブルの使用、 2. 原因結果グラフ、3. 実験計画法、4. 原因流れ図（グレーボックステストの一種） 状態遷移テスト ファズ・テ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
InfoQ: より良いユニットテストためのガイドライン
