第5章：レビュー

テストアナリストが、要件・ユースケース・ユーザーストーリーをチェックリストでレビューする方法を扱う。

問題1

要件レビューのチェック項目として、最も適切なものを選びなさい。

1. 開発者の個人的な好みと文書のページ数
2. テスト実行後に発生した欠陥の件数だけ
3. 要件の出どころ、優先度、受け入れ基準、テスト可能性
4. 本番環境の CPU 使用率だけ

問題2

次の要件のうち、テスト可能性に問題があるものを選びなさい。

1. 「ソフトウェアは使用性標準文書 Version 3.2 に適合すること」
2. 「検索結果は 2 秒以内に表示されること」
3. 「ソフトウェアは非常にユーザーフレンドリーであること」
4. 「管理者はユーザーを登録できること」

問題3

ユースケースレビューで確認すべき項目として不適切なものを選びなさい。

1. メインフローが明確に定義されているか
2. 代替フローとエラー処理が識別されているか
3. UI メッセージが必要な場合に定義されているか
4. すべてのフローを必ず 1 つの巨大なユースケースに統合しているか

問題4

次のうち、ユーザーストーリーのレビュー観点として誤っているものを選びなさい。

1. 対象スプリントに適切か
2. 要求者・ユーザーの観点で記述されているか
3. テスト可能な受け入れ基準があるか
4. 他のすべてのストーリーと必ず結合されているか

問題5

チェックリストをプロジェクト向けに調整する際に考慮すべき組み合わせとして正しいものを選びなさい。

1. 組織の標準、プロジェクトのリスク、成果物の種類、適用するテスト技法
2. レビュー担当者の気分だけ
3. 常に同じ内容に固定し、リスクによる変更を禁止する
4. テスト対象の画面色だけ

問題6

受け入れ基準をレビューする際の観点として、最も適切なものを選びなさい。

1. 受け入れ基準が存在しないか
2. 開発者だけが理解できる表現か
3. どの機能にも同じ曖昧な文言を使っているか
4. 合否を判断でき、テストケースへ変換できる程度に具体的か

問題7

要件に一意な識別子とバージョンを付ける利点として、最も適切なものを選びなさい。

1. 要件の内容を自動的に正しくする
2. 変更履歴やトレーサビリティを追跡し、影響を受けるテストを識別できる
3. 要件レビューを不要にする
4. 欠陥報告を禁止する

問題8

ある文書で「顧客」「利用者」「ユーザー」が同じ意味で混在している。レビューで指摘すべき理由として最も適切なものを選びなさい。

1. 文書のページ数が増えるため
2. すべての用語を英語にする必要があるため
3. 解釈の違いや要件間の矛盾を生む可能性があるため
4. テスト技法を使えなくするため

問題9

「すべての画面は標準文書 Version 2.0 の使用性基準に適合すること」という要件について、最も適切な評価を選びなさい。

1. 画面が多いので必ずテスト不能である
2. 標準文書を参照してはいけない
3. 合否を判断する必要はない
4. 参照標準が利用可能で、判定基準が明確ならテスト可能かつ複数画面へ適用できる

問題10

要件間のトレーサビリティをレビューする観点として、最も適切なものを選びなさい。

1. 詳細要件をすべて独立させ、上位目的との対応をなくすか
2. テストケースだけを確認し、要件間の関係は確認しないか
3. 要件の出どころを削除するか
4. ビジネス／マーケティング要件から詳細要件、ユースケース、ユーザーストーリーへ追跡できるか

問題11

ユースケースのメインフローについて、最も適切なレビュー観点を選びなさい。

1. メインフローを定義せず、代替フローだけを書くか
2. メインフローはテスト不能でよいか
3. すべての例外をメインフローに隠すか
4. 基本的な成功シナリオが明確で、メインの振る舞いが複数混在していないか

問題12

ユースケースレビューで、基本フローしか記述されていない場合の指摘として最も適切なものを選びなさい。

1. 基本フローだけで必ず完全である
2. エラー処理は実装時に初めて考えればよい
3. エラー処理はテスト対象外である
4. 代替フロー、例外、エラー処理の振る舞いが不足していないか確認する

問題13

ユースケースで「登録に失敗した場合はエラーを表示する」とだけ書かれている。レビューで確認すべきこととして最も適切なものを選びなさい。

