Advanced Level テストマネジメント（AL TM）模擬試験 セットCの問題と解説

1. A　すべてのステークホルダーに受け入れられる必要があるため、意見の相違を解決してから計画を確定する
2. B　プロダクトオーナーの意見を優先して計画を確定し、開発リーダーには確定後の計画書を配布する
3. C　意見の相違はテスト実行の結果を見れば解消するため、テストモニタリングの段階で改めて扱う
4. D　テストの専門家として、テストマネージャーが判断を下し、相違は記録として残したうえで計画を確定する

1. A　テストケースの実行件数と欠陥件数の推移を中心に構成し、詳細な目標値の設定は報告の柔軟性を損なうため避ける
2. B　テストチーム内部の進捗管理を目的とする枠組みであり、ステークホルダーへの状況報告には別途テスト完了レポートを用いる
3. C　テスト完了時に終了基準の達成度を評価する尺度として確立し、テスト実行中の状況把握には個々のテストログやテスト担当者の報告を用いる
4. D　作業成果物やリソースの状況を計画書や戦略の目的に関連付ける詳細な尺度と目標値を含み、ステークホルダーに分かりやすく伝える

1. A　終了基準に基づいてテスト完了の承認を行い、あわせて必要な関係者からの承認を得る
2. B　終了基準を満たしていても、検出した欠陥がすべて修正されるまではテスト完了を判断しない
3. C　終了基準の達成状況の判断はテスト担当者に任せ、テストマネージャーは結果の報告だけを受ける
4. D　終了基準を満たしたので承認の手続きは省き、テストウェアの保管とテスト環境の削除を始める

1. A　プロジェクトマネージャー・プロダクトオーナー・ビジネスユーザー
2. B　顧客とユーザー
3. C　開発担当者・開発リーダー
4. D　運用チーム

1. A　経理部長＝無関心者：重要なマイルストーンでのみ報告する／リーダー＝推進者：テスト計画の形成に主要協力者として日常的に参加させる
2. B　経理部長＝潜在的協力者：リソースや方向性の意思決定で関与を求める／リーダー＝擁護者：定期的な報告と議論への関与で関心を維持する
3. C　経理部長＝推進者：テスト戦略の形成に日常的に参加させる／リーダー＝無関心者：重要なマイルストーンでのみ報告して関心の低下を防ぐ
4. D　経理部長＝擁護者：定性的なフィードバックの提供を定期的に求める／リーダー＝潜在的協力者：リソース配置に関する意思決定を依頼していく

1. A　テストマネージャーが意思決定とチームマネジメントを統括し、各役割を明確に分ける
2. B　受け入れ基準と完了の定義に重点を置き、イテレーションごとのストーリープランニングで見積る
3. C　テストレベルごとに早い段階で詳細な見積りを行い、それをベースラインとして変更を管理していく
4. D　マイルストーンごとにテスト進捗報告書を作成し、それを主要な報告の手段として用いる

1. A　開発チームと協力し、コンポーネントの統合順序とテストの組み合わせを決める
2. B　UATで挙がった課題事項について、関係者と協力してその解決を促進する
3. C　スコープと目的をリスクアセスメントや品質目標と整合させ、進捗と課題事項を監督する
4. D　テスト担当者をコードレビューなど従来の役割を超えた活動に参加させる

1. A　テストの重複を防ぐため、チームをまたぐ機能のテストはすべて外部ベンダーのシーケンシャルな工程に任せる
2. B　スクラムチームのテスト担当者を外部ベンダーの工程に合わせた1つのテストチームへ集約し、スプリントでのテストをやめる
3. C　各チームの自律性を尊重してチーム間の調整は行わず、重複や漏れはリリース直前の総合テストでまとめて解消する
4. D　テスト担当者向けのスクラムオブスクラムのような協調の場に参加し、スプリント内のテスト活動を追跡・レビューする

1. A　テスト実行率や欠陥率などの従来のメトリクスはやめ、ベロシティだけでチームの日々のテストの状況を報告するようにする
2. B　報告の手間を減らすため、テストの状況はスプリントの終了時にまとめて報告し、途中の報告はやめるようにする
3. C　ダッシュボードとデイリーステータスアップデートで継続的に報告し、ベロシティやバーンダウンチャートも併用する
4. D　週次の報告書をより詳細にし、テストレベルごとの終了時点でマイルストーンベースの報告書も追加で作成する

