レビュー

レビューとは、1人もしくは複数人で作業成果物やプロセスを評価して、改善していく静的テストです。
プロセスに沿った形式的レビューと非形式的レビューがあります。

形式的なレビューの実施では、各プロセスの標準で行い多くのタスクが必要になります。
作業成果物のレビューによって、同じ成果物に対してレビューを複数回実施することがあります。

レビューの役割と責務

レビューには役割と責務があり、JSTQBの役割と責務を次に記載します。

プロジェクト内のレビューには以下があります。

レビュープロセス

1

レビュー計画

実施するレビューを計画します。
目的、作業成果物、評価対象の品質特性、重点を置く領域、終了基準、標準などの裏付け情報、レビューの範囲を決めます。

2

レビューの立ち上げ

実施するレビューを立ち上げます。
レビューの立ち上げでは、作業成果物や人員とレビューの役割と責務を明確にしてレビューに必要なものを確認します。

3

個々人のレビュー

各レビューアは、作業成果物の品質を評価して不正・推奨・質問を識別して記録します。

4

共有と分析

レビューで実施した不正・推奨・質問に対してアクションします。
アクションを完了させるためのフォローアップのレビューが必要になる場合があります。

5

修正と報告

是正処置のために欠陥レポートを作成して、レビューの終了基準に満たしている場合はレビューの結果をレポートします。

作業成果物のレビューを完了させるためには、レビュープロセスを複数回実施することもあります。

レビュー成功要因

レビューを成功させるには、レビューに参加する人の役割と責務を定義してプロセスに準拠していくことです。
レビューの成功要因は以下の通りです。

テストアナリストでは、レビュー成功させるためにレビュープロセスに積極的に参加して、技術的な見解を提供します。
技術的な見解とは、レビューを静的テストの観点で参加してレビュー対象の欠陥を発見して指摘することでドキュメントの品質を向上させます。
開発プロセスの早い段階で欠陥を発見することで、費用対効果の向上に貢献できます。

また、レビューに参加する前に、レビュー対象のドキュメントを事前に検査することを事前ミーティング準備といいます。
事前ミーティング準備では、ドキュメント内容の理解・関連ドキュメントのチェック・一貫性やトレーサビリティなど欠落のチェックします。

レビュー種別

JSTQBのシラバスではレビュー種別には、非形式的レビュー・ウォークスルー・テクニカルレビュー・インスペクション・マネジメントレビュー・監査の6つがあります。
テストアナリストは、非形式的レビュー・ウォークスルー・テクニカルレビュー・インスペクションの4つに参加します。 レビューの詳細は以下に記載します。

非形式的レビュー

非形式的レビューは、場所やドキュメントのアウトプットも必要としないレビューです。
そのため、コストを最小限に抑えてレビューの効果を得ることができます。
レビューの目的は、初期段階のアイデア出しや軽微な修正の確認など不正の検出です。

ウォークスルー

ウォークスルーは作成者が主導で進めて、参加者が質問や意見を出し合っていくレビューです。
レビューの目的は、品質評価や作業成果物の信頼向上、レビューアの教育、合意形成、新しいアイデアの出し、作成者のモチベーション向上と改善、不正の検出などです

テクニカルレビュー

テクニカルレビューは、モデレータが主導で進めて、ソフトウェアの技術的な側面に焦点を当てたレビューです。
ソフトウェアの技術的な内容が分かる人が参加して、ドキュメントの内容を確認していきます。
レビューの目的は、技術的な問題に関して合意、不正の検出、品質評価や作業成果物に対する信頼の向上、新しいアイデア出し、作成者のモチベーション向上と改善などです。

インスペクション

インスペクションは、訓練されたモデレーターが進行して、品質管理プロセスの一環として行われる形式的なレビューです。
レビューアに役割を割り当てたり、チェックリストを用います。
メトリクスを収集して、ソフトウェア開発ライフサイクルのプロセス改善にも使用されます。
レビューの目的は、不正の検出、品質評価や作業成果物に対する信頼向上、作成者のモチベーション向上と改善などです。
議事録を必ず作成するのも特徴です。

マネジメントレビュー

マネジメントレビューは、組織の戦略や目標に対する進捗状況を評価し、必要な改善策を決定します。
シーケンシャルな開発では、次のステップへ移行できるかの確認も実施します。
レビューの目的は、 組織の戦略や目標に対する進捗状況を評価し、必要な改善策を決定します。

監査

監査は、組織の業務やプロセスが規定された基準や規則に従って適切に行われているかを評価し、改善点を見つけます。
監査のモデレータは、監査リーダが行います。
レビューの目的は、組織の業務やプロセスが規定された基準や規則に従っているかの確認です。

レビューの技法

チェックリストベースドレビュー

チェックリストベースドレビューは、ソフトウェア開発や品質管理のプロセスで、チェックリストを作成してそれに基づいてレビューします。
チェックリストには、レビュー対象の項目や基準をリストアップし、品質基準や要件や設計ガイドラインを含んで属人的なレビューを軽減します。

