テストの種類：テストはデバックのためそれとも品質保証のため？
テストでバグを見付けるかバグが無い事を保証するか
ソフトのテストは、デバッグのために行うテストと、品質を保証するために行うテストの２つに大きく分けられます。どちらも同じテストで、実施する時期によってテストの主な目的が変わっていくのですが、主な目的が変わればテストの設計や実施でどこに重点を置くのかも変わってきます。
デバッグのためのテストでは、あの手この手で潜在するバグを見つけ出して、見つけたバグをデバッグ作業でソースコードから取り除く事で、ソフトの品質を高めていきます。品質保証のためのテストでは、様々な観点からテストを行って、どれだけテストをしてもバグが見つからないのだからこのソフトには潜在バグが残っていないと推測する事でソフトの品質を保証します。
デバッグのためのテストも品質保証のためのテストも同じテストなので、うまく整理しておかないと考えが混乱してしまいます。この記事ではグータラ親父が行っていたこの２つのテストの整理の仕方と注意点を紹介します。
テストの前半はデバッグのためでテストの終盤は品質保証のため
テストの実施時期という観点で見ると、デバッグのためのテストは単体テストを開始した時期からシステムテストの中盤くらいまでに実施され、品質保証のためのテストはシステムテストの終盤にかけて、実施されます。 またテストを誰が実施するかという観点では、デバックのためのテストはソフトの設計や実装を行ったソフトエンジニアが行う事が多いですが、品質保証のためのテストはテスト専門のチームに所属するテストエンジニアが行う事が多いです。
デバッグのためのテストも品質保証のためのテストも、どちらもソフトのテストなのでテスト設計やテスト実施などのテストプロセスには違いなありません。でもテストの主な目的が違うのでテスト設計の内容ですこし注意点が違ってきます。
デバッグのためのテストはバグの効率的な検出に注力
デバッグのためのテストでは、デバッグサイクルを効率的に回す事が大切です。できるだけ早い時期から多くの潜在バグを見つけ出して、重要性の高いバグから優先的にデバッグ作業を勧められるようなテストの工程計画が必要になります。とはいえ、潜在するバグの数はデバッグサイクルが進むに従って減っていき、新しいバグの発見もだんだんと難しくなっていきます。ですので、デバッグサイクルが前半・中盤・終盤と進むに従って、テストの進め方を変えていくのが良い方法です。
デバッグの前半では正常系と準正常系を網羅的に
デバッグサイクルの前半ではまだまだ多数のバグが潜在しているので、テストをすればボロボロとバグが見つかります。場合によっては、あるバグがあるために、その後のテスト工程に進めないというようなバグによるテストのブロッキングの状況も発生します。ですので、この時期にはまず、正常系と準正常系のテストを網羅的に進めて、簡単に見つかるバグを見付けてデバッグで取り除いてく事が重要になります。簡単に見つかるバグをまずは修正してしまい、ある程度はテストに耐えられるレベルのソフト品質を確保して初めて、中盤以降のテストが実施できるというのが現実です。
デバッグの中盤からは探索的テストや複合動作テストで検出率を上げる
デバッグも中盤になると簡単に見つかるバグは殆ど出尽くします。ここからが、安定性や堅牢性などのソフトの品質を大きく左右する潜在バグをどれだけ洗い出せるかという、テストの最も重要な時期になってきます。
この時期になると、様々な処理のタイミングに依存して発生するバグや様々な条件が組み合わさった時に発生するバグが潜在バグとして残ってきています。タイミングや条件の組み合わせを網羅しようとすると、テスト件数が膨大な数になるテスト件数の爆発が起きてしまうので、網羅的なテストはできません。
ですので、この時期には探索的なテストや複合動作テストを使って、タイミングや条件の組み合わせに依存したバグをできるだけ効率的に見つけるようにします。
探索的テストや複合動作テストって何？
探索的テストは、簡単に言うとテストエンジニアがテストを進めながら、過去の経験と照らし合わせてバグの起きそうな操作タイミングや実行条件をその都度考えてバグを探し出していく、というテストの方法です。ソフトのバグは内部処理で何かの処理の仕方が切り替わるような箇所によく潜んでいます。熟練したテストエンジニアは、装置の動きや表示の動きを元に経験と勘でソフトの内部で何かの処理の切り替わるタイミングや条件を嗅ぎつけて、バグを洗い出します。
複合動作テストは、関係しそうな２つや３つの処理を同時に実行させる事で潜在バグを見付けようという方法です。例えば、XXXの状態を読み出す処理と書き換える処理があれば、この２つを同時に実行させる、というような方法です。複合動作テストは、どの処理を選ぶかによる組み合わせ試験になるので複合させる処理の数を３つ、４つと増やすとすぐに条件の組み合わせを網羅できない程にテスト件数が増えてしまいます。ですので、実際の運用でありそうな処理の複合に絞り込んで、現実的なテスト件数に抑える工夫が要ります。
探索的テストにしても覆道動作テストにしても、どこまでやれば良いというテスト終了の判断基準を設けるのが難しいテストです。テスト計画を考える時点では、何人日程度のテストエンジニアの工数を割り振るか、という工数ベースでの計画で対応するのが良いと思います。
品質保証のためのテストは再びテストの網羅性が大切に
デバッグのためのテストで十分に十分に潜在バグを洗い出してデバッグによりバグを取り除けば、いよいよソフト開発の最終段階のソフトのリリースです。ソフトをリリースするには、リリースしても問題無いレベルまで十分に品質が良くなっていて、ソフトのベンダとして品質が保証できる状態になっている必要があります。
ではソフトの品質が良い事はどうやって保証するのでしょうか？ 品質の保証はソフトでもハードでも同じで、テストをして、テストの結果問題無いと確認した項目がメーカとして保証できる項目です。
ですのでソフトの品質を保証するには、十分な量と質のテストを行っても ①バグが検出されないという事実の確認と、②十分なテストでバグが出ないのだから未発見の潜在バグが残っている可能性は非常に低いという推定との ２つの状況から、そのソフトの品質を保証する、という方法を使います。
そして、十分なテストをしてもバグが出ない事を確認するために実施するのが、品質保証のためのテストです。テストの項目や内容は、バグを見付ける事を目的としたデバッグのためのテストと同じかもしれません。しかし、テストの目的はバグが見つからない事を確認してソフトの品質を保証する事です。
ですので、品質を保証するためのテストでは、テストの網羅性が大切です。テスト設計で洗い出した詳細なテスト項目の中で、テストの実施が不可能なテスト項目を除いた、現実的に実施できるテスト項目については全て、テストを実施する必要があります。
この品質保証のためのテストの結果を１つの重要な判断材料として、そのソフトをリリースしても良いかどうかのリリース判定が実施されます。もちろん、ソフトのリリース判定はテスト結果だけではなく、その他にも様々な情報を元にして、総合的に判定する必要があります。 リリース判定については、リリース判定はソフトソフト品質保証の最重要作業の記事で詳しく紹介していますので、興味のある方はこちらの記事もご覧ください。