国際的なテスト技術認定機関＜ISTQB(JSTQB)＞によるテストの7原則

つまり、ソフトウェアテストでは実行したテスト条件においての結果は得られますが、 リリース後に無限と存在する全ての条件下においてどう動くかはわかりません。

それでは「ソフトウェアテストで欠陥が無いことの証明は出来ない」という前提の中で どのように品質保証に役立てたら良いものでしょうか。

明確な答えはないが、良いテストに必要だと思われる必須要素↑

テストチームのメンバーに対して「良いテストとは何か」といったお題を投げかけてディスカッションをしてみると面白いもので、10人10色の答えを引き出せます。

明確な答えは無いですが、ビジネスシーンにおける文脈であれば左図の要素は必須でしょう。

ただし、これらの要素を満たさないテストが世の中に溢れていることも事実です。
よくある例としては、「仕様書をそのままコピペしただけのチェックリストをテストと称し戦略がない」。
「実務者は戦略を頭の中で思い描いてテストケースを作ったつもりだが、第三者から見て意図が読み取れない」。「同じような観点のテストケースばかりで合理性に欠ける」などです。
良いテストへの第一歩を踏み出すキーワードとして「テストの目的と達成手段を論理的に示せること。またその選択がプロジェクトにとって最善であると説明できること」を意識することは有用です。

よく、テスト設計をしないで突然テストケースを作成する現場を目にしますが、 このテーマと向き合うと「なぜ、テストの上流プロセスにあたるテスト分析やテスト設計が必要か」などそれぞれの活動意義が腹落ちするでしょう。
また、トレーサビリティーに関する意識も自ずと湧いてきますし、ドキュメンテーションの質も変わってきます。

テストでは「何をやらないか」も決めなくてはならない

その他には、実現可能性の観点から意識しなければならないことが、「人・モノ・金・期間」などの制約です。
例えば、上映予定の映画のキャンペーンサイトであれば納期は必須でしょう。

ヒットするか分からないソーシャルゲームの新規タイトルであれば大量のお金はかけられません。
これは、医療や航空宇宙など高信頼性分野でも同様で程度の違いはあるものの、必ず何かしらの制約の中で品質保証をすることが求められます。

この制約という概念が加わると、テストは「何をするか」を決めると同時に「何をやらないか」を決めなければならないことに気が付きます。
そのため、優先度をつけながら「どこまでやるべきか」を検討する必要があるわけです。

ソフトウェアテストには答えはなく、一筋縄ではいきません。
ただし「良いテスト」と呼ばれるものには、先に述べたような特徴があることを理解しながら実践を重ねていくと良いでしょう。

このTest-Service BLOGでは、皆さんがソフトウェアテストを実施する際に参考になるような情報をお届けします。