- 作者: 高橋寿一
- 出版社/メーカー: 翔泳社
- 発売日: 2013/12/10
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (7件) を見る
- テスト計画
テストでも何でもそうだが、先ず始めに計画ありき。
テスト計画書はIEEE829のテストテンプレートをカスタマイズする。
計画に盛り込むリスクは下記の式で算出。
リスク＝問題の発生確率×発生した場合のダメージ
典型的なリスク要因として、複雑度／新規性／大きな変更／上位依存性（未出荷の製品やコンポーネントに対する依存関係）がある。
- テスト実施
やるべきテストは下記3つ。
1. 境界値テスト
2. デシジョンテーブルでのパターン網羅
3. 状態遷移（ただし、アーキテクチャ設計、デザインパターンの適用でバグを抑えられる）
- レビュー
テスト仕様書や結果のレビューが追いつかない場合、バグがありそうな箇所を重点的に攻める。
1. 複雑度メトリクスの高いもの
McCabeサイクロマティック数の複雑度＝プログラムに含まれるルートの数−分岐点の数＋２
→この数よりもテストケース数が少ないのは論外
21〜50は高リスク、50〜はテスト不能らしいが、50を超えるプログラムはざらにあるが・・・
2. 頻繁に変更されているコード（Googleのバグ予測システムでも使われている）
- 管理
「バグ曲線が寝た」→「出荷して問題ない」という論理は弱い。
テストの終盤になってバグが増加するケースもあるので、その場合は下記の指標を取り入れる。
1. 重要度の高いバグが減ってきているか(→出荷可能なレベルになっているか)
2. バグ修正にかかる時間が短くなってきているか(→プログラマが忙しすぎて修正に手が回らない、といった事態ではないか)
3. コンポーネント毎のバグ数をみて分析(→20%のコードに80%のバグがある)
- その他
・テストの自動化
概して上手くいかない。特に、画面系の自動化は止めた方がいい。メンテのコストが高すぎる。
逆に、共通機能とかAPI的なものは自動化した方がいい。
・探索的テスト
ソフトウェアの理解＋テスト設計＋テスト実施を同時に行う手法。バグ発見効率が良い。
一個人の責任として、きちんと仕様を理解して、テスト設計し、テストし、バグ報告するスタイル。
→当たり前のことすぎるが、実際のところ、これができない人が多すぎて困る。
テスト仕様書は必ずしも必要ではない。下記のようなテストも取り入れる。
- 弱いところを見つけて重点的にテストする
- 実行環境を変えてテストしてみる(ブラウザを変えるとか)
- 重要機能に対してシンプルなテストを実施し、デグレしてないことを確認する
→うまいこと計画に明記し、うまいことテスト内容とエビデンスを残さないと、実際のプロジェクトに取り入れるのは難しいと思う。
重役を説得するにはどうすればよいだろうか・・・
