(2021年版) ソフトウェアテストの上流設計-3 テストの目的設定

テストの目的設定は、ゆもつよメソッドの特徴的なアクティビティではなく、どちらかとテストをうまくやるための常識かもしれません。そのため、どんな時でも大事なアクティビティです。大規模なウオーターフォール開発でも、スクラムの１スプリントの中のテストでも重要であることに変わりはありません。

まずは、2010年の記事で書いた、以下の例を見てください。

例えば、ある家電製品のテストをしていて、「処理の切り替えタイミングになった瞬間にUSBを高速に数十回も抜き差ししてみる」というテストをしていたとします。そんなテストをするのは何故でしょうか？　単に正しく動いているかどうかを確認しているわけではないでしょう。だって数十回も抜き差しするのは、通常行う使い方ではありません。では何のためにやっているのでしょうか。そう！フリーズやリブートしたり、データ破損したりするような「致命的」な不具合を見つけたいからです。けど、そこまでして不具合を見つけなければいけないのは何故でしょうか？                                            もうひとつ例をあげてみます。動画再生プレーヤーのテストをしていて、「メディアの挿入→コンテンツの選択→再生オプションの選択→再生」と言った一連の操作手順をテストしたとします。非常に単調ですが、いろいろなコンテンツ/メディアの組合せで何百回も同じことをしなくてはいけません。何でこんなに沢山やるのでしょうか？工数もかかって大変ので、「よし。テスト技法を使ってテストケースを減らしてっと。」　ちょっと待ってください。減らして良いのでしょうか？このテストでは何を確認したかったのでしょうか？機能が仕様書どおり正しく動作することを確認しているだけですか？それとも、メディアの互換性を確認しているのですか？

テストの目的の必要性

上記の例 は、どちらもテストしていることだけしかわからないので、何のためのテストかは分かりません。そうならないために必要になるのが、テストの目的です。テストの目的とは、テストを設計、実行する理由や狙い・意図のことです。目的が大事なんていう話は、よく聞かされることなのでちょっと「うんざり」かもしれません。ただ、いくら効率が良くなる技法を駆使してテストケースを書こうとも、テストツールで自動化しようとも、そのテストが何のためにやっているかわからないと、どこまでテストをするのかが分からなくなります。まるで底なし沼にはまっていくような感じになります。

テストの特徴

SWEBOK では、ソフトウェアテストの特徴の一つとして...プログラムの振る舞いを、通常は無限に大きいと考えられる実行領域から、最適だと考えられる有限なテストケースのセットを選択… することとしています。

最適だと考えられる有限のテストケースのセットを選択するためには、まず最初に的を定めます。的になるものがテストの目的です。

全部やろうとするとものすごい量になるという話は連載の1回目の中でテストケースの問題として触れました。要は、テストは、いろいろなことをやろうと思えばどこまでも出来てしまうものであるということです。どこまでもテストできてしまう底なし沼にはまっていくのも、どこまでもテストが出来るあまり的がわからなくなっている、つまり、目的を見失っているのです。
　　　　　　　　　　　　

テストの目的の設定は、テスト分析の前に行います。ISTQBなどで定義しているカッチリしたやり方としては、マスターテスト計画作成時に、テスト戦略を具現化したテストアプローチ一部として策定すると良いです。

テスト目的の設定の流れ

テスト目的の設定の流れは図のようになります。

テストの目的を設定するためには、システム／ソフトウェアが実現したい品質を把握し、確認するテスト箇所を選択しながら、必要なテストをいつどう行うかを決めていくことで、相応しい具体的なテストの目的をアウトプットしていきます。また、テストの目的はテスト対象のどの要素に着目しているか、つまりテスト対象アイテムをアウトプットします。
これらの四つはお互いが影響を受け合いながらだんだんに明確になっていくものなので、上図では順番を示しましたが、必ずこの順番ですすめていかなければならないというわけではありません。

実現したい品質を具体的に把握
まず、そのシステム／ソフトウェアが実現したい品質を具体的に知らないといけません。品質を具体的に知るとは、実現したい特性の単位（製品を使う人が実現できることとか、そのときの使い勝手とか、応答時間やリソース利用量など）で、どのような事を実現したいのかを具体的に知ることです。何故ならそれによってテストすべきことが変わるからです。具体的に知るために、開発企画書や要求分析ドキュメントを読んだり、プロダクトマネージャーやエンジニアと話をしたり、可能であればユーザーからも話を聞くといったことを行います。