1. A　テスト分析：リスクに基づく優先順位付けが実行順序を決める／テスト実行：リスクレベルがテスト条件の選択の指針になる
2. B　テスト計画：リスクレベルが実行順序を決める／テスト実行：リスク分析の結果が適用するテスト技法を選択する指針になる
3. C　テスト分析：リスクレベルがテスト条件の選択の指針になる／テスト実行：リスクに基づく優先順位付けが実行順序を決める
4. D　テスト設計：リスクレベルがテスト条件の選択の指針になる／テスト完了：リスクに基づく優先順位付けが報告の順序を決める

1. A　定性的アセスメントでも、順序尺度の各段階に数値を割り当ててその積を求めれば、リスクレベルを損失の金額として客観的に扱える
2. B　統計的に有効なデータがあれば定量的に評価できるが、通常は順序尺度による定性的な把握となり、リスクレベルは相対評価として解釈する
3. C　客観性を確保するため、リスク分析はリスク可能性をパーセンテージ、リスク影響を金額で表す定量的アセスメントを基本として行うべきである
4. D　リスクマトリクスで組み合わせたリスクレベルは絶対的な尺度として扱い、異なるプロジェクト間の比較にも使える

1. A　保守性：受け入れテストでの保守作業のシミュレーション／セキュリティ：受け入れテストでの動的テスト
2. B　保守性：統合したシステムの動的テスト／セキュリティ：アーキテクチャのレビューと静的解析の組み合わせ
3. C　保守性：静的解析とコードレビュー／セキュリティ：アーキテクチャのレビューと統合したシステムの動的テストの組み合わせ
4. D　保守性：コードレビュー／セキュリティ：テストでは軽減できないためリスク移転し、委託先との契約で責任の範囲を明確にする

1. A　公平になるよう全機能を5名で均等に分担し、どの機能にも同じテスト技法と同じ厳格さを一律に適用してテストを進める
2. B　料金計算は経験豊富な担当者が早期から厳密な技法でテストし、帳票のレイアウトは後半に厳密でない技法でテストする
3. C　育成を優先して料金計算は配属されたばかりの担当者に任せ、経験豊富な担当者は帳票のレイアウトをレビューする
4. D　帳票のレイアウトは利用者の目に付きやすいため、経験豊富な担当者が最初に集中的にテストし、料金計算は後に回す

1. A　リスク1：コンティンジェンシープラン／リスク2：リスク受容
2. B　リスク1：リスク移転／リスク2：リスク受容
3. C　リスク1：リスク受容／リスク2：テストによる軽減
4. D　リスク1：テストによる軽減／リスク2：コンティンジェンシープラン

1. A　軽量的な技法ではステークホルダーは関与しないため、テストマネージャーが単独でリスクを分析する
2. B　PRAMやPRISMAは候補になるが、SSTは要件仕様がある場合にのみ使えるため候補から外す
3. C　軽量的な技法はどれも要件仕様を前提としているため、この状況では重量的な技法のFMEAを使う
4. D　SSTは要件仕様を必要としない軽量的な技法なので、この状況に最も適した候補として選択する

1. A　デジャブ：リスク識別の参加者を少数に絞り、重要なリスクのみを軽減する
2. B　リスクレベルのアセスメントが困難：過去のデータだけを使ってリスクレベルを決め直す
3. C　ステークホルダーの変化：リスク分析を継続的でイテレーティブなものにする
4. D　重要なリスクの見逃し：当初のリスク分析を維持したまま新任者を教育する

1. A　受け入れテストは顧客が行うため契約の受け入れ基準は考慮せず、リスクベースドテストを厳格に使って優先順位を決める
2. B　契約の受け入れ基準をカバーするテストを確実に含めたうえで、リスクベースドテストを厳格に使って優先順位を決める
3. C　予算と納期を守るため、受け入れ基準のテストは顧客の受け入れテストに任せ、探索的テストだけで進める
4. D　契約の受け入れ基準をカバーするテストを含めたうえで、残りのテストはすべて均等に実行するように計画する

1. A　連携先のチームとテストを調整してシステム統合テストを設け、テストデータは個人情報を含む本番データをそのまま使って用意する
2. B　連携部分はスタブで代替してシステム統合テストは設けないこととし、テストデータは本番データを匿名化して用意する
3. C　連携先のチームとテストを調整してシステム統合テストのレベルを設け、テストデータは本番データを匿名化して用意する
4. D　連携先は他社や他チームの責任範囲なので統合テストは本番稼働後に行い、テストデータは本番データをそのまま使う

