ソフトウェアテストにおいてレビューは、各種成果物の品質を保持するために必要な作業です。レビューが適切に行われず成果物の欠陥や問題点が放置されれば、ソフトウェアの品質も落ちてしまう恐れがあります。

この記事ではレビューの概要から、レビューを行うメリットや進め方、参加者の役割、成功させるためのポイントを解説します。レビューを成功させるためにも、まずはレビューに関する基本的な知識について確認しておきましょう。

レビューとは？

ソフトウェア開発における「レビュー」とは、ソフトウェアの各種成果物に対して行う静的テスト（プログラムを実行せず行うテスト）を指します。たとえば仕様書やソースコードを、目視して誤りがないかチェックするのは、代表的なレビューの手法です。

レビューは、ソフトウェア開発の様々な場面で行われます。レビューの対象は、ソフトウェア仕様書・ソースコード・ユーザーマニュアルなどソフトウェアに関わる全ての成果物です。

レビューには、ソフトウェアテストに関連した各種成果物に対するレビューもあります。対象となるのは、テスト仕様書・テストケース・テスト結果などソフトウェアテストの成果物です 。

たとえばテストケースを対象としたレビューでは、レビュー者は以下に挙げる内容をチェックします。

・記載されている条件に誤りはないか
・テストの手順と期待値に齟齬や矛盾はないか
・テスターが簡単に理解できるか
・テストに利用する資料が漏れなく添付されているか
・記載の漏れがないか

レビューを行うメリット

早い段階でレビューを行い、欠陥を検出・修正することによって、生産性が向上し開発期間を短縮させることが可能です。その結果、ソフトウェアテスト全体のコストも軽減されます。

またプログラムを動作させる必要がある動的テストでは、環境構築を行ったりモジュールやテストデータを作成したりなど時間がかかるのは否めません。それに対しレビューは、こういった準備の必要がなくフットワーク軽く速やかに実行できる点も、大きなメリットと言えます。

その分だけ早く欠陥を見つけられたり、動的テストより少ないコストで問題点を発見できたりする可能性があるわけです。また要件定義が十分でない機能や処理は、動的テストよりレビューの方が検出しやすいでしょう。

レビュータイプ（レビューの進め方に関する種類 ）

レビュータイプとは、簡単に言うとレビューの進め方に関する種類のことです。レビュータイプごとに、レビューを行う目的も異なります。以下、代表的なレビュータイプについてみていきましょう。

非公式レビュー

非公式レビューは決められた手順がなく、手順やテスト結果のドキュメント化が義務付けられていない（作成してもよい）レビューの種類です。非公式レビューは手順の決まりがないので、フットワーク軽くスピーディに実行できます。たとえば隣にいる同僚に対し、軽くコードを読んで所感を述べてもらうのも、非公式レビューの一例です。

公式のレビューは、準備に時間がかかります。一方で非公式レビューの目的は時間をかけずに、一定の成果を出すことです。すぐに欠陥と見分けがつきにくい潜在的な欠陥を検出も、非公式レビューの目的とされます。

ウォークスルー

ウォークスルーは作成者が主導して行うレビューの種類で、非公式レビューに比べ公式性は高くなります。ただしウォータースルーは必ずしも決まった手順があるわけでなく、非公式に行うことも可能です。一方で顧客向けに、要件定義などをチェックするためのウォークスルーは公式のレビューになります。

ウォークスルーの目的は欠陥の検出にありますが、それだけではありません。作成者がソフトウェアや成果物について説明することで、参加者の教育をしたり合意を形成したりするのも目的です。

テクニカルレビュー

テクニカルレビューは、ウォークスルーとは反対に作成者以外が主導するレビューの種類です。テクニカルレビューでは、同僚やレビュー対象に関連する技術の専門家がレビューアとして参加します。また経験豊富なスタッフが、モデレータ（まとめ役）として参加するのが理想です。潜在的な欠陥を検出し技術的な問題を解決することや、議論を行い合意形成することがテクニカルレビューの目的とされています。

たとえば開発チームのリーダーが、ソースコードを状況に応じて確認するといったことも非公式なテクニカルレビューの例です。一方、定型的な書式で課題の一覧を作成し、検証者がフォローアップをするような公式的なテクニカルレビューも行われます。

インスペクション

インスペクションは潜在的な欠陥の検出を目的とした、最も公式的なレビューの種類です。公式的なレビューなので、インスペクションの結果を顧客に報告することも少なくありません。インスペクションでは、作成者でなく経験を積んだモデレータが進行を主導します。参加者の役割は明確に決められ、レビュー結果のドキュメント化はもちろん、顧客へ報告する場合はレポートの作成も必要です。

インスペクションは欠陥の検出以外に、成果物や開発プロセスの評価や改善なども目的としています。

