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

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　採用するSDLCや開発手法を選定し、それに合わせて開発チームとテストチームの体制を決定すること

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　テストはプロダクトリスクの軽減にのみ関係するため、テストマネージャーはプロジェクトリスクマネジメントには関与しない
3. C　テストで欠陥が見つからなかった場合は、そのテストがプロダクトリスクの軽減に役立たなかったことを意味する
4. D　欠陥が見つかればリスクレベルが予想より低いことを示し、見つからなければテストの有効性を見直す必要がある

1. A　重大なリスクを効率よく識別するには、参加者をドメインと技術の少数の専門家に絞り、ステークホルダー全体へのヒアリングは省略するのが最もよい
2. B　一般的な疑問や参照ドキュメントの問題、プロジェクトリスクなど、プロダクトリスク以外の課題事項も副産物として識別されることが多い
3. C　リスクはテスト対象内にほぼ一様に分布するため、識別したリスクは機能ごとに均等な重みで扱い、テストの労力も均等に配分する
4. D　識別されたリスクのうち、プロジェクトリスクがリスクベースドテストの主要な焦点となり、テストの優先度と労力の配分を決める

1. A　地理的に分散したチーム
2. B　組織の成熟度
3. C　適切な回避策の欠如
4. D　テストベースの変更率が高い

1. A　横型探索（breadth-first）：各リスクに少なくとも1つのテストを最優先で割り当て、残りはリスクレベルで優先順位を付ける
2. B　要件ベースの優先順位付け：要件仕様の記載順にテストを実行し、すべての要件を漏れなく順番にカバーしてから全体を評価する
3. C　縦型探索（depth-first）：カバーするリスクレベルの高い順に厳格に降順で実行し、最も高いリスクをできるだけ早い段階で軽減する
4. D　コストベースの優先順位付け：実行時間が短く低コストのテストから実行し、実行済みテストの件数を早い段階で増やして進捗を示す

1. A　規格の要求事項への適合は認証機関が確認するため、テスト完了後に監査対応として証跡をまとめればよい
2. B　規格がインテグリティレベルに基づきテスト技法と必須のカバレッジを規定している場合があり、それらの遵守を保証する
3. C　規格がテスト技法とカバレッジを規定しているため、プロジェクト固有のリスク分析は省略して規格の要求事項だけに従ってテストする
4. D　安全関連規格は開発プロセスを対象とするため、テストでは通常のリスクベースドテストの手順をそのまま適用する

1. A　フォールトツリー解析
2. B　ハザード分析
3. C　FMEA
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四半期末までに優先度の高い要件の100%をテストで確認し、重要度「高」の未解決欠陥を0件にする
3. C　テスト自動化を継続的に推進し、いずれはリグレッションテストの自動化率を十分な水準まで引き上げる
4. D　テストケースを十分に実行し、重要度の高い欠陥をできる限り減らして、品質に問題がない状態でリリースする

1. A　診断 → 開始 → 行動 → 確立 → 学習
2. B　開始 → 診断 → 確立 → 行動 → 学習
3. C　確立 → 開始 → 診断 → 行動 → 学習
4. D　開始 → 確立 → 診断 → 学習 → 行動

1. A　参加者の意見や経験などの定性的な情報のみを用い、定量的なメトリクスは改善の判断に使わない
2. B　プロジェクトやチーム自体のデータから問題を識別し、根本原因分析、メトリクスを用いた分析、GQMアプローチなどを用いる
3. C　TMMi®やTPI NEXT®などのモデルに示された外部の最良の実践例と比較し、そのギャップから改善策を導き出す
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　経営幹部：使用性／ツールを使う人：保守性／運用スタッフ：ROI
2. B　経営幹部・ツールを使う人・運用スタッフのいずれも、プラスのROIを最も重視する
3. C　経営幹部：保守性／ツールを使う人：ROI／運用スタッフ：使用性
4. D　経営幹部：プラスのROI／ツールを使う人：使用性／運用スタッフ：保守性

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人あたりの実行テストケース数と、計画に対するテスト実行件数の日ごとの推移

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　不合格になった原因はテストケースの誤りであるため、テストケースを修正して合格させる
3. C　コンポーネントの開発中であっても、自動テストの不合格はすべて欠陥レポートとして記録し追跡する
4. D　このようなテスト結果は欠陥が原因とは限らず、通常は欠陥レポートで追跡しない

1. A　欠陥マネジメントツールの代わりに会議で欠陥の状況をすべて管理し、議事録を正式な記録として扱う
2. B　欠陥レポートの有効性を判断し、修正・却下・延期を決める。修正する場合は他のタスクに対する優先度を設定する
3. C　テスト担当者から報告された欠陥を委員会メンバーが分担して修正し、修正内容をレビューして承認する
4. D　欠陥レポートの記述品質を評価し、報告したテスト担当者ごとの評価点を算出して人事評価に反映する

1. A　開発者がその場ですぐに修正できる軽微な欠陥
2. B　他のスプリント活動をブロックし、チーム内ですぐに修正できない欠陥
3. C　同じイテレーション内で解決できない欠陥
4. D　サプライヤーが解決しなければならない欠陥

1. A　タイトルと簡単な概要、再現手順を含む不正の詳細な説明、重要度、優先度
2. B　影響を受けた品質特性、欠陥が混入した作業成果物、混入したSDLCフェーズ
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　ピアラーニング
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　評判の向上、スムーズで予測可能なリリース、法的責任からの保護