【ITパスポート練習問題 6.3対応】(1) システム開発のプロセス – 2

【解説】

正解: 1 複数のモジュールが適切に連携するかを確認すること

この問題は、統合テストの位置付けと目的を理解しているかを確認するものです。単体テスト・統合テスト・受入れテストといった各テストの役割の違いを区別できているかがポイントになります。

選択肢1の「複数のモジュールが適切に連携するかを確認すること」は、統合テストの主な目的を正しく表した内容です。単体テストでモジュール個別の動作を確認した後、それらを組み合わせた際にインターフェースやデータ受け渡しに問題がないかを検証するのが統合テストです。

選択肢2の「各モジュールが単独で正しく動作するかを確認すること」は、モジュール単体の動作を検証する単体テストの目的です。選択肢3の「システム全体がユーザー要求を満たしているかを確認すること」は、システムを完成品としてまとめて評価する受入れテストやシステムテストの目的であり、統合テストの目的とは異なります。

【解説】

正解: 2 モジュール間のインターフェース

この問題は、統合テストで具体的にどの点を重視して確認するのかを理解しているかを問うものです。単体テストでは見えにくい、モジュール同士のつなぎ目に注目できているかがポイントです。

選択肢2の「モジュール間のインターフェース」は、統合テストで最も重視される確認項目です。モジュール同士が想定どおりのデータ形式や呼び出し手順で連携しているか、異常なデータが渡されたときに不具合が出ないかといった点をテストします。

選択肢1の「システムのパフォーマンス」は、応答時間や処理能力などを評価する性能テストの範囲であり、統合テストの主目的ではありません。選択肢3の「データベースのバックアップ」は、運用や障害対策の一環として重要な作業ですが、テスト工程そのものの主な確認項目とは言えません。

【解説】

正解: 3 単体テストが完了した後

この問題は、開発プロセスの中で統合テストがどのタイミングで実施されるかを理解しているかを確認するものです。各テスト工程の順序関係をイメージできているかが問われています。

選択肢3の「単体テストが完了した後」が、統合テストを実施する適切なタイミングです。まず各モジュールが単体テストで正しく動作することを確認し、その後にモジュール同士を組み合わせて連携動作を確認する、という流れで進めるのが一般的です。

選択肢1の「システム全体の開発が完了した後」は、システムテストや受入れテストが行われるタイミングを表しており、統合テストよりも後の段階です。選択肢2の「要件定義が完了した後」は、まだ設計や実装も始まっていない開発初期の段階であり、テストを実施できる状態ではないため不適切です。

【解説】

正解: 2 入力に対する正しい出力

この問題は、ブラックボックステストがどのような観点でテストを行う手法なのかを理解しているかを確認するものです。内部構造を見るのか、外側からの動作を見るのかという違いを把握しているかがポイントです。

選択肢2の「入力に対する正しい出力」は、ブラックボックステストの基本的な考え方を表しています。ブラックボックステストでは、内部のプログラム構造には踏み込まず、「ある入力に対して期待どおりの結果が得られるか」を外側から確認します。そのため、仕様書や画面設計書をもとにテストケースを作成することが多くなります。

選択肢1の「内部コードの論理構造」は、分岐条件やループなどソースコードの中身を調べるホワイトボックステストの対象です。選択肢3の「モジュール間のデータ連携」は、モジュール同士のつなぎ目を確認する統合テストの主な確認事項であり、ブラックボックステストの説明としては適切ではありません。

【解説】

正解: 3 ユーザー目線での動作確認を行う

この問題は、ブラックボックステストの特徴を、ホワイトボックステストと対比しながら理解しているかを確認するものです。テストの視点が「利用者寄りか」「内部構造寄りか」を区別できているかが問われています。

選択肢3の「ユーザー目線での動作確認を行う」は、ブラックボックステストの特徴を的確に表しています。ブラックボックステストでは、ユーザーが実際に行う操作や入力を想定し、その結果として表示される画面や出力が仕様どおりかどうかを確認します。内部の処理手順よりも、外部から見える振る舞いを重視する点が特徴です。

