HOME
Lv029

「Lv029」の記事一覧

「インシデントのトリアージ」会議において、主に行う決定はどれか。

リソースと時間が限られる中で、ビジネス上の影響を考慮して対応順を決定する。

2026年1月25日

インシデント管理において「不具合の傾向分析」を行う目的はどれか。

データの蓄積を将来の品質予測や、弱点の補強に活用する。

2026年1月25日

「回帰テスト（リグレッションテスト）」を、不具合修正のたびに実施する目的はどれか。

デグレード（退化）を検知し、品質の安定性を保証するために不可欠な活動。

2026年1月25日

不具合の「ライフサイクル管理」において、最終的に「完了（Closed）」にする権限を持つのは誰か。

修正した本人（開発者）ではなく、客観的に確認した側がクローズするのが原則。

2026年1月25日

不具合の「再テスト（確認テスト）」が失敗（不合格）となるのはどのような状況か。

再テストは「特定の欠陥が除去されたか」のみを確認する活動である。

2026年1月25日

インシデントレポートにおいて、発生した際の「スクリーンショット」や「ログ」を添付する利点はどれか。

百聞は一見に如かずであり、正確な情報提供が修正サイクルを早める。

2026年1月25日

インシデントのステータスが「却下（Rejected）」とされる適切な理由はどれか。

仕様変更や、テスト環境の設定ミスなどが原因であることが多い。

2026年1月25日

不具合報告書（バグ票）において「期待される動作」を記載する目的はどれか。

「実際の動作」との差を明確にすることで、仕様の認識齟齬を防ぐ。

2026年1月25日

不具合の「優先度（Priority）」が「高」で、かつ「重要度（Severity）」が「低」となる例はどれか。

ビジネス的な観点（信頼、ブランド、法的要件等）で、技術的な影響とは別に優先順位が決まる。

2026年1月25日

「インシデント管理」において、不具合の「重要度（Severity）」を決定する主な基準はどれか。

システムを停止させるか、一部の機能制限か、単なる表示ミスかなどの影響度で測る。

2026年1月25日