テスト仕様書を書く際にありがちな疑問

どうも、畜産ペンギンです。

 

侍JAPANも無事金メダルという事で。

ヤクルト勢も大活躍で非常に楽しく見れました。😁

 

今回はテスト仕様書について語って行こうと思います。

ひとえに単体テスト、結合テスト、システムテスト等ざっくり括りがあってもどの工程でどこまでやるのかはプロジェクト等によって様々です。

様々なケースで臨機応変に対応する際に思い浮かびがちな疑問と対応について書いていきます。

 

目次は以下の通り。

 

目次

・前提 ・どのような観点が必要なのか ・どこまで実施、網羅するのか ・まとめ

 

前提

基本的に、イチ担当であれば、プロジェクトのテスト方針等が決まっていたりドキュメントがあればそれに従うのが前提となります。

 

その上でテスト仕様書を書く際不明点等があった時の対応を主に下に書いていきますが、顧客やチームの合意を得た上で進める事が当然必要になってきます。

 

どのような観点が必要なのか

観点表のような物があれば一定それに従うのは当然ですが、化石の如く古いものであったり、あるいは観点表もなく「過去のテスト仕様書見て同じノリで書いて」みたいな感じになる事は多いのではないでしょうか。

 

その際に、ただ何となく観点表に書いてある通りに記載する。過去のを参考にこんな感じかなと真似るだけでは品質は向上しません。

何故なら既存の観点表やテスト仕様書はこれまで起きてきた事の蓄積でしかなく、程度の差はあれ今後の参考に過ぎずこれからの品質を保証する物では無い為です。

 

つまり、全く同じソフトウェア、全く同じ改修を行うというのは基本的にはありえない為常に新しい観点、切り口を考えていく必要があります。

 

過去の積み上げなど意味無いよみたいに言いましたが、とはいえ新しい観点や切り口を自分の頭で適切に導きだすのは困難ですし、これまでの蓄積というのは非常に参考になります。

同じ現場の過去プロジェクト等の蓄積は同じ理屈で同じ観点が必要になる事は非常に多いですし、これまで自分が学んできた事、もしくはどこかのスゴい人が考えてくれた手法を学ぶ事で穴が塞がる確率が上がるのは間違いないでしょう。

 

という訳で、いくつかどこかのスゴい人が考えてくれた手法を紹介します。

 

・ISO/IEC 9126　品質特性規格

品質に関する国際規約です。主に品質を以下の6つに分ける事で特性事の良し悪しを考える事が出来ます。

　・機能性：必要な機能に不足が無い事。

　・信頼性：機能が正しく、長時間動作し続けられる事。

　・使用性：利用者が使いやすく、魅力的である事。

　・効率性：資源の量に対し効率が良い事。

　・保守性：維持、改修がしやすい事。

　・移植性：別環境への移植の負担が低い事。

 

何かテスト界の5W1Hみたいな感じですね。

確かにこれらを満たせば良い物が出来そうですが、具体的にどう満たすかを考えて行く事は必要そうです。

 

・V&V（Verification & Validation：検証と妥当性確認）

Verification（検証）とは設計書の通りにソフトウェアが作成されているかを事。

Validation（妥当性）とはユーザーの要求通りにソフトウェアが作成されているかを確認する事となります。

 

例えば、ユーザーの個人情報を入力させ、確認画面を表示させた際に再度入力を行う画面に戻すボタンがあったとします。

このボタンを押下し、入力画面に再度遷移させた際に、入力値を保持していくか否かは設計書には記載されてません。

 

Verification（検証）の観点では、設計書に記載されていないので入力値を保持しておく必要がありませんがValidation（妥当性）の観点、つまりユーザーが使いやすいか否かであれば入力値を保持しておいた方が使い勝手が良いと感じるでしょうという事です。

 

どこまで実施、網羅するのか

こちらも基本的な考え方自体は上記と同じと思います。

ですので、いくつかどこかのスゴい人が考えてくれた手法のみを紹介します。

 

・狩野モデル

品質をユーザーの要求に応じて「当たり前品質」、「一元的品質」、「魅力的品質」に分けます。

テストのケース数と時間はトレードオフになりますので、実施するべき項目の優先度を決める為の手法となります。

ユーザー目線でまとめると一般的には以下のような感じですかね。

 

　・当たり前品質：充足して当たり前と考え、不充足だと不満に感じる物。

　・一元的品質：充足していると満足し、不充足だと不満に感じる物。

　・魅力的品質：充足していると満足し、不充足でも仕方が無いと感じる物。

 

なお、これらの内容は時間と共に変遷します。以前は魅力的品質であった物も、時間が立てば当たり前品質になる事もしばしばあります。

以前はこれだけやってくれたら喜んでくれてたのに。。。と思う事もあるかも知れませんがユーザー側も変化が当然あり、逐次対応していく必要があると言う事ですね。

 

・ホワイトボックステストとブラックボックステスト。

ざっくり言うと、ホワイトボックステストはプログラムの中身の制御等を意識しながら行うテスト。

ブラックボックステストはIFの入出力のみを気にし、中身は気にしないと言った感じです。

 

スコープをどこにおくかでも変わってきますが単純な見方なら単体試験はホワイトボックステスト、結合試験以降はブラックボックステストで行う事が多いでしょうか。

 

・2因子間網羅テスト

ざっくり言うと、複数の項目（因子）の組み合わせをどこまで網羅してテストするかと考える際、全組み合わせパターンを行うと膨大な量になります。

ですが、これを2つの項目の組み合わせを網羅すれば大体のバグは見つかるよといった手法ですね。

ちょっと具体的な例を表等に起こして説明するとややこしいので割愛します。興味があれば調べればすぐ出てきます。

 

D.Richard Kuhnと言う人が、①医療機器用ソフトウェア、②Webブラウザ、③サーバー用ソフトウェア、④NASAのデータベースでそれぞれ1因子および2因子間で生じる欠陥の割合を調べた所全欠陥の①97%、②76%、③70%、④93%となったそうです。

 

一番身近な②、③があんまり見つけきれてないな。。。

 

ちなみに3因子間網羅まで行くと①99%、②95%、③89%、④98%となったそうです。

 

まとめ

結局の所、ケースバイケースでその都度考えて行く必要があるよねというのは一つの真理だと思います。

とはいえ毎回行き当たりばったり、思い付きで取り組んでも品質は安定しませんので上記で記載した手法等をちゃんと引き出しの中に整理して入れて置き、引き出し易くしておく必要はあるのかなと思いました。

 

今回はここまでです。

 

さようなら。