システムテスト（総合テストとも言う）は、システム開発プロジェクトの工程で、ベンダー側の最終テスト工程である。
最終テスト工程のため、開発したシステムが顧客の要件を満足しているかどうかを検証することがポイントとなる。
しかしながら、プロジェクトの経験が浅いようだと、システムテストの観点やテストの種類について悩むだろう。
私も今でこそ、10年以上のプロジェクトマネージャ経験があるものの、新人の頃はシステムテストに悩んだものだ。
そこで今回は、システムテストの目的や観点といった基本的なことを中心に説明していこう。
目次
システムテストの目的
まず最初にシステムテスト（総合テストと呼ぶ場合もある）の目的を説明しておこう。
システムテストとは、システム開発会社（ベンダー）側の最終テスト工程である。
システムが本番化されるまでには、発注側の受け入れテスト（運用テストとも言う）が残っているものの、このテストは発注側の確認用のテストであるため、開発側としてはシステムテストが最終テスト工程となる。
当然ながら、システムテストが終了したシステムは、「品質に不備はない」と胸を張って言える状態でなけらばならない。
すなわち、システムテストの目的は、”システム全体が発注側の要求した機能や性能を満たしていることを検証すること“である。
システムテストの観点
システムテストの目的は、”発注側の要求を満足していること”を検証することだが、具体的にどのような観点でテストをするのだろうか？
実際のプロジェクトで起こりがちなのは、画面の入力チェックだったり、画面の機能だったりを全て検証しようとするケースである。
つまり、”発注側の要求を満足する ＝ 全機能を検証する” としてしまうケースだ。
全機能を検証することは間違ってはいないのだが、単体テストのようなことをシステムテストでやっても意味がない。
意味がないというのは、単体テストと同じことをしても、新しい不具合を検出できずに、品質を向上することができないということだ。
だったら、システムテストはどういう観点で実施するのか？
明確な答えがある。
それは、要件定義書に記載していることを満足しているかどうかを検証していけばいいのである。
要件定義書は、発注側の要求をまとめた書類である。
すなわち、発注側の要求はすべて要件定義書に記載されている。
よって、システムテストは、要件定義書に書かれている要件をシステムが満足できているか、という観点で実施する。
例えば、単体テストや結合テストは、システムを構成するプログラムに着目してテストを実施する。
これに対してシステムテストは、ハードウェアや利用者といった要素を加えて動作したときに発生する総合的な問題を検出するのだ。
・操作マニュアル
・利用者への教育
・ヘルプの内容
・ユーザビリティ
・トラブルシューティング
などなど
システムテストの種類
システムテストは、”要件定義書の要件を満足できているか“という観点で実施する。
具体的なテストの種類を紹介しておこう。
①機能テスト
文字通り、発注側の要求した機能が実装されていることを検証する。
業務フローに沿ったテストケースを作成して一連の機能をつなげて実施するのが一般的だ。
②性能テスト
要件定義書に記載した性能要件を満足していることを検証する。
性能要件を明確に規定していない危ないプロジェクトもあるが、その場合はシステムテストの計画書を作る際に、発注側に確認した方がいいだろう。
ちなみに、性能要件は”非機能要件”の1つである。
非機能要件については、下記の記事をご覧いただきたい。
また、障害復旧テストもこの種類に含まれる。
（システム異常を発生させ、復旧作業が要求の時間内で実施できるかを検証する）
③ユーザビリティテスト
システムの利用者にとって、使いやすいシステムであるかどうかを検証する。
具体的には、要件定義書に記載している機能毎の利用者を元に、システム操作を想定したテストケースを設定する。
例えば、パソコンの操作に慣れていない利用者がいる場合は、システムの起動方法から検証していく。
逆に、ベテランの利用者がいる場合は、複数の機能を同時に実行するといったようなケースも想定される。
もちろん、開発者側は実際の利用者ではないため、テストケースを想定するには限界があるだろう。
（漏れたケースは、後続フェーズの”運用テスト”で検出されることを願うしかない…）
④セキュリティテスト
要件定義書に記載したセキュリティ要件を満足していることを検証する。
性能テストと同様に、こちらも”非機能要件”の1つだ。
・ユーザー毎のシステム利用権限が反映されているか？
・パスワード失効時の対応が可能か？
・悪意のあるjavascriptが実行されないか？（クロスサイトスクリプティング検証）
・悪意のあるSQLが実行されないか？（SQLインジェクション検証）
など
⑤回帰テスト（リグレッションテスト）
現行機能保証と呼んだ方が分かりやすいだろう。
あるシステムに機能を追加した場合、それ以外の機能が現行通りに動作していることを検証する。
現行の全機能を検証するとなると膨大な作業になってしまうため、システム開発のスコープから適切なテスト範囲を設定する。
テスト範囲の設定に悩む場合が多いが、改修が影響しそうなシステムをキーワード検索などで洗い出し、ベテラン社員のレビューを受けて範囲を設定する場合が一般的だろう。
システムテスト仕様書に記載すべき項目
システムテストを実施する際には、システムテスト仕様書（計画書と呼んだりもする）を作成するのが一般的だ。
プロジェクトメンバーとの意思疎通を測ったり、テスト観点やテストケースの抜け漏れをレビューする。
ここでは記載項目を紹介しよう。
テスト概要
はじめから細かい内容を書いてしまうと、付いてこれない人が続出するため、今回のシステムテスト実施することををざっくりと記載する。
テストの実施環境
ハードウェアやソフトウェアなど、どのような環境でテストをするのかを記載する。
本番環境に近い環境でテストをすることが望まれる。
テストケース
機能テスト／性能テスト／ユーザビリティテスト／セキュリティテスト／回帰テストなどの種類をベースにし、どのようなテストを実施するのか、どのような結果が得られればOKなのかを記載する。
テスト手順
テストケースをどのような順番で実施するのかを記載する。
“どんなデータを用いるのか”という点についても記載しておいた方がいいだろう。
テスト実施担当者
テストを実施する人。
複数名いる場合は、主担当者が分かるようにしておくと放置される危険が少なくなる。
テスト結果確認者
テスト結果を確認する人。
思い込みをしないように、テスト実施担当者とは違う人にすることが望ましい。
テストの体制
ベンダー内のテスト実施体制を中心に記載する。
テストスケジュール
システムテストの実施スケジュールを記載する。
テスト仕様書のレビュー、テスト環境の構築、テストデータの用意などのタスクを洗い出し、スケジュールに落とし込む。
システムテスト実施中にデータが削除されるような事態にならないように、スケジュールは関係者間で共有すべきだろう。
システムテストで不具合を検出した場合
システムテストで不具合を検出した場合は、課題管理台帳に記載する。
不具合管理台帳やら障害管理台帳やら呼び方は様々だが、本質的にやっていることは変わらない。
記載内容は下記の記事を参考にしてほしい。
現場でやりがちなのは、不具合を検出した後、改修作業に入ってシステムテストを中断してしまうケースだ。
これは良くない。
他のテストケースでも不具合が検出される可能性も大いにあるため、一連のテストを実施してから改修作業に着手した方がいいだろう。
改修作業をまとめて実施できたり、もっと重要な不具合を検出できる場合もあるからだ。
なお、全ての不具合を改修できるのがベストだが、状況によっては軽微な不具合を抱えたままで次の工程に進む場合もある。
（多くの場合は、本番時期に差し迫っているような状況で、運用テストで別の機能の検証をしている間に、並行して改修作業実施するようなケース）
さいごに
システムテストの目的や観点、テストの種類などについて記載してきた。
システムテストは開発側の最終テストということもあり、機能面以外で検証する観点が多い。
つまり、非機能要件に対する検証するテストケースが多いのだが、非機能要件に苦手意識を持っているエンジニアが多いため、十分に不具合を検出できなかったり、そもそも非機能要件のテストが漏れてしまうプロジェクトもある。
最悪、機能要件は発注側の運用テストで気づく場合もあるだろうが、非機能要件については発注側ではほぼ気づかない。
システムテストを実施する際は、機能要件だけでなく、非機能要件に対するテストについても十分検討するようにしてほしい。
この記事が参考になれば幸いだ。
非機能要件の記事はこちら。
テスト関係の記事はこちら。
コメントを残す