そして、このような「特性」のうち、何をテストで確認すべきかを選択します。具体的には、機能適合性を確認するのは当然だとして、それ以外のこと（例えば、信頼性はどこまで高くするか、性能効率性、例えば応答時間はどの程度で返るようにするかなど）を選択します。

具体的に把握する際に、「リスクベースドテスト」というテストのやり方を使うことがあります 。このテストのやり方を進めて行く場合は、この段階で、インパクト（市場で起きては使う人に迷惑がかかること）とライクリフード（欠陥が入り込んでしまう可能性が高いところ）という二つの視点で実現したい品質を分析し、何をテストすべきかを選択します。

 
確認するテスト箇所を選択
次に、確認するテスト箇所の選択です。これは２つの視点の組合せで考えられます。

まずは、テストレベルを横断的に見て目的設定する場合は、コンポーネントだけでテスト出来ることなのか、単一のソフトウェア／サービスだけでテスト出来るのか、ユーザーが使うだろう全部のサービスがそろっていないとテストしても意味が無いのか、といった開発の詳細レベルで判断する視点です。この視点は、典型的にはV字モデルと呼ばれる視点で、特にマスターテスト計画の段階でテストレベルの垣根をとって全体的にテストの目的を設定するときに重要です。

もうひとつが、その特性のテストはシステム全体としてテストが必要なのか、一部の特定の項目（例えば、差分開発での新機能部分だけ）のテストでよいのかといった観点でテスト箇所を判断する視点です。特性が機能適合性の場合だと、ある機能の追加があった時に影響範囲として他の機能や連携するサービスもテストするか判断しなければりません。特性が性能効率性であっても、例えばバッチ処理のテストであればバッチ処理後に後続のサービスが何か処理をするのであればそのサービスも含めて応答時間を計測したほうがよいとなります。

この観点はマスターテスト計画でも詳細テスト計画（例えば、システムテスト計画のときの目的設定など）でも必要になります。

必要なテストをいつ、どう行うか
「実現したい品質を具体的に把握」「確認するテスト箇所」の情報を使って、テストのスケジュールを立てる中で、どのタイミングでどのようなことを確認していけばよいのかを決めていきます。例えば以下の図のようなイメージです。

それぞれのテストの中でどのようなことを確認していけばよいのか決めることが、テスト目的の設定とテスト対象アイテムの特定になります。図に書いてあるイメージでいうと、「（機能）要件通りに使えることを確認する」が、テストの目的として設定したものの一つになります。そして、要件通りに使えることの確認をする対象として、新規開発の機能をテスト対象アイテムとして選択しています。

以降、テストケースを作っていく時に大事なのは、テストの目的とテスト対象アイテムにそったテストだけ作り、余計なものを削ぎ落とす、ということです。的を絞ることで余計なテストをしないようにすると、テストが速くなります。念の為やっとく、一応やっとく、というのは極力無くしましょう。

ここで極力とわざわざつけたのには理由があります。例えば、「念の為やっとく」ことがテストの目的になる場合もあるので、その時は念の為のテスト、信頼性向上のためのテストや、リグレッションテストをやります。

このように説明すると、なにか特別なすごいことがあるわけではなく、当たり前のことをやっているだけのように見えると思いますが...全くその通りです。大事なことは、このようにテストの目的とテスト対象アイテムを明らかにして次のテスト条件やテスト設計方針を特定して行く、つまりなんのためにこのテストをやるのかな？って考えて設定したテストの目的をテストケースまでつなげて、テスト実行するときになんでこのテストをしてるのかが分からなくならないようにしていくことです。例えば、日程計画でさえ、いざ立ててみると、テストの目的やテスト対象アイテムの話が消えてしまい、過去の慣習に沿って線を引いてしまっていることがあります。テストケースとテストの目的が断絶しているケースも良く見かけます。「わかってはいるんですけどねぇ」という言い訳もよくききます。そのようにならないように、テストの目的とテスト対象アイテムを明示して以降のアクティビティにつなげてください。

次回は、テスト分析について書いていきます。

テストでできることは大きく３つ

ここからはテストの目的設定に関してもう少しうんちくを混ぜて説明していきます。また、おまけとして、最近の私の考え方も少し書いておきます。