# タイトルコール ようこそ、世界が広がるソフトウェア品質展。 このチャンネルでは、Qエンジニアのサミーが、 ソフトウェアテストやソフトウェアの品質保証を中心に、 日々奮闘していることや考えていることをお話しします。 毎日、お昼の12時30分に配信しています。 ゲストの方やリスナーのあなたと、 テストや品質の世界を広げていきます。 # テストオラクルとは？ こんにちは。Qエンジニアのサミーです。 今回はテストオラクルについて話そうと思います。 突然ですが、ここでクイズです。 JST-QBにおけるテストオラクルの正しい説明はどれでしょう。4択です。 1、テスト対象の出力が正しいかどうかを判断するための基準となる情報のこと。 2、テストケースを設計する際の根拠となる資料やドグメントのこと。 3、テストの自動化を行うために必要なスクリプトやツールのこと。 4、ソフトウェアの品質を保証するために実施する受入テストのこと。 さあ、どれでしょうか。 あれですね、もう一回聞きたい方はぜひ巻き戻して聞いてみてください。 正解はですね、1番です。 1番のテストオラクルとは、テスト対象の出力が正しいかどうかを判断するための基準となる情報のことを指します。 どうですか、パッと答えられましたか。 ちなみにですね、私はいつもテストオラクルってなんだっけって分からなくなっちゃう派の人です。 特にですね、テストオラクルとテストベースの違いがちょっとよく分からなくなっちゃうなっていつも思ってます。 クイズの選択肢の2番が実はテストベースの説明でした。 テストベースというのはテストケースを設計する際の根拠となる資料やドキュメントのことです。 そのテストオラクルという言葉がなんでしっくりこないかというと、私の場合ですけどオラクルという言葉がいけないような気がしていて、 私がオラクルという言葉から連想するのはデータベースですね、オラクルデータベースになっています。 これも新卒で最初に入った会社で提供していたシステムがオラクルDBでしたしっていうのもあるのかなと思いますけど。 オラクルという言葉の語源というか名前、単語オラクルという言葉自体を調べたら神託っていう風なのが出てきて、神と託すの神託ですね。 やっぱりよう分からんという風になっております。 あれから今ちょっとウィキペディア見てたんですけど、オラクルのその別の意味として神託機械において特定の決定問題をワンステップで解く付加装置という風に書いてありました。 日本語のウィキペディア見てますけど。 これは完全に私の感覚解釈ではあるんですけど、そのオラクルっていうのが中小機械、マシンの方の機械ですけど、 マシンの一種で、特定の決定問題をワンステップで決定可能っていうところが今回話題にしているテストオラクルのもしかしたら何か由来になっているのかもなという風には今ちょっと思ってたりします。 というのもテストオラクルを見てこの機体結果、テストケースの機体結果、出力の正しさ、出力が正しいっていうことを判断できるのでっていうニュアンスなのかな。 そこが元々の語源というかオラクルという言葉自体のさっきの問題を解決する1ステップで決定することができるみたいなところと似てるのかもなという風に感じてます。 新宅機械のウィキペディアのURLをこのチャプターに入れておきますので、興味ある方はぜひ読んでみてください。 テストオラクルとテストベースの違いに戻ってくるんですけど、テスト業務で使う順番としてはテストベースが最初でテストオラクルがその後のはずという風に解釈をしています。 テストベースっていうのはテストケースを作るためのインプットなので、具体的に言うとPRDとか仕様書、設計書と呼ばれるものになります。 こういうPRDとか仕様書を元にしてテストベースとしてテストケースを書いていきます。 ただPRDとか設計書、仕様書の情報だけだとテストケースを書いていて、テストケースの期待結果がこれでいいんだっけって分かんないときってありますよね。 なのでそのアウトプットをテストを何かを実行した期待結果、出力の結果が正しいかどうかを判断するにはテストオラクルと呼ばれる別の情報が必要になります。 場合によっては仕様書を見れば分かるかもしれないし、何かしらのロジック計算式かもしれないし、 システム以降やったときとか、システムを変えるときっていうのはシステムを変える前後で期待結果が変わらないことを確認するので、 そういう場合だったらテストオラクルっていうのは既存システムの出力結果がテストオラクルとなって、 その既存システムからの出力結果と新しい新システムからの出力結果が一致するかを確認するっていうことになるから既存システムの出力がテストオラクルになると。 期待結果が正しいことを判断できる材料っていう意味でテストオラクルなのかなというふうに考えてます。 はい、ということで今回はテストオラクルの話をしました。 ちょっと私も調べながらとか考えながらお話をしたのでただただしいというか感じになってしまいましたが、 ぜひテストオラクルってこうだよねみたいないい例え話、具体例とか定義とか解釈みたいなものがあればぜひ教えていただきたいなと思います。 一言でまとめるとテストオラクルというのはそのテストケースの期待結果、出力の値が正しいかどうかを判断する材料、情報源です。 # クイズ形式どうでしたか？ 今回クイズ形式にしてみたんですけど、どうでしたか? ぜひ感想をコメントでいただけると嬉しいです。 # #51のコメント返し🥰 コメント返しのコーナーです。今回は51話目のコメント返しをします。 1週間前の51話目は、健やかに働くために時間で解決しないというお話をしました。 コメント2件いただいております。ありがとうございます。 1件目、けんけんさんですね。 最近聞き始めましたということでありがとうございます。ようこそいらっしゃいました。 リソースは有限という認識を持つことは大事ですよね。 だからこそ工夫・改善や優先度を考えることにつながるかと。 リソースを無視したテスト実施計画、もはや計画ではない、は嫌いです。 本当にまさにというふうに思ってまして、リソース有限というのは本当そうだなと思います。 私も常々意識しています。 時間というのは限られていて、 自分の平日の仕事をする時間とかもかなり細切れに、30分単位くらいで、 あとこのくらいあるからこのくらいの仕事ができるみたいなふうに、 ある限られた資源というかリソース時間というものをどういうふうに使うかなというのをいつも考えていたりします。 あとそのリソースを無視したテスト実施計画も嫌いですというふうに書いてくださっているんですけど、 本当そうですよね。これもテストしなきゃいけない、あれもやらなきゃいけないみたいな感じで、 なんか気づいたら膨大な数の掛け算のテストケースがあって、 こんなの1週間でできない、数週間じゃできないみたいなのは確かに過去ありました。 本当にその全件が必要なぐらいの精度というか、細かいいろんなパターンを考慮したテストが必要なのであれば、 それはテスト計画のタイミングでもっとかかりますというところをアピールしなきゃいけないですし、 単純に組み合わせの掛け算とかでテストケースの数が爆発してしまうのであれば、 それはテスト設計のやり方があまりよろしくなくて、 それって本当に全部その要素って組み合わせる、因子水準って組み合わせる必要があるんだっけということを ロジカルに考えて削っていくことが必要なのかななんて思ったりしました。 はい、初コメありがとうございました。 2件目のコメント、みずけんさんからいただいております。 いつもコメントありがとうございます。 いや耳が痛い。ついつい時間で解決してしまいますよね。 ダメだと分かっていても、ちゃんと考えて仕事をしないといけませんねとコメントいただいております。 みずけんさんは時間で解決しちゃうタイプの方なんですね。ダメですよ。 どうかですね、体とか心も含めてですけど、体調を崩す前に休みましょう。 健康でないと仕事もアスピも一生懸命できないですからね。 はい、ということでコメント返しでした。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 次回はテスト分析とテスト設計の違いについてお話ししようかなと思っております。 気を抜くと違いが分からなくなってしまうというか、同時にやることも多かったりするので、改めて違いについて考えてみようと思います。 今回の放送を聞いて、なるほどな、確かにな、学びになったなと思った方は、ぜひ画面右下のハートマークでいいねを押してください。 とても励みになります。 ぜひフォローもよろしくお願いします。 Xでのシェア、コメントもいつもありがとうございます。 それではまたお会いしましょう。ごきげんよう。