過去のエントリは以下にあります。この中で、あらためて調べたことなどをまとめておきます。
捏造練習問題は、後日・・・。
kzsuzuki.hatenablog.com kzsuzuki.hatenablog.com
2周目の補足事項
テストオラクルって何者？
先日twitter上で、「テストベースとテストオラクルの違いがわからん！」と発言しました。両方とも、テストケースの元ネタかのように思われたためです。その際にいただいたコメント含め、色々調べたので整理してみます。
まずJSTQBにおける「テストベース」の定義（一部）は、
コンポーネント要件やシステム要件を推測できる全てのドキュメント。これらのドキュメントがテストケースのベースとなる
つまり、テストケースの元ネタです。
次にJSTQBにおける「テストオラクル」の定義（一部）は、
テスト対象のソフトウェアが実際に出力した結果と比較する期待結果を決定するためのソース
つまり、テストケースと不可分のもの。
こう並べてみると、テストベースはテストケースを作るときに使い、テストオラクルはテストケースを実行した後に使うということでしょうかね。
具体的には、こういうことなのでは？と思っています。
じゃあ、オラクルって、テストケースの「期待結果」に書いてあることとと同じじゃないかってことになりますが、明確に「y=3」と書かれる期待結果に対して、オラクルはそうとは限らない。
たとえば、ExcelのセルB1に、こういう数式を入力しておきましょう。
セルA1の値がx、セルB1の値がyにあたります。このExcelシートは、期待結果を教えてくれるテストオラクルです。A1に値を入力すれば、B1の結果が得られ、プログラムに期待される動きを教えてくれるからです。
計算であればExcelでオラクルが作れますが、あるべき出力結果がドメインに依存するようなケースでは、そのドメインに精通した人の知識がオラクルになるでしょう。
Cem Kaner氏のページには、テストオラクルの面白い例が載っています。Microsoft Officeの競合品としてOpenOfficeを開発しているとすると、OpenOfficeの「Writer」の動作が「正しいか」は、Microsoftの「Word」が教えてくれるという話です。両者に同じ入力を与えて、同じ出力が返ってくれば「正しい」ということで、この場合、MS Wordという競合品がそのままテストオラクルになるということですね。
ちなみにこのページによると、Writerでは65,535文字でいっぱいになって、そこに文字列のペーストをするなどで無理やり溢れさせると、無言で落ちるそうです。Wordはメモリが許す限りがんばると。
さて、オラクルの定義には続きがあって、
コードであってはならない。
上の(1)(2)に似たステートメントがコード上にあっても、それはテストオラクルにはならない。コードが仕様とズレていても、気づくことができないから。
テスト条件について
ここでいう「条件」は、「条件網羅」の条件とは違います。「テスト対象」というのが近い。このテスト条件をどうテストするかというのが、2.4.1「テスト条件の識別」に含まれます。
この作業に、FV表を適用することができるのでしょう。『ソフトウェアテスト技法ドリル』に説明があります。ここでいう「Fr（目的の機能）」「V（検証内容）」が、テスト条件に対応するものと思います。
- 作者: 秋山浩一
- 出版社/メーカー: 日科技連出版社
- 発売日: 2010/10/01
- メディア: 単行本
- 購入: 7人 クリック: 153回
- この商品を含むブログ (19件) を見る
もう1つ、テスト設計で大事な作業
テスト設計では、「何を」「どう」テストするかだけではなく、「どこで」テストするかも規定しておくことになります。「どこで」というのは、物理的な場所もそうですが、プログラムを動かす環境全般ですね。テスト環境は本番環境よりサーバのスペックが低かったり、2つのサーバを1つにまとめてしまったりすることもあります。
テストでどんなツールを使うのか、テストに使うデータはダミーでいいのか本物に近いものを用意するのか、本物を使うなら、データの提供をいつお客様に相談するか・・・などなど、考えることはたくさんあります。
これらは、技術的な問題というより、調整ごとの多い話ですね。「今頃言われても準備できないよ！」「え？そのツール使える人誰もいないけど・・」「もうテスト端末おくスペースないよ・・・」とか、「テストのメンバーを追加したせいで、IPアドレスが足りないんだけど・・・」（実際にありました）とかいう悲しい自体になりませんように・・・。
なお、「なぜ」テストするかについて検討するフェーズは規定されていないので、勝手にやりましょう。
