ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

テストオラクルとは何か

File:Chinese oracle bone (16th-10th C BC) - BL Or. 7694.jpg"File:Chinese oracle bone (16th-10th C BC) - BL Or. 7694.jpg" is licensed under CC0 1.0

 ソフトウェアテストの有識者の方々と、「テストオラクル」について話す機会があったので、自分なりの理解を整理しておきます。

 まずはおなじみ、I/JSTQBの用語集から。

テストオラクル(test oracle)
テスト対象のソフトウェアの実行結果と比較する期待結果のソース。オラクルは、実在する(ベンチマーク用の)システム、他のソフトウェア、ユーザマニュアル、個人の専門知識の場合があるが、コードであってはならない。

 要するに、期待結果を作るための元ネタでふね。

 ここで2つ、気がつくことがあります。

  1. (少なくとも明示的には)仕様書はオラクルと見なされていない。
     → オラクルにはどんな種類があるのか
  2. オラクルは、期待結果そのものではない
     → オラクルが期待結果そのものではないとは、どういうことか

 本記事では、この2点について考えてみたいと思います。

オラクルにはどんな種類があるのか

 「期待結果のソース」というオラクルの定義を考えれば、明記こそされていないものの、仕様書自体もオラクルに含めてもかまわないでしょう。
 これを含めれば、オラクルは以下の3つに分類できます。

そのソフトウェアをふるまいを記述したドキュメント

 仕様書、ユーザマニュアルなどがこれに当たります。

比較対象にできるソフトウェア

 まず、用語集で「ベンチマーク」と表現されているものがあります。Cem Kaner氏は、Microsoft Officeの競合品としてOpenOfficeを開発しているとすると、OpenOfficeの動作が「正しいか」は、Microsoftの「Word」が教えてくれるとしています*1

http://www.testingeducation.org/k04/examples/obas05s.htmlwww.testingeducation.org

 またJRの運賃計算では、膨大なテストケースの期待結果を、1つ1つ人間が考えるのではなく、Nバージョンプログラミング、つまり同じ出力を持つシステムを複数作って突き合わせるということをしています。

www.publickey1.jp

テスト対象となる実機用の運賃ソフトウェアと、検証用の運賃ソフトウェアは別のチーム、別のアルゴリズム、別のプログラミング言語で作ります。実機用はC++ですが、検証用はJavaで言語特有のバグをなくそうとしています。でも検証用のソフトウェアにはそんなに予算が掛けられず少人数で作っているので、実機用はどうやって作ったのか聞きたくなるのですが、そこを我慢して作る。

過去の履歴

 「そのソフトウェアの前バージョンと同じ動きであれば問題ない」というオラクルもあります。リグレッションテストは、「過去の想定した期待結果の通りに動作する」ことを確認するので、テストオラクルの一覧ということができるでしょう。

人間の知識

 用語集では「専門家の知識」とあります。
 ですが、たとえば文字判別のソフトウェアにおいては、一般の人が「妥当」と考える常識的な判断がオラクルになりうるでしょう。

その他

 メタモルフィックテスティングはちょっと異色で、「正しいことがすでに分かっている期待結果」を派生させていくものです。

www.kzsuzuki.com

 このように、「期待結果のソース」は様々な種類があることがわかります。

オラクルが期待結果そのものではないとは、どういうことか

 oracleとは、神託のことですね*2
 世界観がぐちゃぐちゃですが、こういう絵になります。

神と神託

 神からのお告げを巫女さんが受け取ります。お告げは神秘と暗示に満ちていますから、解釈が必要です。専門職たる巫女さんがこれを解釈し、人々に伝えます。
 このアナロジーから言えることが、これまた2つあります。

  • 間違いが入り込む
  • 細かいことを教えてくれるとは限らない

間違いが入り込む

 まず、巫女さんが間違えます。
 たとえば「18歳以下は無料」という仕様を、「18歳であれば有料」と解釈してしまうと、誤った期待結果を得ることになります。

 次に、神が間違えます。
 神の無謬性を信じたいところではありますが、ソフトウェア開発において神託を告げるのは神ならぬ人。「仕様通りの動作である」ことがテストで確認できても、「間違った仕様通りの動作」なら意味がありませんね。

細かいことを教えてくれるとは限らない

 たとえば神たるお客様が「性能要件は、“旧システムと同様“ね~」と重々しく宣われたとしましょう。このオラクルは、システムのあらゆる性能要件を余すところなく記述したものと言えますが、「旧システムの性能を一つ一つ確認する」という「解釈」なしには、何も言っていないのと同じです。
 つまり、オラクルがあったとしても、テスト設計においてはそれを解きほぐす必要があるかもしれない、ということです。

まとめ

 まとめると、「適切なオラクルを適切に解釈しないと、適切な期待結果は得られない」という、ごくごく当たり前の結論になります・・・!

*1:まったく同じ話を過去記事でも書いていました・・・ www.kzsuzuki.com

*2:甲骨のことは、oracle bone というらしいです。