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

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　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　故障モード影響解析（FMEA）、フォールトツリー解析、ハザード分析、エクスポージャーコスト
3. C　プランニングポーカー、ワイドバンドデルファイ、三点見積り、メトリクスに基づく見積り
4. D　PRAM、PRISMA、体系的ソフトウェアテスト（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　他チームのシステムは各チームの責任範囲なので、自チームのシステムテストで自システムの品質を確保することに集中する
2. B　インターフェースの問題は本番に近い環境でしか再現しないため、システム統合テストは本番稼働後の監視で代替する
3. C　連携先が多いため、インターフェースは他チームのシステムをスタブで代替してテストし、コンポーネントテストの網羅性を高めることを優先する
4. D　他チームやプロジェクトとテストを調整してシステム統合テストに適切なテストレベルを選び、リスクベースドテストで優先順位と規模を調整する

1. A　R（妥当な）：数値化可能で、具体的な進捗基準を持ち、達成度を測れるものでなければならない
2. B　T（タイムリーな）：プロジェクト全体の目的に沿い、その方向性と整合したものでなければならない
3. C　A（達成可能な）：リソースの可用性、時間枠、能力を考慮し、実現可能でなければならない
4. D　M（測定可能な）：明確で曖昧ではなく、誰が読んでも同じ意味に理解できるものでなければならない

1. A　改善の展開後に、計画した利益が得られたかを検証し、次の改善サイクルに向けた教訓をまとめる
2. B　改善の詳細なアクションを列挙したテストプロセス改善計画を作り、改善に優先順位を付ける
3. C　現在のテストプロセスをアセスメントして強みと弱みを把握し、改善の可能性がある領域を特定する
4. D　プロセス改善の目的、ゴール、スコープ、カバレッジをステークホルダーと合意し、改善の体制を整える

1. A　測定ゴールを定義し、ステークホルダーの視点で品質の側面を定義する質問へ洗練し、回答に必要な情報を提供するメトリクスを選ぶ
2. B　ステークホルダーの質問を起点としてゴールとメトリクスを同時に定義し、収集したデータを使って最初の質問自体の妥当性を確認する
3. C　まず利用可能なメトリクスを収集し、その傾向から質問を導き出し、最後に質問への回答に基づいて測定ゴールを設定する
4. D　測定ゴールを定義し、そのゴールを直接表すメトリクスを選択して、質問は収集したデータの分析後に定義する

1. A　15件をすべて記録として残し、次回のふりかえりで全件を改めて再評価してから、実施するかどうかをまとめて判断する
2. B　改善アクションに優先順位を付けて責任者と効果を測るゴール・メトリクスを定め、検証可能なステップで管理できるよう数を絞る
3. C　チームの意欲が高いうちに、15件すべてを次のイテレーションのバックログに追加し、全員で並行して実施する
4. D　テストマネージャーが15件の中から実施するアクションを単独で選び、効果の確認方法や期限も含めて各メンバーに割り当てる

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つを調整して制約に合わせる

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回を長めにする

1. A　欠陥または欠陥の根本原因に対する混入・検出・除去のSDLCフェーズ
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　自己学習（書籍やeラーニングなど）のアプローチ

1. A　基本的なマネジメント能力とテストマネジメントの知識に加え、社会的・個人の能力が不可欠な成功要因である
2. B　計画・モニタリング・報告などの基本的なマネジメント能力があれば、テストマネジメント特有の知識は必要ない
3. C　人材の確保は人事部門の役割であり、テストマネージャーが労働条件やチームの状況を分析する必要はない
4. D　テストの専門知識とマネジメントの能力が十分であれば、社会的能力や個人の能力は成功要因にならない

1. A　衛生要因は意識的に認識される要因であり、満たされることで本人の成長と満足感につながる
2. B　衛生要因を満たすと満足感が大きく高まるため、モチベーション向上策として最も効果的である
3. C　衛生要因は昇進や責任の拡大などを指し、欠けるとモチベーションが下がるが満たせば成長を促す
4. D　当然のものと見なされ、満たしても満足感が増すとは限らないが、欠けるとモチベーションが下がりうる

1. A　品質コストの4分類はテストの効率の評価に使うもので、ビジネスケースには使えない
2. B　外部失敗コストは発生頻度が低いため、通常、評価コストと内部失敗コストの合計より少ない
3. C　評価コストと内部失敗コストの合計は、通常、外部失敗コストより大幅に少ない
4. D　本シラバスの品質コストは、Boehm が提唱したアプローチの分類に基づいている

1. A　4,600ドル
2. B　4,300ドル
3. C　4,700ドル
4. D　5,700ドル