テストアナリストは、チェックリストベースドレビュー（レビューでチェックリストを利用すること）でレビューの一貫性と網羅性を確保します。

チェックリストの特定側面

チェックリストは、以下の特定側面を対象とします。

チェックリストの精度が高ければ、問題を識別しやすくなります。
標準チェックリストと組織固有のチェックリストを組み合わせて使用することで、作業成果物の品質を向上できます。

要件レビュー

要件レビューとは、要件が正確で完全であることを要件ドキュメントを仕様してレビューします。
テストアナリストは、要件のテスト方法とテストケースから要件をトレースできるようにする必要があります。
要件がどのようにテストするか判断できない場合は欠陥があると認識する必要があります。

要件が変更されたら、追従してテストケースを修正してレビューを行っていきます。
要件レビューで使用するチェックリストのアイテムはJSTQBのシラバスでは以下のような例があります。

要件は抽象的や不明確な場合、テストケースに落とし込むことができません。
テストアナリストは、レビュー時に指摘してテストケースに落とし込めるようにする必要があります。

チェックリストの調整基準

チェックリストは、以下の調整基準があります。

ユーザーストーリーレビュー

ユーザーストーリーレビューとは、要件をユーザーストーリーに基づいてレビューします。
ユーザーストーリーでは、ユーザーストーリー、ユーザーストーリー番号、優先順位、ビジネス価値、見積り、ユーザへの受け入れ基準をベースにします。

ユーザへの受け入れ基準では、ユーザーストーリーがテストが行えるように明確に記載します。
ユーザへの受け入れ基準、ステークホルダーと認識を合わせて受け入れテストのテストケースを作成していきます。 また、ユーザーストーリーは、ユースケ―スの記述と同様に、ユーザーインタフェースや具体的なメッセージは記載しません。

ユーザーストーリーでは以下が求められます。

ユーザー ストーリーは独立していて、通常は開発にかかる時間によって範囲を定めます。
ユーザーストーリーが新しいインターフェースを定義したら、ストーリーチェックリストとユーザーインターフェースチェックリストを使用することが適切です。

マネジメントレビュー

マネジメントレビューは、組織の戦略や目標に対する進捗状況を評価して、必要な改善策を決定することでした。
シーケンシャルな開発では、次のステップへ移行できるかの確認も実施します。
レビューの目的は、 組織の戦略や目標に対する進捗状況を評価し、必要な改善策を決定します。

マネジメントレビューの特徴として、プロジェクトに直接責任を持つマネージャ、ステークホルダ、意思決定者な度が実施し、計画との整合性や逸脱、マネジメント手順の妥当性をチェックする。 リスクやアクションの影響、その測定方法を評価し、課題への対応方針を決定します。

監査

監査は、組織の業務やプロセスが規定された基準や規則に従って適切に行われているかを評価し、改善点を見つけることでした。
レビューの目的は、組織の業務やプロセスが規定された基準や規則に従っているかの確認です。

監査の特徴として、監査リーダが管理やモデレートを行い、準拠しているかのエビデンスを収集します。
監査リーダが観察事項・勧告・是正措置・合否アセスメントを成果物ドキュメントに含めます。

レビューのマネジメント

テストマネージャーは、マネージャーまたはレビューリーダーのレビューには役割があります。
その役割に応じて、レビューの計画・実施・リソースの提供を行います。
レビューの戦略として、テスト戦略やテストポリシーと適合しているかも検証します。

レビュープロセス

1

レビュー計画作成前

レビュー対象の選定、レビューの関与メンバ、カバーすべき関連リスク要因を考慮

2

レビュー計画

レビュー対象、レビュータイプ、レビューの公式度合、レビューの予算（時間とリソース）、メトリクス、レビュープロセスの目的

3

レビュー実施

レビュー対象の完成度、レビュー担当者の選定、レビュー対象の最終版完成時期、レビューにかかる時間
インスペクションを実施する場合、簡易的（要件単位や節単位）にインスペクションを実施

4

レビュー実施後

レビューメトリクスを収集し、テスト目的に沿って解決されていることを保証
レビューの投資効果(ROI)を決定するためのメトリクスを使用
フィードバック情報をステークホルダやレビュー参加者に提供

レビューのためのメトリクス

テストマネジャーまたはレビューリーダはメトリクスを使用して次のアクションできるようにします。

レビューのメトリクスには以下があります。

公式レビューのマネジメント

公式レビューには、定義済の開始基準と終了基準があり、チェックリストを使ってレビューし、レポートや評価シートなどの提供物、レビュー効果をレポートするためのメトリクスを収集します。
非公式レビューの場合、これらが明記されていないこと多いです。
公式レビューの開始として、前提条件を満たしていない場合、レビュー責任者（プロジェクトマネージャなど）に相談して最終判断してもらいます。

← ソフトウェア品質特性の問題
レビューの問題 →