選択肢1の「内部のアルゴリズムを検証する」は、分岐網羅や条件網羅といった観点でコード内部を調べるホワイトボックステストの特徴です。選択肢2の「開発者目線での動作確認を行う」も、内部構造や実装方法をよく知る開発者がコードに基づいて確認するホワイトボックステストのイメージに近く、ブラックボックステストの説明としては適切ではありません。

【解説】

正解: 1 ソースコードの詳細な理解が必要ない

この問題は、ブラックボックステストを採用することによる利点を理解しているかを確認するものです。テスト担当者に求められる知識や役割の違いを意識できているかがポイントです。

選択肢1の「ソースコードの詳細な理解が必要ない」は、ブラックボックステストの大きな利点です。ブラックボックステストでは、仕様書や画面仕様をもとにテストケースを作成するため、テスト担当者がソースコードの中身を深く理解していなくてもテストを実施できます。これにより、開発者以外のメンバーもテストに参加しやすくなります。

選択肢2の「内部構造を正確に把握できる」は、むしろホワイトボックステストの特徴です。ブラックボックステストでは内部構造には踏み込まないため、内部の詳細な把握には向きません。選択肢3の「エラーの原因を即座に特定できる」は必ずしも当てはまりません。ブラックボックステストで不具合を見つけても、原因がコードのどこにあるかを特定するには、別途ソースコードの調査が必要になることが多いからです。

【解説】

正解: 2 応答時間や処理速度

この問題は、性能テストがどのような観点を評価するテストなのかを理解しているかを確認するものです。機能の正しさと性能の評価を区別できているかが問われています。

選択肢2の「応答時間や処理速度」は、性能テストで主に評価される項目です。性能テストでは、一定の負荷条件のもとで、画面の表示までにかかる時間や、処理の完了までに要する時間、同時接続数などのパフォーマンス指標を測定し、要求された性能を満たしているかを確認します。

選択肢1の「ソフトウェアの動作が要件通りかどうか」は、機能要件を満たしているかを確認する機能テストの目的です。選択肢3の「データの入力精度」は、入力チェックやデータの妥当性を確認するテストの範囲であり、性能テストの主な評価項目とは言えません。

【解説】

正解: 3 ソフトウェアの内部構造の効率を評価すること

この問題は、性能テストの目的として適切なものと、他のテストや設計段階で扱うべき内容を区別できるかを確認するものです。性能テストが「外側から見た振る舞い」を評価するテストであることを理解しているかがポイントです。

選択肢3の「ソフトウェアの内部構造の効率を評価すること」は、性能テストの直接の目的としては不適切です。内部構造の効率そのものは、設計レビューやコードレビュー、あるいはチューニングの検討対象であり、性能テストでは主に外部から測定可能な応答時間や処理能力といった結果を評価します。

選択肢1の「システムが大規模なトラフィックに耐えられるか確認すること」は、負荷をかけた状態で性能を測るテストとして、性能テストの代表的な目的の一つです。選択肢2の「通常時の負荷での応答時間を測定すること」も、平常運用時の性能を確認するという点で性能テストの目的に合致しています。

【解説】

正解: 1 システムの応答時間

この問題は、性能テストで用いられる代表的な評価指標を理解しているかを確認するものです。品質に関するさまざまな指標の中から、性能に関係するものを選び取れるかが問われています。

選択肢1の「システムの応答時間」は、性能テストで最も基本的かつ重要な評価指標です。画面表示までの時間や処理完了までの時間が許容範囲内に収まっているかを測定することで、ユーザーがストレスなく利用できるかどうかを判断します。

選択肢2の「バグの発見率」は、テスト全体の品質管理やテストプロセスの評価に用いられる指標であり、性能そのものを示すものではありません。選択肢3の「データベースの正確性」は、データの整合性や正しさを確認するテストの対象であり、性能テストで扱う指標とは言えません。

【解説】

正解: 2 システムの耐久性と安定性

この問題は、負荷テストが何を確認するためのテストなのか、その狙いを理解しているかを確認するものです。単に性能を測るだけでなく、高負荷時の振る舞いに注目できているかがポイントです。

選択肢2の「システムの耐久性と安定性」は、負荷テストの主な確認事項を正しく表しています。大量のアクセスや高い処理負荷をかけた状態で、システムが応答不能になったり異常終了したりせず、一定時間安定して動作し続けるかどうかを検証します。

