This question's explanation and your answers so far.
システム開発プロセスを要件定義, 外部設計, 内部設計, プログラミングに分け, テストの種類を運用テスト, 結合テスト, システムテスト, 単体テストに分けたとき, 図の a～c に入れる字句の適切な組合せはどれか。 図は, 左側にシステム開発プロセスの工程, 右側に対応するテストの種類を配置したものである。破線の矢印 (←---→) が「対応する工程」を, 実線の矢印 (←——) が「システム開発プロセスの流れ」を示す。
| システム開発プロセス (左) | 対応するテスト (右) |
|---|---|
| 要件定義 | c |
| 外部設計 | b |
| 内部設計 | a |
| プログラミング | 単体テスト |
実線の矢印は, 左側を 要件定義 → 外部設計 → 内部設計 → プログラミング と下向きに進み, 続いて右側を 単体テスト → a → b → c と上向きに進む。破線の矢印は, 左右で「対応する工程」どうしを結んでいる。
a = operational testing, b = integration testing, c = system testing. The correspondence derived from the figure is a = integration testing, b = system testing, c = operational testing, so all three of a, b and c are shifted out of place (the integration testing that belongs in a has been put in b, the system testing that belongs in b has been put in c, and the operational testing that belongs in c has been put in a). Decisively, operational testing, which should be carried out last, appears in a at the very bottom, contradicting the upward flow of the solid arrows on the right (unit → integration → system → operational). Also, a is linked by a dashed line to internal design, but what operational testing verifies is not the internal design; it is the business requirements decided in requirements definition, so this does not fit the correspondence shown by the dashed lines either.
正解 The correct answer is イ (a = integration testing, b = system testing, c = operational testing). The figure represents the V-model, and the dashed lines show the 'corresponding phase' — they link each development phase on the left with the test on the right that verifies what was decided in that phase. The pair already filled in, programming to unit testing, is the clue: unit testing checks whether each individual module produced by programming works as specified. Apply the same idea upward. The a linked by a dashed line to internal design is integration testing. Internal design decides the internal structure of the program and how data is passed between modules (the interfaces), so its counterpart is integration testing, which combines modules and checks that they work together. The b linked by a dashed line to external design is system testing. External design decides the screens, reports, functions and performance requirements that the user sees, so its counterpart is system testing, which checks the whole system against those specifications. The c linked by a dashed line to requirements definition is operational testing. Requirements definition decides what business needs must be met, so its counterpart is operational testing, in which users check that the system can be used in an environment close to the real business procedures and real data. The upward solid arrows on the right also read unit testing → integration testing → system testing → operational testing, matching an order of execution in which the scope of verification widens step by step from a module, to between modules, to the whole system, to the whole business operation.
a = system testing, b = operational testing, c = integration testing. Here too all three correspondences are out of place. In particular c = integration testing is wrong: c is linked by a dashed line to requirements definition, but what integration testing verifies is the interfaces between modules decided in internal design, not the business requirements. Following the solid lines on the right gives the order unit → system → operational → integration, in which integration testing, the narrowest in scope, ends up last — which also violates the V-model principle that the scope of verification widens step by step.
a = system testing, b = integration testing, c = operational testing. c = operational testing is correct, but a and b have been swapped. Since a is linked by a dashed line to internal design, it should be integration testing, and since b is linked by a dashed line to external design, it should be system testing. Integration testing is what verifies internal design (the internal structure of the program and how data is passed between modules), and system testing is what verifies external design (the functions, screens and performance the user sees); エ mixes up this correspondence. The order of execution on the right also becomes unit → system → integration, an unnatural sequence in which the whole system is checked before the links between modules are checked.