1. エラー時の表示は不要か
2. すべてのエラーで同じ文字列にするか
3. エラーはログだけでよいか
4. メッセージの内容、表示条件、ユーザーが取るべき行動などが定義されているか

問題14

ユーザーストーリーが「データベースのテーブルを追加したい」とだけ記述されている。レビューで指摘すべき主な問題は何か。

1. 技術用語を使ってはいけないという問題だけ
2. 受け入れ基準が必ず不要になる
3. ストーリーはユーザー目的を書いてはいけない
4. ユーザーや要求者の観点、達成したいゴール、理由が明確でない

問題15

ユーザーストーリーが他の 3 つのストーリーに依存しないと実装できない。この場合のレビュー観点として最も適切なものを選びなさい。

1. 依存関係は必ず隠す
2. 受け入れ基準を削除する
3. すべてのストーリーを 1 件へ結合する
4. ストーリーを分割・再整理し、可能な限り独立したフィーチャーにする

問題16

ユーザーストーリーのレビューで、対象イテレーションに適切かを確認する理由として最も適切なものを選びなさい。

1. すべてのストーリーを同じスプリントへ入れるため
2. 優先度をなくすため
3. レビュー対象をコードだけにするため
4. ストーリーの範囲、受け入れ基準、テスト準備が実行可能か確認するため

問題17

ユーザーストーリーに優先度がない場合、レビューでの問題として最も適切なものを選びなさい。

1. 実装・テストの順序やリスクに基づく資源配分を決めにくい
2. そのストーリーは必ず誤っている
3. 受け入れ基準が自動的に正しくなる
4. テスト技法を使う必要がなくなる

問題18

次のうち、一般的なユーザーストーリー形式に最も近いものを選びなさい。

1. 「テーブルを追加する」
2. 「管理者として、利用停止ユーザーを検索したい。なぜなら再有効化の判断をしたいから」
3. 「API-203 を修正する」
4. 「ボタンを赤くする」

問題19

同じ要件レビューで、汎用チェックリストと使用性向けチェックリストを併用する利点として最も適切なものを選びなさい。

1. 文書の一般的な品質と、使用性固有の観点を両方確認できる
2. チェックリスト項目が重なるため、レビューは必ず無効になる
3. 汎用チェックリストを使えば専門観点は不要である
4. 専門チェックリストはリスクと関係がない

問題20

セーフティクリティカルな要件をレビューする場合のチェックリスト調整として最も適切なものを選びなさい。

1. 安全性に関する固有の要件、規制、証跡、受け入れ基準を追加する
2. 安全性に関する項目を削除する
3. すべての要件を簡略化する
4. リスクを考慮せず、一般的な UI 項目だけにする

問題21

デシジョンテーブルをレビューするチェックリストに含めるべき項目として最も適切なものを選びなさい。

1. 条件の組み合わせが完全か、重複・矛盾がないか、各ルールのアクションが明確か
2. 画面の色だけ
3. 状態遷移のループ回数だけ
4. ユーザーの経験年数だけ

問題22

チェックリストレビューについて、最も適切な説明を選びなさい。

1. 項目を確認すれば、チェックリストにない問題を議論してはならない
2. 見落としや属人性を減らすが、チェックリスト外の問題についても議論すべきである
3. チェックリストがあれば、レビュー参加者の判断は不要である
4. チェックリストの内容は一度決めたら更新しない

問題23

要件レビューを早期に行う主な利点として最も適切なものを選びなさい。

1. 欠陥や曖昧さを実装・テスト前に発見し、後工程の修正コストを抑えられる
2. 以後のテストがすべて不要になる
3. 受け入れ基準がなくても問題ない
4. レビューではテスト可能性を扱えない

問題24

要件レビューを開始する前の準備として、最も適切なものを選びなさい。

1. 参加者が各自の方法で読み、目的や観点を決めずに開始する
2. レビューの目的・対象範囲・完了条件・参加者の役割を明確にする
3. 欠陥を見つけるまで対象範囲を無制限に広げる
4. 作成者を参加させず、質問も受け付けない

問題25

次の要求のレビューで、テストアナリストが最も優先して指摘すべき問題を選びなさい。

「システムは大量のアクセスがあっても、十分に高速に応答しなければならない。」