選択肢1の「ユーザーインターフェースの使いやすさ」は、画面の分かりやすさや操作性を評価するユーザビリティテストの範囲です。選択肢3の「コードの可読性」は、ソースコードレビューなど開発プロセス上の品質確認で扱う内容であり、負荷テストの対象ではありません。

【解説】

正解: 3 各モジュールが単体で正確に動作するか確認すること

この問題は、負荷テストの目的と、他のテスト工程（特に単体テスト）の目的を区別できているかを確認するものです。テストの対象が「システム全体」か「モジュール単体」かを意識できているかが問われています。

選択肢3の「各モジュールが単体で正確に動作するか確認すること」は、負荷テストではなく単体テストの目的です。単体テストはモジュールごとに正しい処理が行われるかを確認するテストであり、高負荷状態での全体的な動作を確認するわけではありません。

選択肢1の「サーバーが負荷に対して応答可能か確認すること」は、高負荷状態での応答性を確認する負荷テストの目的に合致しています。選択肢2の「システムが予期せぬ停止をしないか確認すること」も、負荷をかけた状態でシステムが落ちないかどうかを確認するという点で、負荷テストが重視する観点の一つです。

【解説】

正解: 1 クライアントのデザインの美しさ

この問題は、負荷テストの対象となる要素と、テストの対象外となる要素を区別できているかを確認するものです。見た目と性能・負荷の違いを理解しているかがポイントです。

選択肢1の「クライアントのデザインの美しさ」は、負荷テストの対象には含まれません。デザインの良し悪しやレイアウトの美しさは、ユーザビリティやデザインの評価の範囲であり、処理能力や耐久性を確認する負荷テストとは別の観点です。

選択肢2の「サーバーの処理能力」は、負荷テストで重要な評価対象です。多くのリクエストを処理できるか、CPUやメモリの使用状況に問題がないかを確認します。選択肢3の「ネットワークの帯域幅」も、通信量が増加した際に性能がどのように影響を受けるかを確認する上で、負荷テストの対象となる要素です。

【解説】

正解: 2 変更が既存の機能に影響を与えていないか確認すること

この問題は、回帰テストがどのような目的で実施されるかを理解しているかを確認するものです。新しい修正が「他の部分に悪影響を及ぼしていないか」を意識できているかがポイントです。

選択肢2の「変更が既存の機能に影響を与えていないか確認すること」は、回帰テストの目的を正しく表しています。バグ修正や機能追加を行った際、その変更によって以前は正常に動いていた機能が壊れていないかを再確認するのが回帰テストです。

選択肢1の「追加機能の動作が要件を満たすか確認すること」は、新しく作成・修正した部分そのものの動作確認であり、単体テストや機能テストの主な目的です。選択肢3の「新機能のユーザー満足度を確認すること」は、ユーザビリティテストやアンケート調査などの範囲であり、回帰テストの目的ではありません。

【解説】

正解: 2 機能の修正や改修後

この問題は、回帰テストをどのタイミングで実施するのが適切かを理解しているかを確認するものです。変更が加えられた直後にどのような確認が必要かをイメージできているかが問われています。

選択肢2の「機能の修正や改修後」は、回帰テストを行うべき典型的なタイミングです。バグ修正や機能追加を行った直後に回帰テストを実施することで、修正が他機能へ悪影響を及ぼしていないかを早期に発見できます。

選択肢1の「システムの最終納品後」は、運用開始前の最終確認や受入れテストが意識されるタイミングであり、回帰テストを行うタイミングとして限定的です。選択肢3の「要件定義完了後」は、まだ実装も修正も行われていない工程であり、そもそも回帰テストを実施できる状態ではないため不適切です。

【解説】

正解: 3 追加機能のユーザビリティを確認する

この問題は、回帰テストの対象となる内容と、別のテストで扱うべき内容を区別できているかを確認するものです。回帰テストが「変更の副作用」に焦点を当てていることを理解しているかがポイントです。

選択肢3の「追加機能のユーザビリティを確認する」は、回帰テストの目的とは異なる内容であり、不適切です。ユーザビリティの確認は、画面の分かりやすさや操作のしやすさを評価する別のテスト（ユーザビリティテスト）で扱われます。

