さあ今日も、人の褌で相撲を取る「とは何か」シリーズです！
今日ご紹介するのは、Soap Opera Testing。Hanz Buwalda氏によるstickymindsの記事が、コチラ[pdf]にあります。
ソープオペラテストとは？
「ソープオペラ」の意味・語源は記事内でも紹介されていますが、こちらの記事がいみじくも訳を当てているように、アメリカ版「昼ドラ」ですね。
この名前を受けたソープオペラテストは、次のように表現されています（意訳）。
Soap opera testing is similar to a soap opera in that tests are based on real life, exaggerated, and condensed.
ソープオペラテストは、実際の人生をベースにしながら、それを極端かつ凝縮しているという点で、ソープオペラに似ている。
ソープオペラテストは、シナリオテストの一種とされています。
シナリオテストにおいてシナリオを作成する方法にはいろいろあると思いますが、ソープオペラテストでは、現実の世界でありそうな出来事を誇張・凝縮してシナリオにし、システムに投入していくのです。
手順はざっくり、以下の通り。
- 様々な「イベント」を経験するキャラたちを設定する。
- 実際に起こりそうなことを大げさに、かつ凝縮したシナリオを作る。この時点ではシステムの仕様は意識しない。
- テスト対象のシステムの言葉に直しながら、いらない部分を落とし（weed）、思いついたものを付け加える（feed）
このデフォルメされたシナリオによって、従来のテストでは見つからなかった欠陥の摘出に期待できるとしています。
「普通の」テストとの比較
仕様書などをベースにテストケースを抽出していく「普通の」テストを、この記事ではmechanical testing（機械的なテスト）と呼んでいます。「a simple, structured」なテストです。
「普通の」テストにおけるテストケースの導出方法には、要件や機能を上から分解していくtop downのアプローチと、それを積み上げていくbottom upのアプローチとがあります。この手順を象徴しているのが、「analytical ways」、「分析的な」、あるいは「理詰めの」という言葉でしょう。
一方、ソープオペラテストでは、ビジネス・業務の側の事情をシステムに持ち込む、つまりoutside inでテストケースを作っていきます。
この二つのタイプのテストは、どちらかのみが必要ということではなく、品質に一定の自信をもつためにも、既存の「機械的なテスト」が必要だと言っています。
ん？
何かこういう言い草、どこかで聞いたことありますよね。
そうです、探索的テストです。*1
探索的テストでも、「普通の」テストをscripted testと呼び、テストケースを事前に手順化しない探索的テストと対比して、両者は補完し合うものだと主張しています。
では、ソープオペラテストと探索的テストとの違いは何なのか。
簡単な表にしてみました。以下で説明します。
| スクリプトテスト | ソープオペラテスト | 探索的テスト | |
|---|---|---|---|
| テスト設計と実装のタイミング | テスト実行前 | テスト実行前 | テスト実行中 |
| 欠陥を見つけてやるぜ感 | 低い | 高い | 高い |
| テストケース導出のアプローチ | 要件・機能仕様 | 現実のビジネス・業務 | プロダクトに対する知識・直感など |
テスト設計と実装のタイミング
Cem Kaner氏は、探索的テストを以下のように表現しています。
Exploratory software testing is a style of software testing that emphasizes the personal freedom and responsibiliy of the individual teseter to continially optimize the value of her work by treating test-related learning, test design, test executin, and test result interpretation as mutually supportive activities that run in parallel throughout the project.
探索的テストでは、テストの設計と実装は、テストを実行しながら行います。一方ソープオペラテストでは、シナリオを事前に準備します。
欠陥を見つけてやるぜ感
low ambition、high ambition という言葉が出てきます。訳しづらいのですが、積極的に欠陥を狙いに行く（high）か、欠陥があるかどうかにあまりこだわらず、検証すべきことを淡々と検証する（low）ということかなと思います。
ここでは、スクリプトテストはlow、ソープオペラテストと探索的テストはhighとされています。
テストケース導出のアプローチ
上で述べた通りです。
効率と効果
さて、この比較はいいのですが、気になるのが次の文章です。
... exploratory testing are now available that easily outperform mechanical tests in efficiency and effectiveness. 探索的テストは、効率と効果の点で、機械的テストより優れたものになっている。
いや、効率も効果も勝っているなら、機械的テストは意味ないんじゃないですかね。
テストにおける効率と効果とは、どう考えるとよいのでしょうか。
単純すぎるかも知れませんが、「テストケース全体のうち、欠陥を引き当てるテストケースの割合の多いもの」が効率的で、「欠陥全体のうち、多くの欠陥を潰せるテスト」が効果的だとわたしは考えました。絵にするとこんな感じ。
で、それぞれのアプローチをマッピングすると、こんな感じですかねえ。
ソープオペラテストの欠点
テストケースの導出方法がシステマティックでないという点が、ソープオペラテストの欠点につながっています。どのくらいテストケースが出てくるか予想しづらい、カバレッジが不明、など。
記事の後半では、その解決方法が提案されています。
大きなテスト対象を、管理しやすい「クラスター」に分解するとか、機械的テストで出てくるような小さいテストケースを、ソープオペラのシナリオの中に埋め込むことで網羅性を高めるように実装していく、など。正直、いまいちな印象を受けます。
どうもこの記事では、「機械的テストも必要」と言いながら、「そうはいってもソープオペラテストでかなり代替できる」と匂わせているフシがあるのです。
が、実際にソープオペラテストをやるとしたら、「機械的」の方をすべて終わらせてから取り組むと思います。「ソープオペラテストの中で、テキストフィールドの最大長・最小長も確認してしまおう」なんてわたしは思わないのですが、そんなやり方アリなんでしょうか？
そして、シナリオテストとは
さて、ソープオペラテストという技法はシナリオテストの一種で、シナリオを導く方法を提供してくれることがわかりました。でも、ここまで書いてなんですが、ぼくの考えている「シナリオ」って、コレジャナイんですよね。
ソープオペラテストがoutside inであり、機械的テストがtop down、bottom upであるように、ぼくに必要なシナリオテスト技法は、inside outとでもいうものです。シナリオを、要件や仕様から、それこそ analyticalに導出したいのです。
ということを、2年前くらいから考えているだけです。今年も考えていきたいと思っています。
最後に、ソープオペラテストについて、電通大のにしさんのコメントを紹介いたします。
海の向こうに昼ドラテスト（soap opera testing）とやらがあるのなら、我々は朝ドラテストという、一つのサイクルで一つのストーリーを表現し、短いサイクルで管理でき、全体として様々な側面からのテストを完結できるような、そんなテストを提案したらどうかと思うクリスマスイブ。
— YasuharuNishi (@YasuharuNishi) 2013年12月24日
*1:探索的テストについて、goyoさんが素晴らしい資料を公開されています！ 感謝。
www.slideshare.net
