シナリオテストについてのメモです。
シナリオテストについては識者がいろいろな議論していますが、それらとの整合性とかは考えず、今わたしが考えている、わたしの知っているドメインでの「シナリオテスト」の話です。
ただ、下書きを書いた後に、2012年の自分の記事を読んでみると、大きく変わってはいませんでした。。。まるで成長していない・・・ので、「その4」にしています。
シナリオテストの定義
まず、ISTQBの定義。
ISTQBでは、シナリオテストはユースケーステストの同義語として扱われています。
ユースケーステスト（use case testing）
ブラックボックステスト技法の一つ。ユースケースの動作を実行するようにテストケースを設計する。
Synonyms: シナリオテスト（scenario testing）, ユーザシナリオテスト（user scenario testing）
次に、ISO/IEC/IEEE 29119 Part3の定義と勝手訳。
scenario testing
class of test design technique in which tests are designed to execute individual scenarios
Note 1 to entry: A scenario can be a user story, use-case, operational concept, or sequence of events the software may encounter etc.
個々のシナリオを実行するためにテストを設計する、テスト設計技法のクラス。
「シナリオ」とは、ユーザストーリー、ユースケース、運用の構想、ソフトウェアが遭遇しうるイベントの連なりなども含む。
「シナリオテスト」周りにはいろいろな類似概念がありますが、ISTQB、29119ともに、それらをまるっと「シナリオ」「ユースケーステスト」に寄せようとしている印象です。
で、オレオレ定義。
人間とシステムの相互作用によって、指定されたゴールが達成できることを確認するためのテスト。
「ゴール」という言葉が逃げなのですが、「ユーザが達成したいこと」という意味です。
「業務」というと業務系システムに限定してしまう感じなので、この言葉を使っています。
このオレオレ定義の意図するところには、以下のようなものがあります。MECE性無配慮。
シナリオでは、人が中心であり、システムが絡まない部分がありうる
シナリオにおいてはコンピュータシステムは要素の一つにすぎず、システムの現れない作業もありえます。
たとえば「テレビ局の番組のための取材」という業務を考えてみましょう。取材のサブ業務として、以下を仮定します。
- 取材に関する情報の登録と、取材に回す人間のアサイン
- 取材自体
- 取材で得た音声/映像コンテンツの持ち帰り
- 当該の取材に関する情報の更新
1と4はいかにもシステム化していそうな部分ですが、2はシステムからいったん離れています。
3はもう少しややこしくて、電子的に転送できる環境であればコンテンツシステムに自動登録され、取材と関連付けられます。一方そうでない場合は「媒体を車両で物理的に持ち帰る」ことになります。ここにはシステムが現れません。
1と4の間で、システムの利用が断絶しているわけです。
シナリオテストでは、システムの利用が断絶しても、業務自体は断絶しないことを確認しなければなりません。もっと積極的には、「スムーズに回る」ことが理想です。
これは1、3、4の個々の機能のテストではわからないことです。
シナリオは、機能の組み合わせからなるものではない
ゴールは機能に先立ちます。まずゴールがあって、システムとその機能は、ゴールを達成するための補助的な存在です。
よってシナリオテストのためのシナリオは、「ユーザは何を達成したいのか」からトップダウン的に作るのがメインルートであり、「おれたちの作った機能を組み合わせて何ができるだろう」からボトムアップ的に逆算するのはサブルートにするのがよいです。
といっても、機能をいろいろ組み合わせてシナリオを作り上げることを否定するわけではありません。機械的に組み合わせてみると、トップダウンのアプローチでは思いつかなかったシナリオを発見できるかもしれない。ですので、発想を広げるためにはこのアプローチも有効だと思いますが、まずは「何を達成したいのか」から目をそらさないことが大事だと思います。
シナリオの網羅性は、機械的に説明しがたい
テスト技法の中には、テストカバレッジの「分母」を数学的に導出できるものがありますよね。コードカバレッジがそうですし、組み合わせテストや状態遷移テストもそうです。
一方シナリオテストにおいて、「全シナリオ」を機械的に導出できるとは考えづらいですね。
シナリオの網羅性は、「ユーザが達成したいこと」とその「バリエーション」、そして「それを妨げる事象」をどれだけ洗い出せるかが勝負になります。特定のお客様がいるのであれば、そのお客様が示す明示的/暗黙的な要件。不特定多数のユーザがいるなら、それらのユーザから収集可能なオペレーションログから想定できる「使い方」。などなど、得られる情報から発想を繰り返すことが、シナリオテストにおける「テスト設計」になるのではないかと思います。
ということで
昔考えていたことから特に進展はありませんでした。
ただ当時は、シナリオを「ユースケースの接続」のように捉えていたのですが、現在は「ユースケースとユースケースの隙間に、システムの介在しない隙間があるよな」と考え直しております。
ずーっと積読になっていたこの本を読み始めました。いつか記事書きます。
