IT化が急速に進む昨今、ITインフラを支えているシステム開発会社では日々さまざまなシステムやツールが生みだされています。その開発の中で、絶対に避けて通ることのできない工程のひとつに「システムテスト」があります。これは機能が計画通り要件を満たしているか否か確かめるための工程で、ほぼ全てのシステム開発会社で行われています。
本記事では、システムテストの目的・種類・工程について詳しくご紹介します。
システムテストとは
システムテストは別名「総合テスト」とも呼ばれ、エンドユーザーが実際に使用するシーンを想定し、開発の最終工程で行われるのが一般的です。開発したシステムが想定通りに動作するのか、設計書通りの性能や機能を備えているかなどについて検証します。
エンドユーザーの利用シーンを想定し、さまざまな観点からテストを行うことにより、開発環境だけでは発見に至らない不具合・バグに気づくことができます。また、システム全体を見据えてハードウェアも含めた包括的なテストも実行することで、ハードウェア環境に関する不具合を検出することも可能です。システムテストを行う前には予めクライアントから要件定義書や仕様書が届くため、開発側はこれらを参考にしてテストを進めます。
システムテストの目的
ここではシステムテストを行う目的について詳しく解説します。
システムテストは「クライアントが要求した機能を実装できているか」を検証することを目的としています。システムが実際にリリースされる前には、後ほどご紹介する「受け入れテスト（運用テスト）」の工程がありますが、これはあくまでも発注側の確認作業に過ぎません。
開発側にとってはシステムテストが事実上の最終工程と言えるため、当然システムテスト終了後は納得のいく品質に仕上げ、不具合・バグが全て取り除かれた状態でなければならないのです。
システム開発で行う4つのテスト
それでは、システムテストは具体的にどのような観点で行うのでしょうか。
一般的な開発方法であるウォーターフォール型で進めている場合、単体テスト・結合テスト・システムテスト（総合テスト）・受け入れテスト（ユーザーテスト）の4つの観点から行います。
テストの目的はそれぞれ以下の通りです。
- 単体テスト
機能・操作画面ごとに動作検証を行う。 - 結合テスト
その他の機能・システムと連動させ動作検証を行う。 - システムテスト
運用を想定し、システム全体で動作検証を行う。 - 受け入れテスト
要件定義書や仕様書通りにできているかチェックする。一般的には納品直前に行う。
自動開発を除き、必ず人の手で行われるシステム開発において、バグや不具合が発生しないケースはまずあり得ません。これらを修正し円滑にシステムを納品・リリースするためには上記のテスト工程は必須と言えます。
これらの工程を蔑ろにしてしまうと、細かいバグだけでなく画面の入力チェックミスやデザインのズレといった初歩的なミスまで引き起こしかねません。クライアントからの要件定義書に記載されている要件をシステムが全てクリアするためにも、これら4つの工程は必ず丁寧に行いましょう。
ここからは、これら4つのテストについてさらに詳しく解説していきます。
単体テスト
システムを機能で分割した際、最終的には機能ごとのプログラムに突き詰められます。単体テストは、こういったプログラムごとに行われるテストを指します。システムの構成要素・部品・単位ごとに実施されることから、企業によっては「コンポーネントテスト」や「ユニットテスト」とも呼ばれています。
PMや専任テスターが携わる場合もあれば、これらのモジュールを構築した担当プログラマー・システムエンジニアが一貫して行う場合もあります。単体テストは、単体テスト用の仕様書に沿って行われることが多く、プログラム・モジュールが動作するか、細かい不具合がないかなどを確認します。システムの最小単位に焦点を置くことで、もし不具合が見つかったとしても容易に修正することが可能です。このステップを挟むことで、その後の工程で問題を切り分けるような事態になっても有利に進めることができます。
なお、単体テストに関する詳しい内容は「単体テストとは？メリット・デメリットやテスト手法を詳しく解説」の記事でも解説していますので、併せてご覧ください。
結合テスト
結合テストは、サブシステムとして単体テストを経たプログラム・モジュールを結合し、それらが想定通りに動作するか検証する工程を指します。この工程でも単体テスト同様、専任テスター・プログラマー・システムエンジニアがそれぞれ担当する場合があり、企業によって担当範囲も異なります。
開発計画を練る際に作成する結合テスト用の仕様書に沿って実施され、サブシステムが組まれた状態で単体テストのような形式で動作検証が行われます。したがって、結合テストの目的はサブシステムが結合された状態で不具合なく動作するかを確かめることだと言えます。
プログラム・モジュールが単体テストをクリアしたとしても、組み合わせた場合に想定外のエラーが発生することもあり、結合テストはそれら複合的なバグの早期発見・対処に役立つでしょう。
また、自社内のサブシステムを結合した「内部結合テスト」の他に、外部システムとの連携を想定した「外部結合テスト」を行う場合もあります。
なお、総合テストに関する詳しい内容は「結合テストとは？目的や手法、単体テストとの違いを解説」の記事でも解説していますので、併せてご覧ください。
システムテスト
結合テストを無事通過した後は、全てのプログラムとサブシステムを結合し、そのシステムが全体的に想定した通りに作動するか否かをチェックするシステムテストを行います。
この工程は「総合テスト」とも呼ばれ、エンドユーザーが実際に使用する本番環境、またはそれに準ずる環境にシステムを設置して検証します。システムを包括的にチェックする工程であるため、これまでのテストとは異なり選任のテスターが担当するケースが多く、プログラマーやシステムエンジニアが参加することはほとんどありません。
システムテストは、クライアントと要件や仕様をまとめた際に作成する「システムテスト仕様書」に沿ってウォーターフォール型におけるV字開発モデルで実施されます。「仕様書通りにシステムが操作するか否か」「不具合・搭載漏れが無いか」を満たしているかを確認するために行われるのです。
なお、システムテストはシステムを総合的に作動させる観点から、後述するいくつかの細かいテストに分かれています。
受け入れテスト
開発側のテストが全て終了すると、最後に発注側が行う「受け入れテスト」を経て、システムテストの全工程が終了となります。受け入れテストでは、出来上がったシステムが要件を満たす性能・機能を保持しているかどうかを、発注側であるクライアントが総合的に検証します。総合的に検証するという意味ではシステムテストと同じです。しかしこの場合ユーザーとなるクライアントがテストを行うため、受け入れテストは別名「ユーザーテスト」と呼ばれます。
システムテストの種類
ここからは、先ほどお話したシステムテスト内で構成される検証方法について解説していきます。
システムテストは、主に以下の7つで構成されることが一般的です。
- 機能テスト
- 性能テスト
- 負荷テスト
- ロングランテスト
- セキュリティテスト
- ユーザビリティテスト
- 回帰テスト
これらは全てシステムテストの一環として行われる一方、役割や特徴が大きく異なります。
以降では、それぞれ何が違うのか、より詳しくご紹介します。
機能テスト
システムテストの中でも重要度が高く、クライアントが求める機能が十分搭載されているかを検証するテストが機能テストです。機能面に関して細かい部分をチェックする工程であるため、単体テスト・結合テストの次に実施され、後ほどご紹介する「性能テスト」や「負荷テスト」と一緒に行われるケースが最も一般的です。
機能テストにおいて対象となるものは、単にプログラムだけではなく、機能を表現するUIも含まれています。そのため、この段階では要件定義書の他に機能仕様書なども対象となり、さらには文書化されていない部分もテストの対象になるため、担当者はシステムへの理解が求められます。
機能テストは、システムテスト内でも特に開発ミスが目立つ工程です。そのため蔑ろにしてしまうと「動作が遅い」「想定通り動かない」といった課題を抱えたままユーザーに提供してしまい、エンドユーザーの不満につながってしまう可能性があります。エンドユーザーに満足してもらうためにも、機能テストは入念に行いましょう。
性能テスト
性能テストは、データ処理能力・応答速度・データ容量がどれくらいなのかを検証するテストです。
性能面を図るテストであるため、システムテストの中でも終盤で実施することがほとんどです。エンドユーザーが快適だと思える性能を追求することを目的としているため、実際の環境を想定して合格基準をシビアに定めましょう。
仮想環境では問題なくとも実際にエンドユーザーが使用する環境に置くと動作が想定とズレてしまうことは多々あります。エンドユーザーがストレスを感じることのない快適な性能を目指しましょう。
負荷テスト
快適な性能や高性能な機能ばかりに目を向けてしまうと、システムがアクセスの負荷に耐えられずオーバーフローしてしまう可能性があります。要件定義の段階であらかじめ許容量を定めておかなかった場合、納品後にエンドユーザーに直接損害が出るというケースも考えられます。そのため、システムが不具合を起こすことなく、どの程度の負荷に耐えることができるかを確かめる上で、負荷テストは外せない工程です。
実際に負荷テストを省きシステムを納品してしまうと、不具合が発生した際に原因究明が困難になります。エンドユーザーが抱えるストレスを想定し、負荷テストと同じようにエンドユーザー目線になった確認が必要です。また、その際はアクセスが集中する時としない時の作動具合を、それぞれ検証すると良いでしょう。
ロングランテスト
ロングランテストは、設定した期間内に連続で稼働させ不具合が発生するかを検証するテストです。短期的に稼働できていても、長期間稼働させた際にパフォーマンスが低下してしまうこともあるでしょう。そのため、機能・負荷と合わせて、必ず検証する必要があります。長期間安定してシステム・サービスが稼働するかどうかは、エンドユーザーにとっては非常に重要です。ユーザビリティを向上させるために、必ず丁寧に行いましょう。
ユーザビリティテスト
これまでのテストは、システム的な問題を未然に防ぐことを目的としていました。一方、このユーザビリティテストではシステム改善に焦点を定め、実際にシステムをエンドユーザーに利用してもらうことで、システムの操作感・UI／UX、その他の課題を発見することを目的としています。実際、ユーザビリティテストを行うことで、エンドユーザーが「どんなものに関心を抱いているのか」「何に不満を感じているのか」といった要素が明確になります。そういった数値では図ることのできないデータを収集できることが、このテストの大きなメリットです。
システムやサービスの使いやすさは、エンドユーザーの満足度に直結します。ユーザー視点での心理・行動だけでなく、開発目線では発見できない課題を社内で共有できるユーザビリティテストは、これらを早期発見できる理由から、実施する価値は極めて高いと言えるでしょう。
以前はモニターとしてユーザーを会場に招きテストを行う対面型が主流でしたが、最近では手軽に日程調整ができるリモート型が需要増加の傾向にあります。
セキュリティテスト
情報漏えいや個人情報の流出がニュースになることが増え、情報セキュリティの重要性が問われている昨今、システムテストにおいてセキュリティテストを実施する意義はさらに大きくなってきました。
情報漏洩は、設計ミス・構成エラー・コーディングエラー・脆弱性など、さまざまな要因が引き金になり得ます。セキュリティテストを通じて、脆弱性や不備に気づくことは可能です。しかし、それだけではトロイの木馬やワームといったプログラムを改ざんするウイルスに対抗することはできません。そのため、セキュリティとは別途、ウイルスやバックドアへの対策が必要です。
開発後に弱点が見つかってしまうと、開発前に比べ修正の難易度が格段に上がってしまいます。開発中のシステムをより安全に仕上げるためには、セキュリティテストは必ず何度も行いましょう。
回帰テスト
先程お伝えしたように、単体テスト・結合テスト・システムテストで不具合が生じたら、修正作業が発生します。回帰テストは、プログラム変更後に無事修正できているかを確かめるためのテストです。
システムの規模が大きくなればなるほど、バグや不具合が発生するリスクも増え、それに比例して回帰テストの重要性も大きくなります。実施するタイミングとしては、部分的なミスが修正しやすい単体テスト・結合テスト後や、システムテスト後など、修正が効きやすいテストの直後が良いでしょう。
なお、ミスに対して敏感になりすぎるあまり、回帰テストを必要以上に増やしてしまうと工数が増えて非効率化してしまいます。そのため、あらかじめ回帰テストを行うパターンとタイミングを設定し、チームで共有しておきましょう。
システムテストの流れ
続いて、システムテスト全体がどのような工程で行われるのかご紹介します。
テスト計画
クライアントからの要件定義書を参考に、まずはテスト全体の方針や要件をまとめた「システムテスト計画書」を作成しましょう。計画書を作る際は、システムテストの目的・対象範囲・実施方法・テスト環境・スケジュールなど、テスト全体の方向性を定める必要があります。
テスト設計
次に、作成したシステムテスト計画書をもとに「システムテスト仕様書」を作成しましょう。システムテスト仕様書は、実際に実施するテストの作業内容を細かくまとめたもので、テストデータ・テストケースといった項目のみでなく、各項目を担当するスタッフ、合格点となる評価基準なども決めておかなければなりません。
テスト環境の構築
テスト項目を明確に定めたら、システムテスト仕様書を参考にテスト環境を構築します。本番を想定したマシン・付属ハードウェアを用意し、OS・ハードウェア・ミドルウェアをはじめシステム全体の動作を確認します。当然データもマスターデータ・トランザクションデータといった本番環境に適したものを用意する必要があります。
テスト実行
システムテスト仕様書で策定されたテストを実施します。バグや不具合を発見した場合は、その箇所を修正し、再度テストを行います。
テスト分析
テスト後は分析を行い、想定したテストデータやテストケースで問題なくシステムが動作することを確認したら全工程終了です。要件定義書・システム仕様書と照合し、問題無ければクライアントに引き渡します。
まとめ
今回はシステムテストの目的や種類・手順に焦点を当て、それぞれ詳しくご紹介しましたが、ご理解いただけましたでしょうか。本記事ではウォーターフォール式を想定して解説しましたが、開発方法によって必要となるテスト項目や工数も違います。システムテストを行う際は、自社リソースと要件とのバランスを考えて工数を組みましょう。
開発現場がひっ迫していてテスト工程を効率化したいとお悩みの方は、以下の資料もぜひご覧ください。
