Advanced Level テストマネジメント（AL TM）模擬試験 セット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　顧客とユーザー：要件定義の鍵を握り、UATに参加することが望ましい
2. B　プロダクトオーナー：必要な品質レベルを定義し、必要なカバレッジを推奨する
3. C　運用チーム：運用受け入れテストに従事し、非機能要件の定義に貢献する
4. D　開発担当者：システムの本稼働への準備を確実にし、UATの合否を判定する

1. A　シーケンシャルなフェーズ管理に一本化し、アジャイルチームのテスト活動もフェーズ終了時のレビューで管理する
2. B　スプリント内のテスト活動はチームの自己組織化に委ね、テストマネージャーはリリース前の品質ゲートの判定のみを追跡する
3. C　テスト担当者向けのスクラムオブスクラムなどの協調的な取り組みに参加し、全体の開発目的に貢献しつつテストへの集中を維持する
4. D　移行期の混乱を避けるため、チームの理解と能力の評価は移行完了後に行い、まずは新しい方法論への全面的な切替えを最優先にする

1. A　システムテストはスプリントとは別の専任チームが並行して行い、各スプリントのストーリーテストとは切り離して管理する
2. B　システムテストをイテレーティブなストーリーテストと統合し、独立したフェーズを避けて継続的かつ統合的に行う
3. C　すべてのスプリントの完了後に、リリース前の独立したシステムテストフェーズを設けてまとめて実施する
4. D　システムテストはコンポーネントテストの自動化で代替し、品質の確認はスプリントレビューのデモで行う

1. A　リスクと開発状況に応じて優先度を調整し、ツールと環境がCI/CDに統合され継続的テストと即時フィードバックを促進しているかを監視する
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　横型探索で、各リスクに少なくとも1つのテストを最優先で割り当て、プロダクト品質の全体像を早期に把握する
2. B　縦型探索で、カバーするリスクレベルの高い順に厳格に実行し、最も高いリスクをできるだけ早く軽減する
3. C　実行時間の短いテストから順に実行し、残り2週間で実行できるテストケースの数を最大にする
4. D　テストケースを作成した順に実行し、計画との差異が生じないことでスケジュールを守りやすくする

1. A　検出した欠陥の総数と重要度の分布を示し、残っているリスクとの関連付けは次のリリースの計画で行うことにする
2. B　実行済みと未実行のテストケースの一覧を詳細に添付し、リリースしてよいかどうかの最終判断はステークホルダーに委ねる
3. C　合格率85%を中心に報告し、目標の90%に達するまでテスト期間を延長することだけを判断材料として提案する
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/Bテストを中心としたユーザー受け入れテストで、使用性と新規契約の可能性の向上に焦点を当てる
4. D　機能的なユーザー要求に基づくテストケースで、患者の健康に対するリスクに焦点を当てた集中的なUATを重視する

1. A　安全関連規格に基づいて必須のカバレッジを定義し、ユーザー受け入れテストの結果を詳細に文書化する
2. B　A/Bテストを取り入れ、使用性と新規契約の可能性に焦点を当てたユーザー受け入れテストを計画する
3. C　静的コード解析とコードレビューでテストを置き換えることとし、ユーザー受け入れテストは省略して進める
4. D　機能的なユーザー要求に基づいたテストケースを用いて、安全上のリスクに焦点を当てた集中的なUATを行う

1. A　リグレッションテストの自動化率を、次のリリース（6か月後）までに40%から70%に向上させる
2. B　リグレッションテストの自動化率を、自動化ツールの導入によって大幅に向上させる
3. C　リグレッションテストの自動化率を、期限は設けずに100%に到達するまで段階的に向上させ続ける
4. D　リグレッションテストの自動化率を、チームの体制が整い次第、できる限り早い時期に大きく向上させる

1. A　施行日の1か月前までに、法改正で変更された計算ルールに対応するテスト条件を100%カバーする
2. B　施行日の1か月前までに、過去3回分の給与データを用いた新旧比較テストをすべて実施する
3. C　施行日の1か月前までに、全画面のレスポンシブ対応について使用性テストを100%実施する
4. D　施行日の2週間前までに、給与計算バッチ処理に関する重要度「高」の未解決欠陥を0件にする

1. A　M（測定可能な）：短縮の度合いを示す数値目標や現状値がなく、達成したかどうかを判定できない
2. B　T（タイムリーな）：完了の期限が明示されておらず、いつまでに達成すべき目標なのかが分からない
3. C　A（達成可能な）：実行時間の短縮はどのようなリソースを使っても実現できない目標である
4. D　S（具体的な）：対象が特定されておらず、どのテストの何を改善するのかが分からない