選択肢1の「過去に問題があった箇所を再度確認する」は、再度同様の問題が発生していないかを確認するという意味で、回帰テストの重要な対象です。選択肢2の「修正による副作用の検出」も、修正が他の部分に悪影響を与えていないかを確認するという回帰テストの目的そのものを表しています。

【解説】

正解: 1 データベースのテーブル設計

この問題は、利用者マニュアルにどのような情報を記載すべきか、また記載すべきでないかを理解しているかを確認するものです。利用者向けの情報と内部設計情報を区別できているかがポイントです。

選択肢1の「データベースのテーブル設計」は、システム内部の技術的な設計情報であり、利用者マニュアルに含める内容としては不適切です。これらの情報は、開発者や運用担当者向けの設計書や技術ドキュメントに記載されるべきものです。

選択肢2の「システムの操作方法」は、利用者マニュアルの中心となる内容です。画面の説明や操作手順を示すことで、ユーザーが迷わずシステムを使えるようにします。選択肢3の「エラー発生時の対処法」も、ユーザーがトラブル時に自力で対処できるようにするための重要な情報であり、利用者マニュアルに含めるべき内容です。

【解説】

正解: 2 エンドユーザー

この問題は、利用者マニュアルの想定読者が誰であるかを理解しているかを確認するものです。ドキュメントの種類ごとに対象とする読者が異なることを意識できているかが問われています。

選択肢2の「エンドユーザー」は、利用者マニュアルの主な対象者として適切です。利用者マニュアルは、システムを実際に操作するユーザーが、手順に従って正しく機能を使えるようにするための文書です。

選択肢1の「システム開発者」は、ソースコードや設計書など技術的な文書を参照することが多く、利用者マニュアルの主な対象者ではありません。選択肢3の「サポートエンジニア」も、問い合わせ対応や障害対応のために、より詳細な技術資料や運用マニュアルを参照することが多く、利用者マニュアルの直接の対象とは言えません。

【解説】

正解: 3 ユーザーが操作に迷わないようにするため

この問題は、利用者マニュアルの目的を他の文書の目的と区別して理解しているかを確認するものです。利用者マニュアルが「何のために存在するのか」を押さえられているかがポイントです。

選択肢3の「ユーザーが操作に迷わないようにするため」は、利用者マニュアルの目的を端的に表した内容です。画面の説明や操作手順、注意事項を分かりやすく示すことで、ユーザーがシステムを正しく効率的に利用できるよう支援します。

選択肢1の「システムの機能要件を確認するため」は、要件定義書など上流工程の文書の目的に近い内容であり、利用者マニュアルの役割ではありません。選択肢2の「システムのプログラム構造を把握するため」は、設計書やソースコードを対象とした開発者向けの目的であり、利用者マニュアルの目的とは異なります。

【解説】

正解: 1 委託者（クライアント）

この問題は、受入れテストを誰が主体となって実施するのか、その立場を理解しているかを確認するものです。開発側のテストと、利用者側のテストの違いを把握しているかがポイントです。

選択肢1の「委託者（クライアント）」は、受入れテストの実施者として適切です。受入れテストは、システムを発注した側が「自分たちの要求どおりにシステムが動作しているか」を確認し、納品物を受け入れるかどうかを判断するためのテストです。実務では、委託者自身が行う場合もあれば、委託者の立場でテストを代行するチームが行う場合もあります。

選択肢2の「システム開発チーム」は、単体テストや統合テスト、システムテストなど、開発側の観点で行うテストが主な担当範囲です。選択肢3の「テストエンジニア」も、開発側のテストを専門に担当する立場であり、最終的な受入れ判断を行う主体ではありません。

【解説】

正解: 2 実運用環境で要件を満たしているか確認すること

この問題は、受入れテストの目的を正しく理解しているかを確認するものです。単に動けばよいのではなく、「実際の運用条件で要求どおりかどうか」を確認することに目を向けられているかがポイントです。

選択肢2の「実運用環境で要件を満たしているか確認すること」は、受入れテストの目的を正しく表しています。受入れテストでは、実際の業務データや運用手順を想定した環境でテストを行い、ユーザーの要求や契約上の仕様が満たされているかを確認します。

