ITパスポート 2018年 春期 問51
問題文
新しく開発した業務システムのテストに、利用部門の立場で参画することになった。利用部門の立場で確認すべき事項として、適切なものはどれか。
選択肢
ア:業務上の要件が満たされていること(正解)
イ:個々のプログラムがプログラム仕様書どおりに動作すること
ウ:システムが利用するネットワークの監視が決められた手順どおりに実施できること
エ:プログラム間のデータの受渡しが設計書の規定どおりに行われること
🔒 解説は解答すると表示されます
利用部門の立場で参画するテストで確認すべき事項【ITパスポート 解説】
正解の理由
利用部門(業務を実際に行う側)の視点でテストに参加する目的は、「業務上必要な要件が満たされているか」を確認することです。つまり、業務フローや業務ルール、帳票の内容や操作手順など、実務で使えるかどうかを判断します。設問の選択肢の中では、業務要件そのものをチェックする ア が最も適切です。
利用部門はシステムの動作が「業務を正しく支援するか」を評価します。個々のプログラムの内部動作やネットワーク監視手順、プログラム間のデータ受渡しといった技術的な詳細は、通常は開発側や運用・インフラ側の担当領域です。したがって業務視点で確認すべき事項は業務要件の充足であり、これが正解の理由です。
解法ステップ
- 「誰の立場か」を確認する:設問は「利用部門の立場」であることを把握する。
- 利用部門が関心を持つ内容を考える:業務が滞りなく行えるか、帳票や画面、操作性など業務に直結する点。
- 選択肢を照らし合わせる:業務要件に関するものを選ぶ(ア)。技術的詳細に関するものは除外する。
- 確認して終了:業務目線での受入(ユーザ受入テスト)であることを再確認する。
選択肢別の誤答解説
-
ア: 業務上の要件が満たされていること
- 正答。利用部門は業務観点での受入を行い、業務フローや出力帳票、操作手順、例外処理などが要件通りに実現されているかを確認します。
-
イ: 個々のプログラムがプログラム仕様書どおりに動作すること
- 誤り。これは単体テスト(ユニットテスト)やプログラマ/テスト担当者が行う確認事項です。利用部門は通常、プログラム単位の詳細な内部動作までは確認しません。
-
ウ: システムが利用するネットワークの監視が決められた手順どおりに実施できること
- 誤り。ネットワーク監視や運用手順はインフラや運用チームの責任範囲です。利用部門は監視結果の可視化や障害発生時の業務影響を確認することはありますが、監視手順そのものの実施確認は専門部署が行います。
-
エ: プログラム間のデータの受渡しが設計書の規定どおりに行われること
- 誤り。これは結合テストやシステムテストで検証される技術的な項目です。利用部門はデータが正しく業務に反映されるか(例:画面の表示や帳票の中身)を確認しますが、内部の受渡し手順や設計書の整合性を詳細にチェックするのは開発側が主です。
よくある誤解
-
利用部門がすべての技術的詳細(プログラム単位やネットワーク監視)を確認すべきだと考える
- 実際は、利用部門は業務に直結する観点(業務要件)にフォーカスします。技術的な詳細は開発・運用で確認されます。
-
受入テストでは単に「仕様書どおりか」を見るだけだと考える
- 受入テストは「実務で使えるか」を判断する場です。仕様書どおりかだけでなく、操作性や業務での例外対応、出力の見やすさなど実務面の検証が重要です。
補足コラム
利用部門が参加するテストは「ユーザ受入テスト(User Acceptance Testing:利用者が業務観点で受け入れを判断するテスト)」と呼ばれます。準備としては次が有効です。
- 受入基準(いつ合格とするか)を明確にする。例えば「主要業務フロー10件が正常に処理できる」「主要帳票の項目が全て正しい」など。
- テストシナリオを業務フローに沿って用意する。現実の作業手順に基づいたケースを作ると発見が多くなります。
- テストデータを実務に近い形で用意する。実際の運用データを模したデータで試すと、本番での問題を防げます。
- 欠陥(バグ)を見つけたら、再現手順、期待結果、実際の結果を明確にして報告する。これにより開発側が迅速に対応できます。
簡単な例:請求書作成機能の受入では「顧客ランクによる割引が正しく反映される」「締め日が異なる顧客でも請求書が正しい期間で作成される」など業務ルールに沿った項目を確認します。
FAQ
Q1: 利用部門が見ればよい「業務要件」の具体例は?
A1: 主な業務フロー(発注→出荷→請求など)、帳票の項目とレイアウト、担当者が行う操作手順、エラー時の業務対応、業務に影響する応答速度やバッチ処理の完了時間などです。
A1: 主な業務フロー(発注→出荷→請求など)、帳票の項目とレイアウト、担当者が行う操作手順、エラー時の業務対応、業務に影響する応答速度やバッチ処理の完了時間などです。
Q2: 技術的な問題(プログラムの不具合)を見つけたらどうする?
A2: まず事象を再現できる手順をメモし、期待される結果と実際の結果を明確にして不具合報告(チケット)を出します。開発側で修正・再テスト後、利用部門で再確認します。
A2: まず事象を再現できる手順をメモし、期待される結果と実際の結果を明確にして不具合報告(チケット)を出します。開発側で修正・再テスト後、利用部門で再確認します。
Q3: 受入合格の基準が曖昧な場合は?
A3: 事前に「受入基準(合格条件)」を作り、関係者(利用部門、開発、運用)で合意しておくことが重要です。これがないと合否で意見が分かれやすくなります。
A3: 事前に「受入基準(合格条件)」を作り、関係者(利用部門、開発、運用)で合意しておくことが重要です。これがないと合否で意見が分かれやすくなります。
Q4: 性能(レスポンス等)は利用部門がチェックすべきか?
A4: 業務に影響するレベルの性能要件(例:決裁画面の応答は3秒以内)がある場合、利用部門も確認します。ただし詳細な負荷試験は開発・テストチームが担当します。
A4: 業務に影響するレベルの性能要件(例:決裁画面の応答は3秒以内)がある場合、利用部門も確認します。ただし詳細な負荷試験は開発・テストチームが担当します。
関連キーワード: 利用部門、ユーザ受入テスト、業務要件、テストレベル、受入基準、テストシナリオ、運用切替、バグ報告

\ せっかくなら /
ITパスポートを
クイズ形式で学習しませんか?
クイズ画面へ遷移する→
すぐに利用可能!