1. A　外部の最良の実践例と自チームの手順を比較し、差異のある手順を最良の実践例に置き換えていく
2. B　分析的アプローチとして、欠陥データに基づいて根本原因分析を行い、流出の原因に対する改善策を導く
3. C　モデルベースのアプローチとして、TPI NEXT®のキーエリアをチェックポイントで評価し成熟度を示す
4. D　モデルベースのアプローチとして、TMMi®の成熟度レベルに照らして組織全体のプロセスを評価する

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　非経常的なコストが低いYのほうが、3年間の総コストが低く、導入のリスクも小さいといえる
2. B　3年間の総コストはXが700万円、Yが810万円だが、利益が同じなのでROIはどちらも等しくなる
3. C　Yはライセンス料がかからないため、3年間の総コストもYのほうが低く、ROIもYのほうが高い
4. D　3年間の総コストはXが700万円、Yが810万円であり、Xのほうが総コストが低く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. A　コードカバレッジ：テストケースによってカバーしている要件やユーザーストーリーの割合
2. B　プロダクトリスクのカバレッジ：識別したリスクのうちテストケースで軽減した割合
3. C　プロダクトリスクのカバレッジ：テストしていないコンポーネントに欠陥がある場合の潜在的な影響
4. D　要件カバレッジ：テストケースによって実行されたコードのステートメントやブランチの割合

1. A　テスト環境の障害はテストチームの管理外なので、欠陥の検出数の推移だけを品質の傾向として報告する
2. B　テストあたりの検出数はむしろ増えており、検出数の減少を品質の向上とは解釈できないと報告する
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　三点見積り
2. B　比率に基づく見積り
3. C　外挿
4. D　プランニングポーカー

1. A　最可能値の合計の29人日を見積りとし、楽観値と悲観値は前提条件として注記するだけにとどめる
2. B　3つの値の単純平均の合計の35人日を見積りとし、不確実性はリスク一覧で別に管理すると伝える
3. C　見積り不足を避けるため悲観値の合計の58人日を見積りとし、不確実性はないものとして報告する
4. D　三点見積りで期待値の合計を32人日とし、各タスクの標準偏差（2と約4.7）も示す

1. A　作業範囲の前提を全員で議論してそろえた後、各専門家が再び個別に見積り、合意に至るまで繰り返す
2. B　見積り不足のリスクを避けるため、最も大きい15人日を採用し、他の専門家の値は参考として記録する
3. C　4人の値の平均である8人日を採用し、ばらつきは前提条件として文書化して見積りを確定する
4. D　多数派の値である6人日を採用し、互換性テストの扱いは見積りの確定後に別途検討することにする

1. A　責任の所在を明確にするため、連続する欠陥ステータスはすべて同じ役割に割り当てる
2. B　終端ステータスは1つ（例：クローズ）とし、遷移時に終結の理由を選べるようにする
3. C　後の分析に備え、ステータス遷移のたびにできるだけ多くの属性の入力を必須にする
4. D　終端ステータスを「修正済み」「重複」「却下」のように複数用意し、終結の理由ごとに使い分ける

1. A　終端ステータスをクローズの1つにして遷移時に終結の理由を選ばせ、クローズへの遷移は別の役割が行う
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　必要レベルと同じであるリスクベースドテストを最優先とし、全員がレベル3になるよう研修を行う
2. B　未達のテスト自動化を優先し、Cさんを中心にトレーニングやOJTでレベル3を目指す
3. C　最高レベルが3に達している性能テストと業務ドメイン知識を、チームの強みとしてさらに伸ばす
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　外部失敗コストは市場の状況に左右され管理できないため、残りの3つのカテゴリーだけを削減の対象にする

1. A　規制対象の機能に関する法的責任からの保護
2. B　リリース時点で既知の欠陥についての情報
3. C　テストによるプロダクトリスクのレベルの低減
4. D　今回のリリース前に発見し、修正した欠陥

1. A　経営層の判断を尊重してテストを一律に半分にし、見逃した欠陥はリリース後の修正で対応すると説明する
2. B　定量的な利点（平均節約額など）と定性的な利点（法的責任からの保護など）を示し、リスクに応じて配分する
3. C　テストは多いほど品質が上がるため、費用に関係なくすべての領域でテストを増やすべきだと説明する
4. D　実行したテストケースの数と作業時間の実績を詳しく示し、テストチームが効率よく働いていることを説明する