概要・テスト品質を良くするにはテストの目的に合うテストの種類を選ぶ事から
テストはまず目的を決めてその目的に合ったでテストの種類を選ぶ事で品質が良くなる
ソフトのテストの品質を良くするには目的に合ったテストを実施する事が必要です。テストの目的というと漠然としていますが、要するに何を最重視してテストを行うのか、というのがテストの目的です。初版のリリースなら機能の網羅性の確認が最重要ですし、改訂版のリリースなら性能確認や安定性確認が最重要かも知れません、バグ修正版なら当然バグが治っている事とデグレが無い事が最重要です。これらの最重点項目＝テストの目的に合ったテストの種類と選ぶ事が、テストの品質を良くする第一歩です。
ところで、テストの種類にはどんな物があるのでしょうか？ ソフトのテストには、単体テストやシステムテスト、異常系テストや準正常系テスト、RAS機能テストや長期安定性テスト、など色々な名称のテストの種類がありますが、皆さんは実施するテストの種類どう使い分けていますか？ テストの種類にはいろいろありますが、その種類がどんな考えか方から付けられているのか、言い換えれば何を確認するためなのかというテストの目的を意識しておくと、テストの設計をする時にどのテストを採用すれば良いのか迷う事も少なくなります。 ここでは、グータラ親父が使っていたテストの種類について紹介しましょう。
開発フェーズに沿って考えられたテストの種類
一番判り易いのが、ソフトの開発フェーズに沿って付けられた種類です。ウォーターフォールモデルやＶ字モデルでよく使うテストの種類ですね。単体テスト、結合テスト、システムテスト という種類が一般的です。このテストの種類は一般的なので使いやすいのですが、実は組織によってその定義が微妙に異なっている事があるので注意が必要です。特に単体テストは、組織が違うと結構その定義が異なる事があるので、他の組織と一緒にソフト開発を進める時には、最初に定義の確認をしておく事をお勧めします。
ソースコードの作りから考えられたテストの種類
つぎに良く使うのが、正常系、準正常系、異常系というソースコードの作りからつけられた種類です。正常な入力が与えられた時の動作が設計どおりになっているかどうかを確認するのが正常系テストです。設計時に考え付いたエラーの状態が起きた時にその状態に対応するエラー処理が正しく動作する事を確認するのが準正常系テストです。設計時に考えていなかったよう異常が起きた時でもソフトが動作を続ける事を確認するのが異常系テストです。準正常系テストはエラーが起きている状態でのテストなので異常系テストに含めてしまうという考えもあるので、異常系テストの定義の確認は大切です。
個々の機能の確認のために考えられたテストの種類
ソフトに搭載される機能は機能要件として要求仕様書や要件定義書に書かれています。あらゆるものがネットに繋がる事を求められる最近のソフト開発では、常に安定して動き続ける事の重要性が高くなってきました。そこでテストについても、機能要件の中の RAC機能とセキュリティについてのテストの重要性が高まってきています。RAS機能のテストは、Reliability(信頼性）, Availability（可用性） Serviceability （保守性）についてのテストで装置そのものが安定して動作する事の確認が目的です。セキュリティテストは外部からの攻撃に対して装置を守る能力についてのテストです。ネットに繋がっているという事は常にサイバー攻撃を受けるリスクがあるので、簡単に乗っ取られて踏み台にされたりしないようなソフトになっているのか、を確認する事が目的です。
システムテストカテゴリによるテストの種類
ソフトの品質を保証するために一番大切なテストはシステムテストです。このシステムテストもいろいろな目的でテストの中身をされに具体的に考える事が大切なのですが、その時にグータラ親父参考にしていたのは、The Art of Software Testing という本の Chapter6 に書いてある 15種類のシステムテストカテゴリの種類です。この本では、システムテストを テスト目的に沿って以下の15種類に分類して、テストの種類に名前を付けてその内容を定義しています。
Facility Testing, Volume testing, Stress Testing, Usability Testing, Security Testing, Performance Testing, Storage Testing, Configuration Testing, Compatibility Testing, Installability Testing, Reliability Testing, Recovery Testing, Serviceability Testing, Documentation Testing, Procedure Testing
この本は 1979年に初版が発行された40年以上も昔の本ですが、ソフトのテストをその実践の面からとても判り易く書いてあり、またテストの概念自体は40年前も今も大きくは変わっていないので、今読んでもとても役に立つ本です。実際に、現在までに第３版まで改版され、アジャイルやモバイルについての記述も加筆されています。
この本が書かれた頃のソフトは大型コンピュータシステムの上で稼働する企業の基幹システムが主体だったので、システムテストカテゴリも今の組み込みソフトには少し使いにくい面があります。グータラ親父は、このシステムテストカテゴリからいくつか取捨選択し、物によって組み込みソフトに合わせて定義を読み替えたりして使っていました。
設計検証と妥当性確認という分類
テストの種類のもう一つ外側の概念になりますが、設計検証テストと妥当性確認テストというテストの分類の名称もテストを考える時に意識しておく必要があります。設計検証と妥当性確認と略して呼ぶ事もありますが、英語にすると Design Verification Test と Validation Test ですね。
設計検証テストは、設計した内容が実行ソフトに確かに実装されて、設計された通りに動いているかを確認するテストです。要求仕様書や要件定義書に書かれた機能要件や非機能要件が、実際に動作するソフトの搭載されているのかを、様々なテストを用いて確認します。言い方を変えると、設計や実装が正しく行われている事を確認する事を目的としたテストですので、要求仕様に無い項目の確認はしません。
これに対して、妥当性確認テストは製品として妥当かどうかを確認します。その製品を実際に使うユーザの立場にたって、機能や性能や安定性や使い勝手に問題は無いかとい視点で製品をテストします。ですので、要求仕様書に書かれていなような項目、例えば「操作手順を示すGUIのデザインが統一されてなくて、どこをどう触れば良いのか判り難い」というような問題点が妥当性確認テストで不具合として検出される事もあります。
潜在バグの検出とバグが無い事の保証というテストの分類
テストは２つの目的をもっています、ソフトのデバッグ作業の一環として潜在バグを見つけ出すという目的と、ソフトの品質保証の一環としてバグが残って居ない事を保証するという目的です。開発組織によっては、潜在バグを見つけるためのテストは設計・実装を担う開発部門が行い、バグが残っていない事を保証するためのテスト品質保証部門が行う、というように実施する部門を分けてい事もあります。
ソフト開発が実装フェーズからテストフェーズに移行した最初の頃は、潜在バグを見つけ出すという目的に重点を置くテスト行われます。テストはできるだけ多くのバグを早い段階で見つけ出して、設計・実装担当者によるデバッグサイクルを回して、ソフトの品質を良くする作業を支えます。ソフト開発の最終段階のリリースの直前には、もうバグが残っていない事を確認し品質を保証するためのテストが行われます。テストでバグが見つからない事をもってソフトの品質が保証できたと判断して、そのソフトのリリースを許可するというルールで運用される事もよくあります。
同値分割と境界値分析とパス網羅
これはテストの種類ではなくテスト条件の洗い出しの方法やテストの方法の名称ですが、同値分割と境界値分析という名称と命令網羅（C0網羅）、分岐網羅（C1網羅）、条件網羅（C2網羅）という名称もテストを設計する時によく出てきますので、ここでも少し紹介しておきます。
同値分割と境界値分析は、インプットの値に着目してテスト条件を選定する方法につけられた名称です。どちらも、テストの時に与える入力値を決める時の方法です。 同値分割は、入力値を同じ意味を持つ値の集団に分けて、その中から代表的な値を１つずつ選びだす方法です。境界値分析は、同値分割した時の２つの集団の境目になる値とその前後の値をテスト用の値として選び出す方法です。
命令網羅、分岐網羅、条件網羅はプログラムコードが実行されたかどうかを確認するコードのパステストにおいて、どんなテスト条件を満たせば全ての場合を網羅したと判断するのか、という網羅率の判断の方法に付けられた名称です。命令網羅は、全ての命令コードが少なくとも１回実行されれば網羅率 100% とします。分岐網羅は、全ての分岐コードが少なくとも１回実行されれば網羅率 100% とします。条件網羅は、全ての条件分岐の組み合わせを実施する事で網羅率 100% とします。
どのテストを行うかそれが大切
テストの種類にはここで紹介した以外にも色々なものが在ります。どの種類のテストを行うのかを決める時には、その種類のテストがどんな考え方で何を確認する事を目的としたテストなのかを意識しておくと、どのテストを採用するのか迷う事が少なくなります。 各々のテストについては個別の記事で順番に詳しく紹介していく予定ですが、全ての記事が揃うのが何時になるかはまだ判りません。 すみませんが、今暫くお待ちください。