1. 性能の対象、負荷条件、応答時間の基準が測定可能になっていない
2. 要求に性能という言葉が含まれている
3. 性能テストは実装後にしかできない
4. 要求レビューでは非機能要求を扱わない

問題26

次のユースケースのレビューで、正常フロー以外に確認すべき観点として最も適切なものを選びなさい。

利用者が商品を購入し、決済が成功したら注文を確定する。

1. 決済失敗、在庫不足、通信タイムアウト時の振る舞いと回復方法
2. 正常に購入できる利用者の氏名だけ
3. 画面のタイトルのフォントだけ
4. 開発者が想定した内部クラス名

問題27

次のユースケース記述について、レビューで最も問題となるものを選びなさい。

「利用者は適切な情報を入力し、システムは必要な処理を行い、よい結果を表示する。」

1. アクター、入力、処理、結果、成功条件が具体化されておらず、テスト条件を導けない
2. ユースケースは文章で書かれている
3. 利用者とシステムの両方が登場している
4. 正常フローが一つにまとめられている

問題28

次のユーザーストーリーのレビューで、テストアナリストが追加を提案すべきものを選びなさい。

「購入者として、注文履歴を見たい。過去の注文を確認できるようにするため。」

1. 表示対象期間、注文がない場合、権限外の場合の受け入れ基準
2. 実装クラスの継承関係
3. データベースのインデックス名
4. 開発者の作業時間だけ

問題29

次のストーリーについて、レビューで分割を検討すべき理由として最も適切なものを選びなさい。

「利用者として、商品を検索し、比較し、購入し、配送状況を確認し、返品したい。」

1. 価値・受け入れ基準・テスト範囲が大きく異なる複数の目的を含み、見積もりや検証が困難だから
2. 一つのストーリーには動詞を一つしか使えないから
3. テストアナリストは購入機能を扱えないから
4. ストーリーは必ず技術タスクに分解してはならないから

問題30

過去のWeb画面レビュー用チェックリストを、医療機器の組込みソフトウェア要件レビューにそのまま適用しようとしている。最も適切な対応を選びなさい。

1. 過去のチェックリストは常に正しいため変更しない
2. 共通観点を活用しつつ、規制・安全性・ドメイン固有の観点を追加し、不要な項目を見直す
3. チェックリストを使わず、記憶だけでレビューする
4. 医療機器ではレビューを実施しない

問題31

リリース後に、レビューで見落とされた権限要件の欠陥が発見された。次回レビューへの改善として最も適切なものを選びなさい。

1. 欠陥を見つけた担当者だけが注意する
2. 原因と再発条件を分析し、権限・境界・異常系のチェック項目を見直す
3. 既存のチェック項目をすべて削除する
4. レビュー時間を短くすることだけを目標にする

問題32

レビュー中に、要件間で矛盾する業務ルールが見つかった。最も適切な対応を選びなさい。

1. テストケース側で勝手に一方を採用する
2. 指摘を記録し、影響と未解決状態を明確にして、適切な要求・業務責任者に解決を依頼する
3. 作成者を責めてレビュー記録には残さない
4. 実装してから利用者に判断してもらう

問題33

レビューで「合計金額は正しく計算される」という要求の曖昧さを解消した。次の説明として最も適切なものを選びなさい。

1. 要求が明確になったため、実装後のテストは不要である
2. レビューで要求の欠陥を減らせるが、実装された計算処理の動的な検証は別途必要である
3. 動的テストでしか要求の問題は発見できない
4. レビューとテストは同じ活動なので片方だけでよい

問題34

要件レビューの開始条件として、最も適切な組合せを選びなさい。

1. 対象範囲、目的、基準資料、参加者、記録方法が合意され、成果物がレビュー可能な版として識別できる
2. 作成途中の文書を版管理せず、参加者が自由に修正する
3. レビュー時間だけ決め、何を確認するかは当日に決める
4. 作成者が内容を説明できれば、レビュー対象の版や範囲は不要である

問題35

レビューで「パスワードを十分安全にする」という要求を発見した。テストアナリストの指摘として最も適切なものを選びなさい。

1. 安全という言葉があるのでテスト可能である
2. 長さ、文字種、漏えいパスワード、試行回数、エラー応答などの判定可能な基準を明確にする
3. セキュリティ要求はレビューせず、実装後に攻撃して確認する
4. テスト担当者が独自の安全基準を決めて確定する

問題36