選択肢1の「システムの内部構造を確認すること」は、ソースコードや設計を対象とするホワイトボックステストや設計レビューの領域であり、受入れテストの目的とは異なります。選択肢3の「システムのパフォーマンスを確認すること」は、性能テストで主に扱う目的であり、受入れテストでは必要に応じて確認されることはあっても、中心的な目的とは言えません。

【解説】

正解: 3 コードの効率性

この問題は、受入れテストがどのような観点を対象とし、逆にどのような観点は対象外となるかを理解しているかを確認するものです。利用者視点のテストで何を重視するかを押さえられているかがポイントです。

選択肢3の「コードの効率性」は、受入れテストの対象としては不適切です。コードの効率性は、設計や実装段階でレビューしたり、性能テストで必要に応じて検証したりする開発側の観点であり、受入れテストで直接評価されることは通常ありません。

選択肢1の「システムの運用手順」は、実運用で問題なくシステムを利用できるかを確認するため、受入れテストでチェックされる対象に含まれます。選択肢2の「システムが要件を満たしているか」も、受入れテストの中心的な目的であり、ユーザー要求や契約上の仕様を満たしているかどうかを確認する重要な観点です。

【解説】

正解: 1 システムが要件を満たしているか確認すること

この問題は、「妥当性確認テスト」が何を確認するためのテストなのかを理解しているかを確認するものです。システムが「作り手の仕様どおり」ではなく「利用者の要件どおり」になっているかに注目できているかがポイントです。

選択肢1の「システムが要件を満たしているか確認すること」は、妥当性確認テストの目的を正しく表しています。妥当性確認テストでは、ユーザーの要求や業務上のニーズに照らして、「この仕様・設計・システムは本当に望ましいものになっているか」を確かめます。

選択肢2の「システムの内部設計を確認すること」は、設計レビューやホワイトボックス的な観点での検証内容であり、妥当性確認テストの目的とは異なります。選択肢3の「システムのパフォーマンスを測定すること」は、性能テストで扱うべき目的であり、妥当性確認テストの中心的な目的ではありません。

【解説】

正解: 1 システムの設計段階

この問題は、妥当性確認テストがどの工程で行われるか、そのタイミングを理解しているかを確認するものです。完成後だけでなく、早い段階で妥当性を確認することの重要性を理解しているかがポイントです。

選択肢1の「システムの設計段階」は、妥当性確認テストを行うタイミングとして適切です。要件定義をもとに作成した設計が、利用者のニーズや業務要件に合致しているかを設計段階で確認することで、後工程での大きな手戻りを防ぐことができます。

選択肢2の「システムが納品された後」や、選択肢3の「システムの運用が開始された後」は、主に受入れテストや運用テストのタイミングです。この段階での確認も重要ですが、妥当性確認テストの考え方としては、より上流の設計段階で行うことが重視されます。

【解説】

正解: 2 システムの実行効率の確認

この問題は、妥当性確認テストの範囲に含まれる内容と、他のテストで扱うべき内容を区別できているかを確認するものです。要件や業務適合性と、性能評価の違いを理解しているかがポイントです。

選択肢2の「システムの実行効率の確認」は、妥当性確認テストには含まれない内容です。実行効率や処理性能の評価は、性能テストや負荷テストで扱うべき事項であり、妥当性確認テストの主眼ではありません。

選択肢1の「ユーザー要件を満たしているかの確認」は、システムが利用者の要求どおりになっているかを確かめるものであり、妥当性確認テストの中心的な対象です。選択肢3の「業務要件に即しているかの確認」も、業務プロセスや運用の実態に合っているかを確認するという意味で、妥当性確認テストに含まれる内容です。

【解説】

正解: 1 データが正確に新システムに引き継がれること

この問題は、システム移行作業において何を最優先で考えるべきかを理解しているかを確認するものです。機能やデザインよりも、データそのものの重要性を意識できているかがポイントです。

選択肢1の「データが正確に新システムに引き継がれること」は、移行作業における最も重要な点を示しています。移行時にデータが欠落したり誤って変換されたりすると、業務継続に大きな支障が出るため、データの整合性と完全性を確保することが最優先事項となります。

