本日読了。
良書。ソフトウェアテストの理想と現実を、筆者の海外に渡る多彩な経験と、独自の語り口調で説明する。
- ホワイトボックステストは、カバレッジというメトリックスが使えるため、管理者には人気。ステートメントカバレッジは、確認できる範囲は限定的なので，ほとんど役立たない。また80%、90%のカバレッジを目指すには、テスト技術者が深くコードを読み込む必要があり、コストがかかる。60%程度で出荷されるプロダクトが多い。ブランチカバレッジも交えるとやや確認できる範囲は広がる。しかしながら、昨今はアジャイル・TDDが主流になってきたため、カバレッジが高くなってきた。
- ブラックボックステストは機能仕様を確認するのに最適。同値分析や境界値分析、ディシジョンテーブルにより、テストケースを効率的に抽出する。
- 探索的テストは、テスト技術者が実際にソフトウェアを操作してみて、試行錯誤的にバグを見つける。GUIに強く、探索的テストと他のテストを併用すると、効果が高い。
- 非機能要求テストは難しい。パフォーマンステストは早期から取り組んで回帰テストをしないと、大きなアーキテクチャーバグを組み込んだままスケジュール終盤になってしまい、取り返しが効かない。
- テストプラン策定の拠り所として、IEEE829がある。
- テストケース管理ツールを使うとよい。
- メトリックスとして、コードの複雑度を測る、サイクロマチック複雑度がある。複雑度の高いモジュールを、集中的にテストする。Microsoftでも使っている（た？）。
- 最近では、GoogleがSREの概念として、開発者とテスト担当者を融合させてきた。（本書の時点ではSREという単語は形成されていない）
本書はやや古いが、直近で「ソフトウェア品質を高める開発者テスト アジャイル時代の実践的・効率的なテストのやり方」が出ており、後で読む。
