【ソフトウェアテスト】レビューについて
ソフトウェアテスト領域には、動作させることを前提とした対象をテストする動的テストと、動作させることを前提としていない対象をテストする静的テストがあります。
単体テストや結合テストなど、作成したものを動作させてテストをするのが動的テストですが、静的テストは動作させる対象がなくてもテストが実施できます。
静的テスト活動の種類としてレビューがありますが、開発活動の中で作成された製品やシステム自体以外のものは、レビュー対象としてテストすることが可能です。
1. 形式的レビュー／非形式レビュー
それ自体がレビュー手法を示しているわけではありませんが、レビュー活動は大別して形式的か非形式的かに分類されます。
形式的レビューはシステマティックレビューとも呼ばれ、ある程度定められた形式にそって進行します。
非形式的レビューは早期に実施されたり限定的に実施されたりするような手法全体を指しており、特にフォーマットなどが明確に指定されていないものです。
非形式的レビューの場合は、XP(エクストリームプログラミング)を実施しているプロジェクトで用いられるペアプログラミングの様に、レビューを同僚など内部でも立場の近い領域の人がレビューするものを「ピアレビュー」と呼びます。
ピアレビューとは反対に、実装担当者からは遠い立場の領域の外部有識者などがレビューするものを「第三者レビュー」と呼びます。
2. レビューの種類
レビューについてはISO/IEC20246が国際規格になっており、レビューの形式についてはIEEE標準1028やカール・ウィーガーズ（Process Impact社）による分類などがあります。
主な分類を以下に列記します。
・ピアレビュー
・インスペクション
・テクニカルレビュー
・ウォークスルー
・マネジメントレビュー
・監査
・ラウンドロビンレビュー
2-1. ピアレビュー
形式的レビュー／非形式レビューの項でも記載しましたが、ペアプログラミングはピアレビュー手法の一つです。
ペアプログラミングの方法はプロジェクトによりさまざまあると思いますが、大まかな形式としては、コード実装や修正改修などの対応が完了した成果物について、同領域(言語・OS等)の開発を担当している同僚のエンジニアにレビュー依頼をし、同僚が対象の成果物を承認した時点で対応完了となります。
アドホックレビューやバディチェックとも呼ばれます。
テスト設計や実装に際して作成されたテストケースやテスト観点やチェックリスト、機能要件定義で作成された仕様ドキュメントなど、作成した後に同僚に確認してもらい抜け漏れなどがないかを確認するのも、ピアレビューの一つです。
2-2. インスペクション
テクニカルレビューの種類の中でも、インスペクションは形式が最も明確に定義されているレビュー技法です。
参加するメンバーや実施のフェーズが定められています。
・ファシリテーター(Inspection Leader)
レビュー全体の責任者です。
計画・準備・進行管理の役割を担います。
・作成者(Author)
レビュー対象物の作成者です。
レビュアーは対象物について作成者に質問し、作成者はレビュアーの質問に回答するという役割を担いますが、後述の理由から作成者自身はレビューに際して対象物の読み上げや説明はしません。
・読み上げ係(Recorder)
作成者とは別の人間を読み上げ係として立てることにより、対象物の説明に際して共有展開されている内容以外の部分を説明の最中に補ってしまうことを避け、形式的に説明のみを進行させることができます。
・記録係(Recorder)
レビューの内容を記録します。
状況によってファシリテーターなどが兼任する場合があります。
・レビュアー(Inspector)
対象を審査評価し、質問や指摘をします。
テクニカルレビューは第三者レビューとも呼ばれるとおり、領域の違うさまざまな専門家による複数の観点からレビューを行うことで、作成者では検知できないような指摘や質問を出すことができます。
インスペクションではレビューの進行も定められたフェーズに従って進めます。
IEEE標準1028では以下フェーズで分けられています。
1. マネジメント準備(Management preparation)
2. 計画(Inspection Planning)
3. 手順の概要(Overview of inspection procedures)
4. レビュー対象の概要(Overview of inspection product)
5. 準備(Preparation)
6. レビュー実施(Examination)
7. フォローアップr(Rework/Follow-up)
ルール、プロセス、メンバー、レビューに際して作成されるドキュメントなども、形式が厳格に定められています。
2-3. テクニカルレビュー
インスペクション同様に形式や役割が定められた形式的レビューですが、インスペクションよりも規格の許容範囲が広い形式になります。
ファシリテーターが進行し記録係が記録する、レビュアーが質問して作成者が返答するといった役割は共通していますが、そのほかに意思決定者(Dicision Maker)という役割を担う人がいます。
レビュー結果を受けて修正判断やリリース判断などの決定をする役割の人です。
PMやステークホルダーなどが上記の役割としてレビューに参加する場合があります。
プロセスや作成物にも規格はありますが、テクニカルレビューの場合はインスペクションよりも形式が自由であり、明確に欠陥の検出を目的としているというよりも、仕様標準の確認やステークホルダー間での合意形成が主な目的になる場合があります。
2-4. ウォークスルー
テクニカルレビューよりもさらに規格の許容範囲が広い形式です。
進行はファシリテーター、記録は記録係、レビュアーがレビューするという役割は先の形式と同様ですが、ウォークスルーでは対象物の作成者が読み上げ説明をする役割を兼任します。
作成者と読み上げ係を分ける利点は、共有された対象物に関する説明を作成者本人以外に説明させることによって、レビュープロセス内の説明プロセスを対象物に記載されている事項のみに絞って説明させるため、説明の最中に補足したり質疑応答したりというプロセスが混在せずスムーズに進行できるという点ですが、作成者に読み上げを兼任させることで、明確にプロセスを分けずに説明補足質疑を同時進行できるため、レビューのコストを軽くすることができます。
シナリオや処理を元にレビューを進行し、欠陥の検出を目的としていますが、先の形式と比べて簡潔な形式のため、綿密に計画を立てて目標を達成するための会議というより、さまざまな視点から意見を出し合うブレインストーミングのような側面を持つ形式です。
2-5. 監査
リリース対象のソフトウェアやサービスが、法的基準や業界標準などに準拠しているかを、開発サイドではない外部専門家が確認する形式です。
各領域での有資格者である専門家へ依頼します。
2-6. ラウンドロビンレビュー
参加者は基本的に全員レビュアーとしてアサインされますが、レビュアーの中から説明者を選出してレビューを進めます。
このため、レビュアーは説明者の役割を果たせる程度には対象物に対する知見を持っている必要があります。
一つの対象物に対して複数回のレビュー実施を計画しておくことで、各回ごとに説明者の役割を順に交代して担うことができます。
説明者とレビュアーの各視点から対象物を評価することで、1名のレビュアーが複数観点からレビューすることができ、かつ、レビューに参加した人員全体が対象物に対する理解を深めることができる手法です。