システムテストの基礎
システムテストとは
システムテストとは、どのようなテストなのでしょうか。一般的に読者の方々が持っているイメージは以下のようなものではないでしょうか。
- 開発の最終フェーズで行うテスト
- プログラムとハードウエアも含めた、お客様が使うシステム全体としてのテスト
- 機能、性能、運用性など複数の視点における個々テストの集まりであるテスト
ここでは、システムテストとは何かについて、もう少し具体的に考えてみましょう。
まず、JSTQBのシラバス日本語版に記載されているシステムテストの定義の一部を引用します。
システムテストは、テストで見つけられない環境関連の故障が残存するリスクを最小限にするため、最終的なターゲットや運用もしくは使用する環境と可能な限り同じテスト環境で行わなければならない。
システムテストには、リスク、または ビジネスプロセス、ユースケース、その他システム動作を高レベルで記述したテキストもしくはモデル、オペレーティングシステムとの相互作用、システムリソースなどの要求仕様に基づいたテストがある。
この定義は、先述のイメージとほぼ同等ではないかと思われます。
では、システムテストにおいて考慮しなければならない観点は何でしょうか？ お客様が最終的に使うシステムであるため、シラバスに記載されているように、ビジネスプロセルやユースケースに基づいてテストするのは比較的わかりやすいかと思います。しかし、オペレーティングシステムとの相互作用、システムリソースなどの要求仕様に基づいたテスト、と定義されると、具体的にイメージしづらいのではないでしょうか。
ご存知の方も多いと思いますが、ISO9126には品質モデル（Quality model）の定義があります。「システムテストで何をするか」を検討するための土台としては、この品質モデルと、そこで定義されている品質特性を使うのが最も確実な選択だと考えます。
もちろん、ここで定義されている品質特性の全てをシステムテストで網羅しなければならないのではありません。テストの戦略策定に関する話題となるため、本稿では詳しくは記載しませんが、単純化すると以下のようなステップで、各テストで行うべき内容を決定し、各テストの組み合わせで、全体として漏れの少ないテストを実施する、とだけは述べておきましょう。
- お客様の要求をもとに、求められる品質を、品質特性の形でマッピングする。
- マッピングされた品質特性をもとに、各テストフェーズでカバーする領域と深さを定義する。
- この定義を基準にして、各テストフェーズのケースケースを設計する。
ここのステップ２で、システムテストでカバーする領域を定義します。システムテストだけで全てを網羅するようなテストを設計するのではなく、他のレベルのテストも含めることで網羅するよう戦略を立てて、適材適所でテストを行うべきでしょう。システムテストでは、詳細な項目チェックを行うよりも、全体を俯瞰するテストが望ましいといえます。しかしながら、全体を俯瞰して見る必要があるため、システムテストの守備範囲が広域にわたるのは避けられないのは事実です。
システムテストで実施するテスト
では、実施するシステムテストには、どのようなものがあるでしょうか。また、どの項目について実施すればよいのでしょうか。
ISO9126の品質特性をベースに考えてみましょう。ISO9126の品質特性では、以下の主特性が定義されています。
- 機能性（functionality）
- 信頼性（reliability）
- 使用性（usability）
- 効率性（efficiency）
- 保守性（maintainability）
- 移植性（portability）
これらの主特性がもつ副特性の一部について、システムテストでの役割を考えてみましょう。
なお、ここでの説明は一例であり、実際にはテスト戦略策定時にシステムの特性に合わせて詳細に検討を行うべきものです。
（注意：ここでの各特性の説明については筆者の認識であり、必要に応じてISOの原文を参照してください）
機能性（functionality）
1. 合目的性（suitability）
お客様がシステムに対して求める目的に、適合しているかどうかの指標です。
システムテストを実施する上では欠かしてはならない特性だと考えます。 同時に、正しくお客様の目的を理解していないと、テスト設計が行えないということであり、お客様が求めていること、お客様に対してシステムが提供する価値に対して正しい認識をすること、がシステムテストにおけるスタート地点となります。
2. 正確性（accuracy）
入力に対して常に期待する出力をするかどうかの指標です。
個々の機能に関しての正確性は、システムテスト以前のテストで網羅されていると思いますが、本番環境でそれらが正しく動作しているかを確認する意味で、必要なテストになります。つまり、システムテストでフォーカスすべきは、個別の機能単体の動作ではなく、環境設定などを含んだ本番システムとして期待通りに動作するかどうかという点であり、それを確認するようなテストを行うべきです。
3. 相互運用性（interoperability）
他システムとの連携が期待通りに行えるかどうかの指標です。
単独で動作するシステムの場合には考慮する必要がないかもしれません。しかし、業務システムのように、他のシステムとの連携が必須な場合には、考慮しなければならないテストになります。ただし、行うべきは他システムとの連携のタイミングやデータ転送の設定などのテストであって、連携するデータ自体のテストなどについては、もっと前のテストフェーズで行うべきです。
4. 機密性（security）
許可されたユーザのみが必要なデータにアクセスできるかどうかの指標です。
おそらく同種のテストは既に行われている場合もありますが、システム全体として必要なセキュリティ要件を満たしているかどうかを確認するのは、システムテストの役割になります。また、システムの要求されるセキュリティ要件はさまざまですから、それに合わせたテスト内容の検討が必要です。 例えば、社内でのみ使われるシステムと、社外に向けたシステムでは、大きくセキュリティ要件が異なるのが普通です。
信頼性（reliability）
1. 成熟性（maturity）
システムが時間経過と共に、どの程度安定して動作するかの指標です。
機能テストや、結合テストでは、システム全体としての動作確認は行っていませんから、ハードウエア等を含めて、システムとしての安定性を見るようなテストを行う必要があります。たとえば、長期運用が必要なシステムで、メモリー消費量が増え続けていけば、ある時点でシステムに重大な影響を与えるかもしれません。システムの稼働時間に対する問題を見つけられるようにシステムテストを設計する必要があります。 逆に、連続稼働時間が限られているようなシステムの場合には、その範囲内でのテストを設計すればよいともいえます。
2. 障害許容性（fault tolerance）
システムのコンポーネントに障害が発生した場合に、どの程度許容して安定動作するかの指標です。
一般的には、ハードウエアの障害に対応するために冗長構成をとることが多くみられます。その場合に各ハードウエアを強制的に停止させて、システムが正しく動作することを検証するのがここでのテストです。これは、まさしくシステムテストで行うものです。また、ハードウエアだけではなく、プログラムの障害でプロセスが停止した場合などのことも考慮して、テスト設計は行われるべきです。 ただし、設計段階で事前に検証を行った上で、その仕組みが正しく動作することの最終確認であることも忘れないでおきましょう。
3. 回復性（recoverability）
発生した障害からの回復に関する指標です。
障害許容性が障害に対する耐性を図るものに対して、こちらは、起きてしまった障害からどうやって復旧するか、に主眼を置いたテストのことです。このテストも設計段階で事前検証されるべきものですが、その仕組みが正しく動作することの最終確認にあたるテストです。
使用性（Usability）
理解性（understandability）、習得性（learnability）、運用性（operability）
システムを利用する上での各ユーザの視点での指標です。
さまざまな角度からのユーザビリティを図るテストです。プロトタイプなどを作った場合には、その時点である程度の評価は済んでいるかと思いますが、最終的なシステムとしてのユーザビリティを図るテストを指します。 また、複数のシステム間連携がある場合には、機能性の相互運用性などを考慮した上でテストの組み立てを行う必要があります。
効率性（Efficiency）
時間効率性（time behavior）
時間を軸にしたシステムの効率に関する指標です。
重要な項目であるパフォーマンスに関したテストがこの副特性に該当します。また、システムのパフォーマンスは設計段階できちんと考慮しておかないと、パフォーマンスが悪いからといって、簡単に改善できるものではありません。とはいえ、この段階にならないとテストできない場合が多いため、事前の検討をちゃんと行ってから実施する必要があります。
保守性（Maintainability）と移植性（Portability）については、システムテストでの対象というより開発段階で検討し、実装すべき項目となるためここでは割愛します。 なお、機能テストおよび性能テスト、ユーザビリティテストなどについては、別途、記事が掲載される予定ですので、詳細についてはそちらを御参照下さい。
システムテストはいつ始めるか？
システムテストの考え方については把握していただけたかと思います。では、システムテストのアクティビティはいつ始めればよいのでしょうか？ 一般的なケースとしては、結合テストの終了後に、遅延なくシステムテストが実行できるよう結合テストフェーズあるいは、もう少し前の時期からスケジュールを組むのではないでしょうか。あるいは、その時期に始めることが組織の標準プロセスとして定義されているのではないでしょうか。
では、もう一度、「ソフトウェアテストの基礎：ソフトウェアテストの7原則」で使われていた「Wモデル」を見直してみましょう。
この図をよく見ると、システムテストの計画（Planning System Testing）は、要件（Requirement）と仕様（Specification）を入力とするアクティビティです。確かにシステムテストの実行（Executing System Testing）は、結合テストの実行（Executing Integration Testing）の後のアクティビティです。しかし、システムテストの計画を開始する時期はいつでしょうか。
つまり、この図からもわかるように、システムテストの計画を行うのに理想的なのは、基本設計を行っている時です。問題の発生から発見までの時間が短ければ短いほど修正コストが少ない、ということはよくご存じだと思います。要件、基本設計をインプットとして、システムテストの計画をたてて、実際にシステムテストのテストケースを作るために分析することで、要件や基本設計に含まれている問題を早期に発見することができます。
仮に、同一の問題がシステムテストの実行フェーズで発見された時のことを考えてみて下さい。その修正にかかるコストはどれくらいでしょうか？
下記にある調査資料の抜粋を記載します。
If it costs $1 to fix a defect found in the requirements phase, it costs $2.40 in the design phase, $5.70 in coding, $18.20 in testing, and $109 if the requirements defect was not found until the product was released into operation. 出典：W. Charles Slavin. Software Peer Reviews: An Executive Overview. Cincinnati SPIN. January 9, 2007. Available at www.cincinnatispin.com/1_2008.ppt.
ここでは、漠然とテストフェーズとしか記載されていません。しかし、同じテストフェーズでも、システムテストの段階であれば、ここで挙げられている数値より大きくなるのは、容易に想像できることではないでしょうか。確かに、システムテストの実行自体は対象となるシステムを必要としますが、システムテストの計画は、要件定義や基本設計と並行して実施できるものなのです。つまり、その時点で問題を発見できれば、それだけコストを抑えることができるのです。 また、システムがなくても工夫をすれば、システムテストの一部（おもに機能性テスト）は机上で行うことも可能です。つまり、ホワイトボードや模造紙、付箋、マーカーなどを使って、要件定義書や、基本設計書を片手にテストを実行してみればよいのです。 そこで問題を見つけることができたら、どれだけ修正コストを抑えることができるでしょうか。つまり早期発見によって、システムの品質が向上するのです。
このことを踏まえて、プロジェクトの中でのシステムテストに対するアクティビティを検討してみてはいかがでしょうか？ テストの実行だけが、問題を洗い出す行為ではありません。テストの計画、設計といった行為でも問題を洗い出すことが可能であり、システムテストの計画、設計は、要件、基本設計という、システムの根幹に潜む問題を顕在化することができることを、意識してみて下さい。
参考文献：
テスト技術者資格制度 Foundation Level シラバス 日本語版
© International Software Testing Qualifications Board VER2011
© 日本語翻訳版Japan Software Testing Qualifications Board Version 2011.J02, ソフトウェアテスト標準用語集（日本語版）Version 2.0.J02 (2011年04月19日)
International Software Testing Qualifications Board 用語集作業班
執筆者プロフィール 吉村 好廣
外資系コンピュータメーカーに入社し、ハードウエアからソフトウエアまで幅広く開発の経験を積む。その中で様々なレベルのテストを経験する。独立後、テストをキーワードにプロジェクトを渡り歩くフリーランスのエンジニア。Androidテスト部、自動化テスト研究会等の活動の中でさらに切磋琢磨し腕を磨き続ける。
