監修：山根一城（株式会社ポテンシャライト代表取締役CEO ／ 業界20年）
システムテストは、単体テストと結合テストを終えたソフトウェアを、本番に近い環境で一つのシステムとしてまとめて検証する工程です。個々の機能ではなく、要件定義で決めた業務全体の振る舞いや、性能・セキュリティといった機能以外の要求を確かめます。開発側が実施する最後のテストで、この後の受入テストへ橋渡しをする位置づけになります。
システムテストは、V字モデルでいえば要件定義と対になる工程です。要件定義で「システムとして何ができるべきか」を決め、システムテストで「本当にその通り動くか」を確かめます。単体テストがモジュール単位、結合テストがモジュール間の接続を見るのに対し、システムテストは業務の入口から出口までを一続きで通します。
確認する軸は、大きく二つに分かれます。一つは機能要件で、受注から出荷までといった業務シナリオが要件定義書のとおりに流れるかを見ます。もう一つは非機能要件で、性能、負荷への耐性、セキュリティ、障害からの復旧、他システムとの連携などを扱います。非機能は結合テストまででは見落とされやすく、システムテストではじめて本格的に確認されることが多い領域です。
目的は、開発チームが「これで受入テストに出せる」と判断できる状態を作ることにあります。バグをゼロにするというより、要件に対する充足度と残っているリスクを可視化し、次工程へ渡せる品質かどうかを示す工程だと捉えると整理しやすくなります。
進め方は、テスト計画から始めて設計、実施、報告へと進みます。担当するのは主に開発ベンダーのテスト担当者やQAで、PMは計画と結果の妥当性を確認する立場になります。順序は次のようになります。
主な成果物は、テスト計画書、テストケース、テスト実施結果、不具合管理表、そしてテスト完了報告書です。完了報告書には、消化状況、未解決の不具合とその影響、残存リスクをまとめ、次工程への申し送りとします。
システムテストで問題が起きやすいのは、テストそのものより前の準備段階であることが多いようです。代表的なつまずきを軸ごとに挙げます。
PMの立場では、テストの遅れが検出件数の収束しない状態として現れることがあります。件数だけを追って「予定どおり消化した」と判断せず、未解決不具合の中身と残存リスクを一緒に見ることが、次工程での手戻りを減らすことにつながります。
システムテストは前後の工程と混同されやすいため、「誰が・何を・どの視点で確認するか」という軸で並べると違いが見えます。
この区別が曖昧なままだと、受入テストで初めて要件の解釈違いが見つかる、といった手戻りが起こりやすくなります。工程ごとの役割を関係者と共有しておくことが、後半の混乱を抑える助けになります。
システムテストの工程を押さえておくと、PMとして品質とスケジュールの両面で判断の精度を上げやすくなります。テストの遅れは、検出不具合が収束しない、環境準備が後ろ倒しになる、といった形で早い段階に兆候が出ることが多く、件数の裏にある中身を読めるかどうかで打ち手のタイミングが変わってきます。
また、システムテスト・結合テスト・受入テストの役割分担を関係者に説明できることは、発注側と開発側の期待値をそろえるうえで役立ちます。要件定義から品質管理までを一続きの流れとして語れるPMは、上流工程の設計にも入りやすくなり、担える領域を広げやすい傾向があります。テスト工程の理解は、その足場の一つになります。
システムテストと結合テストはどう違いますか。
結合テストはモジュールやサブシステム同士の接続が正しく動くかを確認する工程で、視点は部品のつなぎ目にあります。システムテストは、結合が済んだ全体を一つのシステムとして、業務シナリオや性能・セキュリティなどの非機能要件の視点でまとめて検証します。範囲と目的が一段広い工程だと捉えると整理しやすくなります。
システムテストは誰が実施しますか。
多くの場合、開発を担うベンダーのテスト担当者やQAが主体となって実施します。開発側が行う最後のテストで、要件をどこまで満たせているかを確認する工程です。この後に発注側の利用部門が主体となる受入テストが続き、実施主体と確認の目的が切り替わっていきます。
PMはシステムテストで何を見ればよいですか。
消化件数だけでなく、未解決の不具合の中身と残っているリスクを合わせて確認することが重要です。テストが要件と対応づいているか、環境が本番に近いか、非機能要件が後回しになっていないかを見ておくと、受入テストでの手戻りを抑えやすくなります。完了報告書の申し送り内容の確認も役割の一つです。