ユースケースのレビューで、正常フローは詳細だが、事後条件が「処理が終わる」とだけ書かれている。最も重要な確認を選びなさい。

1. 成功後の業務状態、保存されるデータ、通知、次に許される操作を具体化する
2. 正常フローの手順をさらに細かくし、事後条件は変更しない
3. 事後条件は実装詳細なので、レビュー対象外にする
4. 例外フローを削除して正常系を短くする

問題37

次のユーザーストーリーについて、レビューで最も優先して解消すべき問題を選びなさい。

「管理者として、すべての利用者を管理し、請求を修正し、監査ログを確認したい。運用を効率化するため。」

1. 複数の価値と権限リスクを含むため、独立した価値・受け入れ基準で分割する
2. 「管理者として」という形式があるので問題ない
3. 技術タスクに分割すれば、受け入れ基準は不要である
4. 管理者機能は利用者価値を持たないため、削除する

問題38

「注文履歴を表示する」というユーザーストーリーの受け入れ基準として、最もテスト可能なものを選びなさい。

1. 使いやすく表示される
2. 利用者本人の注文だけを、指定期間・ページ単位で表示し、注文がない場合は明確なメッセージを表示する
3. 高性能な画面にする
4. 開発者が必要だと判断した項目を表示する

問題39

過去の欠陥の多くが、要件間の矛盾と異常系の未定義に起因していた。次回レビュー用チェックリストの改善として最も適切なものを選びなさい。

1. 項目を増やすだけで、適用対象や重複を確認しない
2. 矛盾、境界、異常・代替フロー、テスト可能性を追加し、実際に欠陥検出へ寄与するか評価する
3. 正常系の項目をすべて削除する
4. チェックリストを固定し、プロジェクト固有の情報を入れない

問題40

レビューの品質を「発見した指摘件数」だけで評価することの問題として、最も適切なものを選びなさい。

1. 指摘件数が多いほど、必ずレビューの品質が高い
2. 件数は対象の大きさや指摘の重複に左右されるため、重要度、再発、未解決、レビュー範囲などと合わせて解釈する
3. 指摘が0件なら、レビューは必ず失敗である
4. 指摘件数は記録してはならない

問題41

レビューで「管理者は削除できる」と「削除したデータは復元可能である」が見つかったが、復元の期限と権限が記載されていない。最も適切な対応を選びなさい。

1. テストケースで任意の期限と権限を決める
2. 削除・復元の状態、期限、権限、監査記録、失敗時の結果を要求の所有者に確認し、指摘として追跡する
3. 復元機能のテストを省略する
4. 削除要求だけを残し、復元要求を削除する

問題42

大規模なレビューで、作成者が説明し、参加者がその場で全文を初めて読む方式になっている。改善として最も適切なものを選びなさい。

1. 参加者へ事前に対象と観点を配布し、個別準備の後に会議では論点・欠陥・解決方針を扱う
2. 作成者が読む速度を上げ、参加者の準備は不要にする
3. 参加者を増やせば、個別準備なしでも品質が保証される
4. 会議で見つかった問題は記録せず、口頭で解決する

問題43

レビューで要求の矛盾を発見し修正した。実装後のテストとの関係について、最も適切な説明を選びなさい。

1. レビューで修正した要求は、実装が正しいことも保証する
2. レビューは静的成果物の問題を早期に見つけ、動的テストは実装された振る舞いを確認するため、両者を組み合わせる
3. 動的テストを行えば、要求レビューは不要である
4. レビューで問題が見つからなければ、欠陥は存在しない

問題44

公共料金の請求機能について、要件レビューで次の成果物が提示された。

• 要件：「利用者は正しい請求額を簡単に確認できること」
• ユースケース：正常な請求確認の手順はあるが、請求データがない場合と権限がない場合のフローがない
• ユーザーストーリー：受け入れ基準は「問題なく表示されること」の一文だけ
• チェックリスト：一般的なテスト可能性項目はあるが、金額境界と権限の観点がない

限られたレビュー時間で、テストアナリストが最初に行うべき対応として最も適切なものを選びなさい。

1. 画面の文言や色を先に確認し、業務ルールは実装後のテストで決める
2. 請求額の正しさ・利用者の目的・「簡単」の測定基準を明確化し、データなし・権限なしの代替フローと受け入れ基準を追加し、金額境界・権限をチェックリストへ反映して指摘を追跡する
3. 受け入れ基準が曖昧でも、レビュー参加者の経験で合否を決めて完了する
4. 問題が多いため、ユースケースとユーザーストーリーを削除して一つのテストケースにまとめる

