アークウェブのブログ

○テストの種類

テストを実施する意味、目的は大きく２種にわかれます。

１．成果物（ソフトウェア）が要求仕様を正しく満たして動うことを保証する
　　（以下、品質保証テストと記述）
２．成果物に含まれているバグを発見する
　　（以下、バグ出しテストと記述）

前者は「（致命的な）バグがないことを証明するためのテスト」、後者は「バグを発見するためのテスト」と表現することもできます。前者は品質保証（QA）の一環とも考えられます。当然、実施しようとするテストの目的が品質保証を目的としたテストであるのか、バグを叩き出すためのテストであるのかによって採用すべきテスト戦略は異なってきます。以下、それぞれに目的において要求されるテスト、そして自動化の意味、目的を考えてみます。

○品質保証テスト

品質保証を目的としたテスト、その主眼はテストによって機能、つまり要求仕様を満たしているかどうかを確認し、保証することです。そのため、通したテストケースの数が多いほど確認された要求仕様の数や要求仕様を確認した切り口が多いということになります。つまり理想的にはテストケースが多ければ多いほどよいということになります。しかし、現実にはテスト工数、スケジュールは限られています。その中で必要十分な品質保証を行うにはどうするか？その為の手法の一つがリスクベースドテストです。そして、このリスクベースドテストを支援するための一つのツールとして自動化テストが利用できます。構造としては

　品質を保証したい
　　↓
　限られた予算と時間の中で重要な箇所をなるべく多く保証したい
　　↓
　リスクベースドテストを使ってテストケースを設計する
　　↓
　もし自動化できる部分があるなら自動化する

ということです。重要なのは「自動化は最後」ということです。優先度は低です。
※でも、自動化が重要じゃないといっているわけではないので注意してください。

リスクベースドテストについては後述します。

○バグ出しテスト

成果物に含まれているバグを発見するテスト、その主眼はテストによってバグを発見し、修正のワークフローに流すことです。目的の第一義はバグの発見です。そのため、同じバグを発見するために通したテストケースの数が少ないほど効率の良いテストということになります。つまり理想的にはテストケースが可能な限り少ない数で多くのバグを発見できればできるほどよいということになります。では、テストケースの数を絞って、バグを効率良く発見するためにはどうするか？その為の手法として、これまたリスクベースドテストが使えます。自動化テストの位置づけも品質保証を目的としたテストとほぼ同様です。構造としては、

　バグを発見したい
　　↓
　限られた予算と時間の中で重要なバグを効率的に発見したい
　　↓
　リスクベースドテストを使ってテストケースを設計する
　　↓
　もし自動化できる部分があるなら自動化する

ということです。

○リスクベースドテストとは

では、ここでリスクベースドテスト（Risk Based Test）とは何かについて説明します。リスクベースドテストとは簡単にいえば、リスクを分析して、リスクの高い箇所に優先的にテストのリソースを配置するテスト戦略のことです。

ここで言うリスクとは
　・ソフトウェアに欠陥を作り込んでしまう可能性（実現確率）
　・欠陥によって引き起こされる問題の重大性（損害）
のことで、リスクベースドテストではこのリスクの高いものから順にテストを実施して、限られたリソースで最大限の効果をあげることを目指します。

参考：リスク・ベース・テストの効果と限界

また、リスクベースドテストを進めるためには、お客様との間で最終成果物が含みうるリスクについて合意を得ておく必要があります。これによって、リリース基準がリスクの観点から明確になり、合理的にテストの終了を判断できるというメリットもあります。

また、Web開発においてはリスク分析を行ってリスクが高い重要な箇所からテストを進めるリスクベースドテストは
　・リスク分析によりお客様を巻き込む
　・リスクの低い箇所の詳細はあまり見ないのでその箇所の変化には強い
などの特性からアジャイル開発プロセスとの親和性が高いというメリットもあります。

○テストの粒度（リスクベースドテストのそれぞれの適用）

リスクベースドテストは品質保証テスト、バグ出しテストの双方に利用できます。しかし、適用方法において一点注意点があります。それは、前者と後者とでは求められるテストケースの階層が異なるということです(※１)。それは最初に確認したように両者のテストの目的が異なるからです。前者は要求仕様に結びついた顧客視点テストであり、後者は設計に結びついた開発者視点のテストだからです。

そのため、一般に前者は後者よりも各テストケースの階層が高くなり、機能単位となることが多いです。また、後者はタスク以下の単位となることが多いです。また、テストケースの階層が異なるということは、リスクを分析する時の階層も異なるということです。つまり、品質保証テストでは機能単位にリスクを分析し、バグ出しのテストではタスク以下の単位にまでブレークダウンした項目に対してリスク分析を行うことになります。

○それぞれのテストの自動化

品質保証テストとバグ出しテストでは目的が異なることを繰り返し述べました。そして、リスクベースドテストを適用するにおいても、そのリスク分析、テストケースの階層が異なることを述べました。では、それぞれのテストにおいて、テストの自動化はどう目的に資するのでしょうか。詳細は当然プロジェクトの置かれた状況によって異なりますが、一般的な傾向では、品質保証テストではシナリオの自動化、バグ出しテストでは回帰テストの自動化がテストの目的に合致しやすいです。

品質保証テストの場合、要求仕様、機能単位にテストを行いますから、複数の手順、つまりシナリオによってテストケースが表現されることが多いです。そのため、自動化テストに求められるのは、複雑な操作手順を自動化してあげることが主目的になります。Webでいえば、ツールとして前回解説したWWW::MechanizeやSeleniumなどの利用が考えられます。また、全体のテストケース数は品質保証テストの方が多くなる傾向がありますので、大量のテストケースを一気に実行する支援ができれば理想的です。

バグ出しテストの場合、設計単位にテストケースを作成し、バグ発見後の修正、再確認も考慮しなくてはならないため、大量のテストケースの実行よりも細かいテストケースの単位を繰り返し実行できることの方が重要になります。この目的にはJUnitに代表されるxUnit系の単体テストツールなどの利用が考えられます。

○まとめ

自動化テストの細かな技法に踏み込む前段階として、テストの目的、テストの目的に応じた自動化の有様についてまとめてみました。また、リスクベースドテストというテスト戦略の紹介も行いました。
次回以降はリスクベースドテストの実施に必要なリスク分析の方法を紹介し、それからリスクベースドテストのテスト戦略を実施する中で自動化の各手法を解説していこうと思います。

※１
ここで階層という言葉は要求仕様レベル、設計レベル、実装レベルなどのレベルの意味で使っています。粒度（テストケースの細かさ）や数とは異なるので注意してください。