1. A　T（タイムリーな）：完了の期限が定められておらず、具体的な時間枠が不明確である
2. B　M（測定可能な）：数値化された目標がなく、進捗を判定する基準がない
3. C　A（達成可能な）：リソースの可用性と時間枠を考えると、実現可能とはいえない
4. D　S（具体的な）：対象が特定されておらず、何を改善するのかが曖昧である

1. A　判定日（6月30日）時点で、品質が十分に高まったとステークホルダーの多くが感じられる状態になっていること
2. B　判定日（6月30日）時点で、重要度「高」の未解決欠陥が0件、かつ優先度「高」の要件のテスト実行率が100%であること
3. C　重要度「高」の未解決欠陥が0件、かつ優先度「高」の要件のテスト実行率が100%の状態を、テストを続けながらいずれ達成すること
4. D　判定日（6月30日）時点で、すべての要件について、あらゆる入力値の組み合わせのテストを実行し終えていること

1. A　16のキーエリアごとに4つの成熟度レベルがあり、チェックポイントで評価した結果を成熟度マトリクスで可視化する
2. B　プロジェクト固有のデータから問題を識別する分析的アプローチであり、根本原因分析やGQMと組み合わせて使う
3. C　当初CMMI®を補完するために開発されたモデルで、組織のテストプロセスの成熟度を段階的な5つのレベルとして評価する
4. D　5つの成熟度レベルで構成され、レベル1を除く各レベルにテストプロセス領域と改善ゴールが定義されている

1. A　データの収集：集めた意見を分析してアイデアを出す／改善アクションの決定：ふりかえり自体をレビューする
2. B　改善アクションの決定：定性・定量データを集める／クロージング：ふりかえりのゴールと課題を確認する
3. C　改善策の導出：集めた意見を分析してアイデアを出す／クロージング：ふりかえり自体をレビューする
4. D　イントロダクション：改善アクションの責任者を決める／データの収集：改善アクションに優先順位を付ける

1. A　ふりかえりはアジャイル開発で各イテレーションの終わりに行う活動なので、このプロジェクトでは実施しないでおく
2. B　テスト完了の一部として実施し、見積りと実績の差異などの定量データと参加者の意見を集めて改善アクションを導く
3. C　見積りの差異の責任を明確にするため、最初に遅延の原因となったテスト担当者を特定するところから話し合いを始める
4. D　定量データは人によって解釈が分かれるので使わないこととし、参加者の感想だけを集めて改善アクションを決める

1. A　小規模なパイロットプロジェクトで試行し、得られた知見を展開の計画に反映する
2. B　ツールの使用に関するガイドラインを定め、トレーニングやコーチングを提供する
3. C　ツールの効果を早く得るため、既存のプロセスは変えずに、全部門へ同時に一斉展開する
4. D　ツールのオーナーを定義し、実際の使用状況から情報を継続的に収集する方法を実装する

1. A　b、d、f
2. B　b、c、f
3. C　a、c、e
4. D　b、e、f

1. A　ツールの利益は通常は予想を上回るので、評価期間のコストや保守ポリシーの変更は分析の対象から外しておく
2. B　保守ポリシーは導入後に確認すれば足りるので、現時点ではライセンス料と初期トレーニング費用の2つだけで比較する
3. C　機会コストは会計上の費用として計上されないので、組織の成熟度とあわせて分析の対象から外して判断する
4. D　組織の未熟さによる非効率な使用と、保守ポリシー変更による作業増のリスク、評価期間の機会コストを分析に含める

1. A　a：プロダクトメトリクス、b：プロジェクトメトリクス、c：プロセスメトリクス
2. B　a：プロセスメトリクス、b：プロダクトメトリクス、c：プロジェクトメトリクス
3. C　a：プロジェクトメトリクス、b：プロセスメトリクス、c：プロダクトメトリクス
4. D　a：プロジェクトメトリクス、b：プロダクトメトリクス、c：プロセスメトリクス

1. A　基準1は満たしているが、基準2は満たしていない
2. B　基準2は満たしているが、基準1は満たしていない
3. C　基準1・基準2ともに満たしている
4. D　基準1・基準2ともに満たしていない

1. A　テスト環境の提供が遅れたため、それを考慮してテストスケジュールを調整する
2. B　識別していたプロダクトリスクが課題事項となったため、残りのテストの優先順位を付け直す
3. C　メトリクスで計画からの逸脱が分かっても、合意済みの計画を守るため実行順序を維持する
4. D　手戻りが発生したため、該当するテストの開始基準と終了基準を評価し直す