基本的なレビューの進め方・流れ

レビューは一般的に、上図のような流れで進めます。以下、それぞれどんな手順になるかみていきましょう。

①計画

レビューを行うにあたって、まずレビュー全体の計画を作成します。計画にまとめる主な内容は以下の通りです。

・レビューの目的
・参加メンバーと役割
・スケジュール

スケジュールにはミーティングの時間や実施回数、レビューに費やす期間などが含まれます。

②キックオフ

計画を作成したら、次に参加者全員でキックオフを行います。キックオフの主な目的は、レビューの目的を共有し合意することです。その上で、レビュー対象の成果物やプロセスなどを共有します。

③参加者個々の準備

参加者個々で、必要な作業・準備をする段階です。具体的には配布された資料を読み込むなどして、欠陥を検出したり質問や問題点をまとめたりします。ケースによっては静的解析ツールを用いた問題点の洗い出し、過去事例の調査なども必要になるでしょう。レビューミーティングで使用する、チェックリストの作成も必要です。

④レビューミーティング

個々で準備した内容を基に、レビューミーティングを行います。それぞれが確認した欠陥や問題点について議論し、欠陥の取り扱いについて決定することが必要です。レビューミーティングで洗い出した課題を一覧にまとめ、解決するまで状況確認できるようにします。

⑤再作業

レビューミーティングでまとめられた課題を解決する段階です。作成者は、まず課題をチェックし修正が必要か判断し、修正するべきであれば必要な作業を行います。

⑥フォローアップ

修正の担当者以外が、欠陥が修正されたかや、課題が適切に解決されたか確認する段階です。欠陥の修正や課題解決がすんでいないと判断された場合は、改めてレビューミーティングを行います。反対に欠陥修正・課題解決が完了していると判断された場合は、これでレビューのプロセスは終了です。

レビュー参加者の主な役割

レビュー参加者には、それぞれ役割が与えられます。
レビューを行う際に、参加者に割り振られる主な役割は以下の通りです。

【マネージャ】
レビューの責任者です。レビューの方針を取り決め、スケジュールの作成・管理を行います。取りまとめ役であるモデレータを選出するのもマネージャの役割です。その他、レビュー開催に伴い参加者の収集や、ドキュメントの受領などを行います。

【モデレータ（ファシリテーター）】
レビューのまとめ役で、レビュー計画の作成やレビューアの人選など、レビュー運営に必要な作業を行います。そのほか、レビュー後のフォローアップもモデレータに任せられるタスクです。

【作成者（レビューイ）】
レビュー対象となる成果物の責任を担う人です。基本的には、その成果物の作成担当者が該当します。たとえば成果物がソースコードであれば、そのソースコードを作成した開発担当者が作成者になるわけです。

【レビューア】
成果物をレビュー（チェック）し、欠陥の検出を行う人です。レビューアはモデレータによって選出されます。

レビューを成功させるためのポイント

いくつかのポイントを把握・実践することで、レビューの成果や効率を大きく改善することができます。以下、レビューを成功させる主なポイントをみていきましょう。

事前に目的を明確にしておく

レビューを開始する前に、目的を明らかにしておくことが必要です。目的が曖昧なままでは、メンバーの統率がとれず期待していたような成果をあげることはできません。たとえばソースコードをレビューしてもらうときも、どのような点をチェックしてほしいか目的を伝えれば、より効率的に作業を行えるのです。

適切なメンバーに参加してもらう

レビューでは、適切なメンバーの人選は非常に重要です。適切でないメンバーが参加すると、目的に合わない指摘が繰り返され思うように成果を上げられない可能性があります。

チェックリストを準備する

過去の問題を繰り返さないようにするため、チェックリストにまとめておくことも有効です。またモデレータがレビューして欲しい内容をチェックリストにまとめておくことで、効率的にレビューを進められます。

レビュー方法やプロセスの振り返りを行う

今後のレビュー品質 を高めるために、レビューの方法や プロセス全体に問題がなかったか振り返ります。これによって、次回以降の成果物やレビューの改善につなげられるのです。

まとめ

ソフトウェアテストにおけるレビューとは、各種成果物に対して実行する静的テスト（プログラムを実行せず行うテスト）を指します。たとえばテストケースに記載されている条件に誤りはないかを確認するのも 、レビューの一種です。

レビューを行うことによって成果物の問題点・欠陥を早期に発見し、修正することができます。レビューを適切に行うことで、ソフトウェア開発の効率や品質も向上するのです。

動的テストを行う前にレビューを実施することで、手戻りが少なくなり、生産性が向上することもレビューのメリットと言えます。 ソフトウェア開発のさまざまな段階・シーンで、レビューは有効な作業です。