選択肢2の「新システムの開発効率を向上させること」は、開発プロセスの改善に関する目的であり、移行作業そのものの最重要事項ではありません。選択肢3の「ユーザーインターフェースが改善されること」も、新システムの利便性向上としては望ましいものの、移行作業の「最も重要なこと」とは言えません。

【解説】

正解: 2 旧システムに戻すためのバックアップを用意すること

この問題は、移行作業に失敗した場合にどうリカバリするか、その備えを理解しているかを確認するものです。事前にどのような対策を講じておくべきかをイメージできているかがポイントです。

選択肢2の「旧システムに戻すためのバックアップを用意すること」は、移行失敗時の重要なリカバリ対策を正しく表しています。移行後に重大な不具合が発生した場合でも、旧システムや旧データに戻せるようにしておけば、業務を継続しながら問題の原因究明と再移行の準備ができます。

選択肢1の「システムのバージョンアップを行うこと」は、移行失敗後の対策としては具体性に欠け、バージョンアップ自体が新たなリスクを生む可能性もあります。選択肢3の「ユーザーの意見を収集すること」は、問題の把握や改善には役立ちますが、直ちに業務を復旧させるリカバリ対策としては不十分です。

【解説】

正解: 2 利用者が少ない時間帯や休日

この問題は、移行作業をいつ実施するのが適切か、そのタイミングを業務への影響という観点から考えられるかを確認するものです。システム停止が業務に与える影響を最小限にする工夫ができているかがポイントです。

選択肢2の「利用者が少ない時間帯や休日」は、移行作業のタイミングとして最も適切です。移行中はシステムを停止したり、不安定な状態になったりする可能性があるため、利用者が少ない時間帯に実施することで、業務への影響を抑えることができます。

選択肢1の「システムが最も利用されるピーク時」は、障害が発生した場合の影響が大きく、最も避けるべきタイミングです。選択肢3の「新システムの開発が完了した直後」は、テストや事前準備が十分でない可能性があり、必ずしも移行に適したタイミングとは限りません。

【解説】

正解: 3 システムの再設計と開発

この問題は、「保守」の範囲と、新規開発や再構築の範囲を区別できているかを確認するものです。運用後の対応としてどこまでを保守と呼ぶかを理解しているかがポイントです。

選択肢3の「システムの再設計と開発」は、新しいシステムを作り直す活動を指しており、一般的には保守ではなく再構築や再開発の範囲に含まれます。そのため、保守の主な目的としては不適切です。

選択肢1の「システムの機能拡張」は、既存システムに新しい機能を追加して利便性や価値を高める活動であり、改善保守（機能改善・機能追加）として保守の一種に含まれます。選択肢2の「システムのバグ修正」も、障害対応として行われる保守（障害保守）の代表的な目的です。

【解説】

正解: 2 ユーザーのニーズに応じた機能追加

この問題は、運用中のシステムに対して具体的にどのような作業が「保守」に含まれるかを理解しているかを確認するものです。開発時の作業と運用後の作業の違いを意識できているかがポイントです。

選択肢2の「ユーザーのニーズに応じた機能追加」は、運用中のシステムに対して行う改善保守にあたります。ユーザーからの要望や業務の変化に対応して機能を追加・改善することも、保守作業の重要な一部です。

選択肢1の「システムのインフラ構築」は、サーバーやネットワークなど基盤を新たに用意する作業であり、通常は新規開発や導入時の活動に分類されます。選択肢3の「システムのコスト削減計画の立案」は、経営的・企画的な活動であり、具体的な保守作業そのものとは言えません。

【解説】

正解: 3 設計保守

この問題は、保守の代表的な分類を理解しているかを確認するものです。どの用語が正式な保守の区分として使われているかを見分けられるかがポイントです。

選択肢3の「設計保守」は、一般的な保守の分類としては用いられない用語であり、不適切です。保守の種類としては、「障害保守」「予防保守」「改善保守」「適応保守」などが代表的に挙げられますが、「設計保守」という区分は通常ありません。

選択肢1の「改善保守」は、性能向上や使い勝手の改善、新機能の追加など、システムをより良くするための保守を指す区分です。選択肢2の「適応保守」は、OSやミドルウェアの変更、法改正など、環境の変化に合わせてシステムを対応させるための保守を指しており、いずれも保守の種類として正しく用いられる用語です。