なかなか学べる箇所のある本でした
- バグは特定の場所に偏在している。プログラムの4%の部分に半分近くのバグが偏在しているという例もある
- テストケースを書くことはプログラムを書くより難しい
- テストは限られた時間で行う最大公約数的な仕事
- ソフトウェアの品質管理者になるなら、最低限のプログラミングの知識が必要
- 才能のある人は10人分のバグを見つけられる
- 探索的テスト＋スキルのあるテスト担当者は最強のコンビ。短時間で最強の結果が出る
- テストの終了基準を設けることは重要。
- 48時間以内に重要度「高」のバグが発見されていないこと
- 重要度「高」のバグが解決している
- テストケースの98%が解決している
- テストケースの管理ツールを使うとよい
- 修正箇所と修正時間の多い箇所にはバグが多い。
テストの終了基準を明確に設けられたことはありません。
自分としてはテストケースを一通り終えて、バグを対処して、あとはモンキーテストして、リリース日迎えられそうならいっか。
みたいな感じでした。
テストコードを書くことはプロダクトのコードを書くことの方が大変なんですよね。
