hirschkalb's blog

"I beseech you, in the bowels of Christ, think it possible that you may be mistaken."

マトリクスは試験仕様書ではありませぬ MATRIX is not Make-A-Troublesome-Review-In-an-eXhauseted-tone

"GNU is not unix"的に格好よく頭字語で決めてみたかったのですが、失敗。

ここでの主張は一つです。

ソフトウェアテストにおいて、マトリクスは必要。しかしマトリクスだけでは十分ではない。ましてやマトリクスは試験仕様書ではない」

以上のことを主張しつつ、困った試験設計者(フィクション)への指摘と、「ならばあなたがその立場ならどうするのか」という、読まれた方が当然のように抱かれるだろう感想に対する見解を述べられたらよいと思います。

テストにも締め切りがある

通常、「テスト」には時間制限があります。そして、ソフトウェアテストはテストの一種なので、やはりこれにも締め切りがあります。


締め切りがあるのは、「すべてをテストしていたら日が暮れてしまう」からです。大げさに言えば、われわれに与えられた時間は有限だからです。


したがって「締め切りのあるテスト」というフレーズには、暗黙のうちに「すべてをテストすることは不可能」という事実が示されています。


以上のことからわかることは次の通りです。

すべてのパターンを試すことができるならばそれが望ましい。
しかし、時間は有限である。
したがって、テストは、テストの内容に縛られて設計されるのではなく、
テストを実施するためにあらかじめ与えられている時間に縛られて設計される。
逆ではない。

テストの目的

ソフトウェアテストの目的は案外ぶれがちです。

  • どこにも問題のないことを証明すること
  • 不具合を発見すること
  • 要件を満たしていることを証明すること

前節の結論(テストは時間によって内容が決まる)から、「どこにも問題のないことを証明すること」は、残念ながら不可能と言わざるを得ません。


また、何が「問題」か自明ではないことが多いでしょう。ソフトウェア開発の現場では、このケースが顕著だと思われます。現実的には次のふるいにかけられて判断されることが少なくないと想像します。

「要件に反しているならば明らかに『問題』としてよい。要件にない場合で、一般的な判断として誤っているように見えるときを考える。仮にそれを「問題」と定義したとき、その問題の解決策を考える。その問題解決策の実施能力があるならば、確かに『問題』としてよい。ないのならば、『仕様』とする」

したがって、実は目的の一つ「不具合を発見すること」も同じ問題を持っていることになります。これもまた、何をもって「不具合」といえるのか自明ではないという点で、同じ問題をかかえています。


残る「要件を満たしていることを証明すること」が尤もらしい目的といえるでしょう。


もともと、あらゆるソフトウェアテストは根拠資料となる設計書類から生み出されます。その書類は要件から生まれます。そのことを考えても、ソフトウェアテストの目的は「要件を満たしていることを証明すること」です。

しかるにマトリクスとは何か

ジョージ・ガモフではありませんが、「猿に表計算ソフトを触らせたら、いつかすべての試験パターンを挙げるだろう」。


問題は、われわれがその試験すべてにソフトウェアを合格させることができるか、という点にあります。


打ち出されたテストの中には物理的および時間的の制約から実施不可能な試験が存在します。また、それより簡単な手順で同様の確認が可能な試験が存在します。さらに、要件として明示されていないことから試験結果を合格とも不合格ともできない試験も含まれます。


以上を端的に言うと「『いらない試験』がたくさん生まれます」。


孫引きになりますが、ポアンカレの言葉を引用してみたいと思います。括弧と太字は私の補足*1

(試験を設計するというのは)或る固定した法則にしたがってでき得るかぎり多くの組合せを作るとかいう問題ではない。かくの如くにして得られる組合せはいたずらに数多く、ただ無益にして煩瑣なばかりであろう。発見者の(=試験設計者の!)真の仕事は、たくみに選択を行なって、無益な組合せを除外すること、或いはむしろ、かかる組合せをつくるが如き労を費やさないことにある。

自分でパターンを思い浮べる間もなくいきなりマトリクスを使い出すと、根拠資料となるはずの要件からひとり立ちした、出所の不明な、試験設計者自ら出来もしないような、そのような試験が生まれます。そして次第にその試験が「ぼくは仕様だ!」と主張し始める──そのようなことが起こりうるのです。

ツールの使い方がおかしい

マトリクスで有用な試験群が生み出されるというならば、先述の通り試験設計者は「猿でもよい」のであって、残念ながら実際にはそのようなことにはなりません。


試験設計者がマトリクスを用いて機械的に吐き出す試験群を試験実施担当者が取捨選択して「要件を満足することを確認できるもの」「実際に実行可能なもの」「既に実施している試験とダブりのないもの」かどうか「試験項目を検査する」のはブラックジョークにしか聞こえませんが、少なくとも私の所属する現場ではそのようなことが起こっています(フィクション)。


まずは要件を読みながら自分で試験を実行することを考えて試験項目を「そのまま誰が読んでも試験実行できるように」書き出すことが大切です。


なぜかといえば、実行できなければ試験を挙げたところで文字通り「実行できない」からです。このように「実際に自分が設計した試験を自分で実施できるのか?」という問いをしていく中で、自然と無用な試験(=したがって本来「試験」と呼ぶに値しないのですが)は捨て去られていきます。


マトリクスは、そのような作業を一通り終えた後、チェックツールとして作成すべきものです。

試験環境と要件を理解したうえで設計する

プログラム設計者が多くの場合、プログラミング可能なことに対し、テスト設計者の中には、ややもすると、自ら設計したテストを実施できない人がいます。後者に対しては「設計者としての仕事をしていない」といわざるを得ません。


テスト設計時は、「『実施できない試験』は定義により実施できない」ことを念頭において、可能範囲で最適な試験を設計することを目標にすることが望ましいでしょう。


そして、「可能範囲で最適な試験」を設計するためには、当然のことながら「現状のテスト環境(時間を含む!)で何が可能で何が不可能か」を知っていて、その上で要件を理解していることが必要となってくるのです。


いたずらに表計算ソフトから無限ともいえる組合せを生み出す作業を試験設計とはいわないことを忘れないようにしたいと思います。

*1:孫引きの補足とは・・・。

広告を非表示にする