1. A　テスト担当者ごとの作業時間と実行テストケース数など、テストチームの生産性に関する指標
2. B　コンポーネント間のインターフェースカバレッジと、統合されたモジュールの呼び出し経路の網羅率
3. C　要件、ユースケース、ユーザーストーリー、プロダクトリスクなどのテストベースのカバレッジとリスクごとの結果
4. D　ステートメントカバレッジやブランチカバレッジなど、コードに対する構造カバレッジの達成率

1. A　構造カバレッジが100%に達しているため、コードは十分にテストされリリース可能な品質だと報告する
2. B　高リスクのうち8件が不合格または未完了であることを示し、その残存リスクを判断材料として報告する
3. C　要件カバレッジが終了基準を満たしたことを中心に報告し、リスクの状況は詳細資料として添付する
4. D　すべての高リスクのテストが合格するまでは判断材料にならないため、報告そのものを延期すると伝える

1. A　モジュールごとのステートメントカバレッジとブランチカバレッジの一覧に、静的解析の指摘件数を添える
2. B　テスト担当者ごとの実行件数と作業時間の推移を示し、計画に対するチームの生産性の高さを説明する
3. C　未解決の欠陥レポートを重要度順にすべて並べ、各欠陥の再現手順と原因の調査状況を一件ずつ説明する
4. D　プロダクトリスクごとの結果と終了基準の達成状況を傾向とともに要約し、残存リスクを示す

1. A　テストベースの品質は開発側の問題なので、見積りは変えずに曖昧な記述の修正だけを開発側に依頼する
2. B　判明した要因を反映して見積りを更新し、前提条件と根拠を添えてプロジェクトマネジメントに示す
3. C　承認済みの見積りはベースラインなので変更せず、影響はチームの残業とリスクの許容で吸収する
4. D　人員が増えて作業を分担できるため、テスト工数は当初の見積りより少なくなると想定して報告する

1. A　アジャイルチームがスプリントのストーリーをチームの判断で手早く見積る：プランニングポーカー
2. B　今回のプロジェクトの初期の実測値がそろい、数式で残りを予測したい：ワイドバンドデルファイ
3. C　見積りのばらつきを標準偏差で示したいが、専門家の推定値は得られない：三点見積り
4. D　過去データがなく複雑度の高い新規開発で、専門家の間で合意を形成したい：外挿

1. A　1回目のベロシティ15を慎重な値として使い、13回とする
2. B　直近3回の平均ベロシティ23で外挿し、8回とする
3. C　他のチームの平均ベロシティ30で外挿し、7回とする
4. D　4回すべての平均ベロシティ21で外挿し、9回とする

1. A　過去データに基づき、比率に基づく見積りなどのメトリクスベースの技法を使う
2. B　三点見積りで、専門家から楽観値・悲観値・最可能値を集めて期待値を求める
3. C　プランニングポーカーで、チーム全員がカードを使って同時に見積りを提示する
4. D　ワイドバンドデルファイで、複数の専門家の個別見積りを繰り返して合意を形成する

1. A　ソフトウェアに欠陥がないため欠陥レポートを削除し、テストケースの期待結果だけを修正する
2. B　開発担当者が解決に遷移させ、テスト担当者が再現手順にしたがって確認テストを行ってクローズにする
3. C　仕様の確認が済むまでの扱いとして、欠陥レポートを進行中のまま残し、次のリリースで再評価する
4. D　開発担当者が理由（誤ったテスト）を付けて却下し、テスト担当者が却下を受け入れてクローズにする

1. A　修正する場合は、修正の利点・リスク・コストを検討したうえで他のタスクに対する優先度を設定する
2. B　委員会で十分に議論していれば、欠陥マネジメントツールへの記録は省略してかまわない
3. C　欠陥レポートが有効な欠陥かを判断し、修正するか、却下するか、延期するかを決定する
4. D　テストマネージャー、開発の代表者、プロダクトオーナーなどを含む機能横断的なチームで構成する

1. A　形式化のレベルや欠陥レポートを作成するトリガーは、組織的テスト戦略で全チーム共通に固定する
2. B　欠陥はユーザーストーリーとは別の欠陥リストで管理し、プロダクトバックログとは独立に優先順位を付ける
3. C　欠陥の扱いに関するチームの合意事項は、柔軟に見直せるよう文書化せずに口頭で共有するのが望ましい
4. D　同じイテレーション内で解決できない欠陥はプロダクトバックログに追加し、他の項目と合わせて優先順位を付ける

