テスト: 2007年9月アーカイブ

客先で発見されたバグは、あなたのテストシステムへ追加するべき完全な候補である。

「基本から学ぶテストプロセス管理」

テスト計画が現実に合わなくなったら、フレキシブルに対応する。例えばテストスイートの選択をミックスするというような。

「基本から学ぶテストプロセス管理」

新しいファイルがリリースされたら、そのリリースでフィックスされたバグをまずテストする。

「基本から学ぶテストプロセス管理」

テストで問題になる２つの間違い。タイプⅠエラー：実際はバグでないのにテスト実行者がバグだと報告すること。（時間の無駄）タイプⅡエラー：実際のバグを見逃すこと。（品質へのリスク）

「基本から学ぶテストプロセス管理」

ホワイトボックス／ブラックボックスは単純化しすぎていて危険だ、という人もいる。結局、「全てのモデルは間違っているが、いくつかは役に立つ」ということなのであろうか。

「基本から学ぶテストプロセス管理」

エラー修正のとき、しばらく設計段階にもどってみよう。

「ソフトウェア・テストの技法」

修正が正しいという確率は１００％ではない。

「ソフトウェア・テストの技法」

エラーの徴候ではなく、エラーそのものをなおそう。

「ソフトウェア・テストの技法」

１つのバグがあるところには、別のエラーもある可能性が高い。

「ソフトウェア・テストの技法」

プログラムのある部分でエラーがまだ存在している確率は、すでにその部分で見つかったエラーの数に比例する。

「ソフトウェア・テストの技法」

エラーは見つからないだろうという仮定のもとにテストの計画を立ててはいけない。

「ソフトウェア・テストの技法」

プログラムが本当に使い捨てのものでないかぎり、そのテスト・ケースも使い捨てにしてはならない。

「ソフトウェア・テストの技法」

プログラムをしらべるのに、それが意図されたように動くかどうかをみただけでは、半ば成功したにすぎない。残りの半分は、意図されなかった動きをするかどうかをしらべることである。

「ソフトウェア・テストの技法」

テスト・ケースは、正しい予想できる入力条件ばかりでなく、誤った予想しないばあいも考えて書かなければならない。

「ソフトウェア・テストの技法」

それぞれのテストの結果を完全に検査せよ。

「ソフトウェア・テストの技法」

プログラマは自分自身のプログラムのテストをしてはならない。プログラマがプログラムを設計してコーディングするあいだは建設的であり、一夜明ければ突然見かたをかえて、そのプログラムに対して完全に破壊的な心構えをもつようにするということは非常に困難である。

「ソフトウェア・テストの技法」

テスト・ケースの必須条件は、予想される出力または結果を定義しておくことである。なぜなら、”自分に都合のよいように見える”という現象があるからである。

「ソフトウェア・テストの技法」

ベータテストで効果をあげるためには多くの調整作業が必要である。むしろ、そのために必要な資源を会社内部でのテストに振り向ければ、より大きな品質保証上のメリットを生み出すことができる。

「ソフトウェア　プロジェクト　サバイバル　ガイド」

テストはソフトウエアシステムの品質レベルを調べる手段であり、ソフトウエアの品質を保証する手段ではない。

「ソフトウェア　プロジェクト　サバイバル　ガイド」