問題45

リリース直前のレビューで、管理者権限の要件とユーザーストーリーの受け入れ基準に矛盾が見つかった。作成者は「実装はすでに終わっており、指摘件数も少ないので問題ない」と主張している。レビュー責任者が取るべき対応として、最も適切なものを選びなさい。

1. 実装が完成しているため、テストアナリストが一方の解釈を採用してレビューをクローズする
2. 指摘を削除し、動的テストで通った方の仕様を正式なものとする
3. 矛盾の内容・影響・未解決状態を記録し、要求の所有者と業務責任者に解決を依頼する。解決後は影響を受ける受け入れ基準・テストを再レビューする
4. 指摘件数が少ないので、レビュー品質は十分と判断してリリースする

問題46

医療予約システムの要件レビューで、ユースケースには「予約を登録する」基本フローだけが記載され、ユーザーストーリーの受け入れ基準には正常系の画面メッセージだけがある。過去には重複予約と権限誤りが多発していた。レビューで最も適切な指摘・提案を選びなさい。

1. 基本フローがあるのでレビューを終了し、異常系は実装者に任せる
2. 代替・例外フロー、同時操作、権限、状態遷移を追加し、受け入れ基準を観測可能な結果へ具体化する
3. 過去欠陥は実装の問題なので、要件レビューのチェックリストから除外する
4. 画面メッセージを増やすだけで、予約状態や権限の条件は変更しない

問題47

1 つの要求を、ユースケース、ユーザーストーリー、受け入れ基準、デシジョンテーブルへ展開してレビューすることになった。各成果物で同じ用語が使われているが、ユースケースの「承認者不在」とデシジョンテーブルの「承認拒否」が同じルールとして扱われている。最も適切なレビュー方針を選びなさい。

1. 成果物の形式が違うので、同じ要求との対応は確認しない
2. デシジョンテーブルを正とし、ユースケースとストーリーを削除する
3. 受け入れ基準だけ確認し、フローと条件の差は実装後に判断する
4. 用語・識別子・トレーサビリティを照合し、異なる事象の条件・アクション・期待結果を分離して、関係者と合意する

問題48

レビューの有効性を「発見した指摘件数」で評価している。あるチームでは、指摘件数は多いが、重複や表記ゆれが多く、重大な権限漏れはリリース後に発見された。改善として最も適切なものを選びなさい。

1. 指摘の重大度・種類・再発・見逃し・修正状況などを組み合わせ、レビュー目的とリスクに照らして評価する
2. 指摘件数の目標をさらに高くし、同じ指摘を複数件として記録する
3. 指摘件数が多いレビューは必ず成功とみなし、リリース後の欠陥は評価しない
4. 指摘を減らすため、権限要件のレビューを対象外にする

問題49

安全機能の要求に「危険状態を速やかに回避する」とあるが、危険状態、許容時間、検出条件、解除後の状態、証跡の保存期間が定義されていない。レビューでテストアナリストが最も優先すべき対応を選びなさい。

1. 安全要求なのでテストアナリストが経験から数値を決めて要求を確定する
2. 実装が先に進んでいるため、記載不足はテストケースの注記だけで済ませる
3. 危険状態、時間、遷移、解除、証跡を測定可能な受け入れ条件にするよう専門家・責任者へ照会し、解決前の残余リスクを記録する
4. 画面表示のテストを増やせば、安全要求の曖昧さも補える

問題50

リリース直前の大規模レビューで、作成者が本文を読み上げ、参加者がその場で初めて確認している。重要なアクセス制御の要求に未解決の指摘があるが、予定された時間は終了した。レビュー責任者の対応として最も適切なものを選びなさい。

1. 時間内に読み上げたので、未解決の指摘は次回リリースへ自動的に繰り越す
2. 作成者の説明を信頼し、参加者の指摘をレビュー後に削除する
3. 予定時間を守るため、アクセス制御の指摘をテスト実行の課題へ移してレビューを完了する
4. 未解決指摘の影響・所有者・期限を記録し、必要ならレビューを再計画またはエスカレーションし、解決後に該当成果物とテストを再確認する