1. A　月1回のミーティングの時間を延ばし、サプライヤー側のテストマネージャーだけで優先順位を決める
2. B　ツール間の同期をできれば自動で確立し、プロダクトオーナーを交えて短く頻繁に会議を開く
3. C　サプライヤー側の開発モデルに合わせ、顧客側のスプリントでも欠陥の修正は月1回にまとめて行う
4. D　欠陥の状況は各チームのツールで管理し、それぞれのチームが別々のプロジェクト計画書で進める

1. A　作成の負担を減らすため、フェーズの情報は省略し、タイトル・重要度・優先度だけを記録の対象とする
2. B　分析に使える可能性がある項目をすべて入力必須とし、性能の欠陥にも機能の欠陥と同じ項目を使う
3. C　混入・検出のフェーズを含む核の項目を全プロジェクトで統一し、性能の欠陥には負荷条件などを足す
4. D　プロジェクトごとの事情を優先し、核となる項目も各プロジェクトで自由に定義して後から変換して集計する

1. A　テスト技法のスキル、技術やビジネスの専門知識、プロジェクトマネジメントスキル
2. B　セルフマネジメント能力、責任感、回復力、変化を受け入れる姿勢
3. C　分析力、概念力、判断力、複雑で新しい課題を独自に遂行する力
4. D　コミュニケーションスキル、対立解決スキル、チームワーク、自己主張

1. A　テスト計画で必要な、テスト戦略を策定するための概念的な知識
2. B　テスト分析で必要な、テストベースとプロダクトリスクを分析する分析スキル
3. C　テスト完了で必要な、プロジェクトの成果を伝える能力と決定への責任
4. D　テスト実装・実行で必要な、テストスクリプトのプログラミングなどの技術的専門知識

1. A　同じ役割タイプのメンバーでチームをそろえると対立が減り、チームが最も効果的に機能するとする
2. B　チームの発達段階を形成期・混乱期・統一期・機能期・散会期に分け、各段階で必要なスキルを示す
3. C　異なる役割タイプで構成されたチームが効果的に機能するとし、チームに不足するスキルの識別に役立つ
4. D　メンバーの役割タイプに応じて、担当させるテストレベルやテストタイプを決めるためのモデルである

1. A　対立の解決に関する書籍や動画で自己学習する計画を立て、読了後のレポートで理解度を確認する
2. B　テスト技法の上位資格の取得を目標にし、専門的能力を高めることで開発担当者からの信頼を得させる
3. C　欠陥に関する議論は他のメンバーに任せ、Aの担当を開発担当者と接しないテスト設計作業に限定する
4. D　ロールプレイを含むトレーニングやコーチングを行い、実場面のフィードバックとふりかえりを続ける

1. A　散会期：メンバーのテストチームへの参加を支援する意欲
2. B　形成期：テストチームを離れるメンバーに感謝と信頼を持って接する能力
3. C　機能期：合意された価値観やルールを守らせる規律と目標指向のリーダーシップ
4. D　混乱期：テストチーム内の対立を解決する能力

1. A　メンバーの生産性とパフォーマンスが高まる
2. B　衛生要因が欠けていても不満が生じなくなる
3. C　クロストレーニングが非公式に行われるようになる
4. D　テストマネジメントが外部の課題に時間を割けるようになる

1. A　a：欠陥予防コスト、b：評価コスト、c：外部失敗コスト、d：内部失敗コスト
2. B　a：欠陥予防コスト、b：評価コスト、c：内部失敗コスト、d：外部失敗コスト
3. C　a：欠陥予防コスト、b：内部失敗コスト、c：評価コスト、d：外部失敗コスト
4. D　a：評価コスト、b：欠陥予防コスト、c：外部失敗コスト、d：内部失敗コスト

1. A　テストを増やすほどリスクは確実に下がるため、予算が許す限りテストの労力を増やし続けるのが最適である
2. B　多すぎればコストが利点を上回り、少なすぎれば見逃した欠陥のコストが上回る。最適点はその間にある
3. C　テストは最小限にとどめ、見逃した欠陥はリリース後に修正するほうが通常は全体のコストが低い
4. D　テストの労力はテスト対象の規模から機械的に決め、リスクの大きさによって増減させるべきではない

1. A　案A 38,400ドル、案B 35,800ドルで、案Bのほうが小さい
2. B　案A 38,400ドル、案B 40,800ドルで、案Aのほうが小さい
3. C　案A 32,400ドル、案B 35,800ドルで、案Aのほうが小さい
4. D　案A 21,600ドル、案B 20,200ドルで、案Bのほうが小さい