テストの種類・単体テストと結合テストとシステムテスト
システムテストはソフトが動かない条件を見つけるテスト
ソフトに全ての機能が組み込まれ、単体テスト・結合テストが終われば最後にシステムテストを行います。ソフトの規模が小さい場合には、結合テストが省略される場合もありますが、システムテストが省略される事はありません。小規模なバグ修正だけを行ったソフトの場合には、修正確認と基本機能の確認テスト（サニティテストと呼ぶ事もあります）だけで済ます事はありますが、新規開発や機能追加開発の場合には、システムテストは必須です。
システムテストは、テスト環境の準備やテストに必要な工数も大きテスト技術も必要になるので、ソフトの設計・実装チームとは別にテストを専門に行うテストチームで実施される事が多いです。品質保証部門の中にソフトの品質を保証する機能がある場合には、テストチームが品質保証部門に所属する事がありますし、品質保証部部門が製造品質のみを見ている場合には、ソフトの品質は設計部門が保証する事になるので、テストチームも設計部門に所属する事になります。
システムテストの目的は色々な考え方がありますが、組み込み系のソフトではソフトが動かない場合を見つける事を目的とすると、システムテストの設計や実行がやり易くなります。ソフトが動かない場合を見つける、というのはどういう事かというと、何等かの入力の値や入力のタイミングや動作環境や負荷条件や他システムとの連携など、実際にソフトが使われる本番環境で起きる事が予想されるいろいろな状態を想定して、ソフトが正常な動作をしなくなるような場面＝潜在バグを見つけ出すという事です。
ソフトが動かない場合を見つける事を目的としたシステムテストを実施して、何件かバグが見つかればそれはこれまでの単体テストや結合テストの環境やテスト方法では見つけられなかった潜在バグを見つけた事になりますし、システムテストでバグが見つからなければ、本番環境を想定したテストでバグが無かったという事なので、ソフトの品質を保証した事になります。
システムテストはテスト計画を使ったテスト管理が大切
システムテストは、テストの規模も大きくなるので、しっかりとテストの実施計画を作ってテスト管理をしながらテスト作業を進める事が大切です。システムテストでは誰が・何時・どんな機材とどのテスト環境を使って・どのテストを実施するのか、というテスト資源のスケジュール調整をしっかりしないと、あちこちでテストの実施待ちが起きてしまいます。 また、ソフトの品質が不十分なままシステムテストが始まると、バグのためにテストが先に進まなくなりある塊のテストがバグ修正版のソフトがリリースされるまで手を付けられない、というような計画にはない工程の応遅れも起きます。ですので、システムテストではテストの実施計画を見ながら常にテストの実際の進捗状況を確認して、必要なら実施計画を見直すという進捗管理が大切になってきます。
システムテストのテスト設計では、いろいろなテストの目的に沿って必要な設計を行って、漏れなくテストを実施していくという考え方で設計されます。（探索的テストとの対の言葉として記述的テストと呼ばれる事もあります） ただし、ソフトが動かない場合を見付けるという目的でテスト設計を進めると、色々な環境や条件の組み合わせを考える必要がでてきて、すぐにテストケースの爆発が起きてしまいます。
テストケースを洗い出すテスト設計の中では、テストケースが爆発しないように必要性の低い組み合わせを切り捨てる作業も進める事になるので、どうしてもテストケースの網羅性が不足するというリスクが残ってしまいます。 そのような場合には、不安がある箇所に対して探索的テストを織り込む事で、少しでもリスクを下げる事ができます。 ですので、システムテストには一定の割合で探索的なテストを入れておくといもの、ひとつの手です。
システムテストの成果は潜在バグの発見とバグが無い事
システムテストの目的がソフトが動かない場合を見付ける事なので、システムテストの成果は潜在バグの発見です。ですが、システムテストは設計検証テストの最終段階でもあるので、もう潜在バグが残っていないことの証明、言い合えると品質保証の根拠としての役目も持つことが多いです。
この場合にはシステムテストを複数行う事として、最初のシステムテストでは潜在バグを見付けて、見つけたバグを設計部門にフィードバックしてバグを取り除いたソフトに仕上げるデバッグサイクルを回します。何度かデバッグサイクルを回して十分にバグが修正されたら、最後にもう一度システムテストを行い、バグが１つも検出されない事を確認して、ソフトの品質が保証されたとしてリリース審査に進める、という２段階のシステムテストを行う事もあります。もちろん、そこまでシステうテストに時間と工数を掛けられない開発プロジェクトの場合には、バグ修正版のソフトに対しては修正内容の確認と二次不具合確認のテストだけを行って、ソフトのリリース判定に進めるという方法を使う事もあります。
システムテストの実際はデスマーチの中
ここまでは、理想的なシステムテストについて書いてきました。しかし実際の開発プロジェクトでは、このような理想的なシステムテストが実施できる事は余り多くはありません。グータラ親父の経験では残念ながらこんな理想的な場面殆ど無くて、たいていのソフト開発では仕様変更の嵐に見舞われ、それでも当初の納期は変わらないたえに設計・実装の工程が後ろ倒しになって、システムテストの開始時にはやっと機能が一通り実装されたばかりで結合テストもまだ十分にできていない、でも納期は近いので今からシステムテストを開始しないと間に合わない、というデスマーチ真っただ中の場合が多かったです。
そのために、システムテストの前半では正常系テストでのバグや、準正常系や異常系の簡単な条件でのバグが多数見つかって、大量のバグを設計部門にフィードバックして、バグ修正されたソフトでシステムテストを繰り返す、という状況になります。この状況では、実はシステムテストと言いつつ、その前段階のデバッグ作業をテストの面から支援しているというのが正しいのですが、デスマーチに突入したプロジェクトではそんな事を言ってる暇はなく、全員が一丸となってバグと戦うしか進む道はありません。
まあ、デスマーチのプロジェクトでも何度かバグ修正サイクルを繰り返していけば、ソフトの品質は徐々に上がっていきます。そしてシステムテストの後半ではいよいよ、複雑な条件の組み合わせで起こるバグや、高負荷の時にだけ起きるバグや、ノイズ環境で長時間動かしていると起きるバグ、のようなソフトが動かない場合に相当するバグがちらほら出始めます。ここまでくれば、あとは時間の許す限りバグ修正とシステムテストを繰り返し、リリースに向けて品質を上げていく段階になり、長かったデスマーチの出口が見えてきます。
ここまで開発フェーズに沿ったテストの名前いについて書いてきました。 次の記事では正常系テスト、異常系テスト、正常系テストについて紹介します。