テストは2つに分けられます。プログラムを動かしてその結果を評価する「動的テスト」と、プログラムを動かさずにコードを読むことで内容を検証する「静的テスト」。
「読むことで評価する」といえば、レビュー。よって、レビューも静的テストの一種と見なされます。その対象はソースコードだけでなく、仕様書や、テストに関するドキュメントも、さらには契約関係のドキュメントまでを含みます。
6.3 レビュータイプ
シラバスでは、レビューのタイプとして以下の6つを挙げています。非公式レビュー以外の5つが、レビューの国際標準であるIEEE1028(PDF)で規定されているものです。
- 非公式レビュー
- ウォークスルー
- テクニカルレビュー
- インスペクション
- マネジメントレビュー
- 監査
最初の4つがFoundationにもあるもの。復習が必要ですね。これら4つはどちらかといえば、プロダクトに関するドキュメントが対象。
「要件レビュー」に使われるのは、ウォークスルー、テクニカルレビュー、インスペクション。受け入れ基準とテスト条件もレビューの対象になるため、テストマネジャーの見識が必要になります。
「設計レビュー」に使われるのは、テクニカルレビュー、インスペクション。設計に対しどのようなテストを行うかというアプローチがレビューの対象になります。
残りの2つがAdvancedで登場したもので、対象はプロジェクト。
マネジメントレビュー（Management reviews）
IEEE1028には、目的がこう規定されています。
IEEE1028 P.14
進捗のモニタリング、計画とスケジュール状況の見定め、要求の内容とそれらに対するシステムの割り当ての確認、目標達成のために用いられるマネジメント手法の評価。
まさしくプロマネの仕事。「契約レビュー」で使われるレビュータイプが、このマネジメントレビューとなります。テストとどう関係あるのやら。
監査（Audits）
IEEE1028には、目的がこう規定されています。
IEEE1028 P.18
規制・標準・ガイドライン・計画・手続きなどに、ソフトウェアプロダクトの開発プロセスが適合していることの評価。
マネジメントレビューとともに、テストに特有の話ではありませんね。
もう1つ、試験問題っぽい話としては、Advanced Levelの3つの職位に対し、誰がどのレビューに対応すべきかの棲み分け。
- テストマネジャー：テスト計画
- テストアナリスト：ビジネス要件、テスト設計
- テクニカルテストアナリスト：機能仕様、テストケース、テストスクリプト
6.5 レビューを成功させるために
6.4・6.5は、レビューを有効なものにするために必要なことが、大量の箇条書きで示されています。「ドキュメントを次工程に渡す前に、レビューは必要だし、コストをかける価値がある」という最低限の文化があれば、当たり前にしか思えない内容ばかりですが、これを読んで、「え？そうなの？」という組織も多いのでしょうか。
特に公式なレビュータイプの場合に、レビューのトレーニングを行う。
未成熟。各々の知識と経験に基づきレビューをすること多し。
消費された時間と予算が、見つかるエラーの数に比例しないことを心に留めておく。
考えたこともありませんでしたが、なるほど。
業績考査の個人評価に、レビューによるメトリクスを使用しない。
当たり前という気もしますが、レビューされる方にはそれを恐れているかも知れませんね。とはいえ、「自分で見つけ出せる欠陥は、もう出し切ったぜ！」という自信をもてるドキュメントを、レビューにかけるべきだとは思いますが。
