🎸

レビュー JSTQB Advanced Levelテストマネージャ資格のキーワード解説!

2023/11/26に公開

レビュー

ISTQB Foundation Level シラバスにおけるレビュー

レビューは製品の静的テスト活動としてISTQB Foundation Level シラバスで紹介されており、ソフトウェア成果物に焦点を当てています。
これは、監査やマネジメントレビューと異なり、テストウェアプロダクトの品質に関する責任をテストマネージャに求めるものですが、組織のポリシーによって責任の範囲は変わることがあります。

Foundation Levelにおけるレビュータイプは下記の通りです。

  • 非公式レビュー
  • ウォークスルー
  • テクニカルレビュー
  • インスペクション

ISTQB Advanced Level シラバスにおけるレビュー

テストマネージャ、品質保証マネージャ、または訓練されたレビューコーディネーターは、プロジェクトの開始前および実行中にレビューを広範囲に適用する責任を持ちます。レビューの成功を確実にするために、「レビューリーダ」と呼ばれる責任者がいます。レビューリーダは、レビューが効果的な価値を生み出すための環境を整え、成果を測定する計画を立てる必要があります。

テスト担当者はソフトウェアの運用やシステムの要求される特性について深い理解を持っているため、レビュープロセスへの関与が重要です。レビュー参加者は全員、レビュープロセスと自らの役割について適切なトレーニングを受け、円滑なレビューに貢献することが求められます。

適切に実施されたレビューは、全体の品質向上に最大限に貢献し、もっともコスト効率の高い手段となります。このため、プロジェクトにおける効果的なレビューの実施と、これらのレビューのメリットを示すことは、レビューリーダにとって非常に重要な任務です。

テストマネージャが関わるレビューはFoundation Levelにおけるレビュータイプに追加して下記があります。

プロジェクト内のレビュー

契約レビュー

プロジェクトに関する契約文書を詳細に検討し、その内容が関係各方の要件や目的を適切に反映し、法的な義務や権利が明確であることを確認するプロセスです。契約のリスク、条項の明瞭さ、実行可能性などを検証します。
プロジェクトの開始と主要マイルストン時に行います。

要件レビュー

要件レビューは、プロジェクト要件が適切に定義され、理解されていることを確認するための評価プロセスです。
機能的および非機能的要件が整った時点で開始されます。

基本設計レビュー

一般的な基本設計レビューで、アーキテクチャ設計ができたら開始します。

詳細設計レビュー

一般的な詳細設計レビューで、レビューする準備ができたら開始します。

コードレビュー

一般的なコードレビューで、コード・ユニットテストコードができたら開始します。

テスト成果物レビュー

主に下記をレビューします。

  • テスト計画
  • テスト条件
  • 品質リスク分析結果
  • テスト
  • テストデータ
  • テスト環境
  • テスト結果

テスト開始レビュー

テスト実行を開始する前にテスト開始基準をチェックします。

テスト終了レビュー

テストを終了する前にテスト終了基準をチェックします。

受け入れレビュー

システムに対する顧客またはステークホルダの承認を得るために行います。

レビューの60秒動画解説!

https://youtube.com/shorts/wVzWXIymUqw?feature=share

マネジメントレビュー

主要なプロジェクトマイルストンで検証活動の一環として行う

  • テスト実施前
  • リリース判定

レビュー計画

レビューリーダはレビュー計画を立てる前に下記を考慮します。

  • レビュー対象
  • 特定のレビューに誰が関与するか
  • カバーすべき関連リスク要因はどれか

レビューの投資対効果

レビューの投資対効果(ROI)は、レビューによるコストと、それによって得られる利益(例: 修正コストの削減)の比較です。
効果的なレビューは、開発後期のコストを防ぎ、品質を高めます。

レビュー実行のタイミング

次の要素で決定される

  • レビュー対象のアイテムの、体裁の完成度合い
  • レビューに最適な担当者の参加可能性
  • アイテムの最終版が利用できるか
  • その特定のアイテムのレビュープロセスにかかる時間

テスト計画時にレビューに関して定義すること

  • レビュー評価のメトリクス
  • レビュープロセスの目的
    • 効果的で効率的なレビューの実施
    • レビューのフィードバックに関する合意した意思決定

プロジェクトのレビュー

下記に対して繰り返し行います。

  • システム全体
  • サブシステム
  • 個々のソフトウェア要素

下記はプロジェクトの規模や複雑さ、およびプロダクトリスクに依存します。

  • レビューの回数
  • レビューのタイプ
  • レビューの編成
  • レビュアー

レビュー参加者

効率を高めるために、技術と手順の両方に関して、適切な知識が必要です。

レビューの成功要因

レビューを成功させるためには、問題を次の3つの観点から捉えることが重要です

適用するレビュープロセスや技法

  • レビュープロセスや技法を適切に選択し、その実施を計画します。選択されたプロセスや技法は、ソフトウェアプロダクトの特性とプロジェクトのコンテキストに適合している必要があります。レビューリーダは、これらのプロセスや技法が効果的に機能する環境を整え、その実施を監督する責任を持ちます。

組織要因

  • 組織の文化や構造がレビュープロセスの成功に大きな影響を与えます。組織がレビューの価値を認識し、必要なリソースやサポートを提供することが不可欠です。レビューリーダは、組織内の関係者と協力して、レビューの目的と重要性を共有し、組織全体のサポートを確保する必要があります。

個人要因

  • レビュープロセスに関わる各個人のスキル、経験、および姿勢が、レビューの質と効率に直接影響します。レビューチームのメンバーは、適切なトレーニングを受け、彼らの役割と責任について十分に理解している必要があります。レビューリーダは、チーム内のコミュニケーションと協力を促進し、ポジティブな姿勢を醸成する役割も担います。

レビューを効果的に実施し、そのメリットを最大化するためには、これらの要因を総合的に管理し、調整することがレビューリーダに求められます。

公式レビューをする際にレビューリーダが確認すること

  • 適切な測定メトリクスをレビュー参加者が提供し、レビュー評価を効率よく行う
  • 将来のレビューに備えて、チェックリストを作成し、継続的にメンテナンスする
  • レビュー時に発見した欠陥のマネジメントを行うために、欠陥の重要度と優先度の付け方を定義する

各レビューの実施後にレビューリーダが行うこと

  • レビューメトリクスを収集
  • 識別された課題が、レビューの特定のテスト目的に十分に沿って解決されているか検証する
  • レビューの投資効果(ROI)のインプットとしてレビューメトリクスを使用する
  • フィードバック情報を関係するステークホルダに提供する
  • フィードバックをレビュー参加者に提供する

レビュー後に問題が発生した場合

Discussion