シナリオテストについての覚書。
シナリオテストについては何度もオレオレ定義を書き散らしてきて、今回もその類なのですが。
「その4」は、コチラ。
シナリオテストを行ううえで、大きく2つのことを意識しているなと考えたので、メモです。
2つというのは以下です。
- ソフトウェアの利用のEnd to Endを意識する。
- ソフトウェアを使う人を意識する。
1. ソフトウェアの利用のEnd to Endを意識する。
テストシナリオ、つまり「ユーザがソフトウェアを利用する流れ」は、どのように考えるとよいでしょう。
ソフトウェアが提供する機能から考えると、開発者目線に偏りがちになるように思います。
シナリオを考える際には、機能からではなく、「ユーザが達成したいこと」を起点にするのがよいでしょう。
「ソフトウェアが提供する機能を組み合わせて何ができるか」ではなく、「ユーザが達成したいことを、ソフトウェアが提供する機能はサポートできるか」で考えるというか。
前者だと、当該ソフトウェアの外にあるもの、たとえば他のソフトウェア・ITシステム、物理的なモノ、人間系、時間の流れといったものが見落とされがちです。
「達成したいこと」は、ソフトウェアだけで実現するとは限りません。ユースケース同士を、人間系でつなぐこともあります。ソフトウェア的には、先のユースケースの出力と、次のユースケースの入力が、いったん断絶することになります。
ユースケースの間にある人間系で、その断絶が正しく埋まっているのか。これは個々のユースケースの確認だけでは検証できないんですよね。
なお、「その1」では、「テストシナリオ」を以下のように位置づけていました。
テストシナリオとは、「テストケースの部分集合に順序をもたせたもの」である。
今ではやっぱり違うかなと思っています。上述の「ユースケースの間」が無視されているように見えるためです。
2. ソフトウェアを使う人を意識する。
ソフトウェアで複数のロールを扱っていて、ロールごとに持つ権限が異なる場合。
権限そのものに関するテストでなければ、ついつい最強の「管理者」的なロールでテストをしがちということはないでしょうか。権限の限定されたロールだと、テストの準備のために権限を切り替える必要があったりと、ちょいちょい面倒が出るためです。
このやり方だと、弱い権限のロールに、ソフトウェアの何が見えないのかが隠されてしまいます。
また、たとえ持つ権限が同じであっても、ロールが異なれば見えている世界が違うはずですが、機能の入出力に注目するテストでは、この点も見過ごされがちに思います。
シナリオテストにおいては、このロールと権限を常に意識する必要があります。
そのロールのユーザが、何を知っていて、何を考えていて、何を求めているのかを意識しながら、ソフトウェアを触る。シンプルな入力系の画面でも、「この情報はこのロールの人は知っているものなのか」「この用語はこのロールの人にとって理解できるものなのか」を考える。このような視点は、入力値のバリエーションとその出力を検証する機能テストではあまり現れません。
突き詰めると、「この人は、このソフトウェアを、自然に使えるか」ということを検証したいんですね。
よってシナリオテストの各ステップには、「どのロールとして行うか」を明記して、テストをする人はそのロールになりきる努力が必要です。
あとがき
シナリオテストにおいて意識するとよい2つのことについて、書きなぐりました。
もう少し、具体的なソフトウェアを例にとって述べられるといいのですが、本業に抵触すると面倒なので、抽象的な話になります。。。
シナリオテストは、テストの中でも特に面白いと個人的には思うので、もう少し方法論作られたらいいなあ（ずっと言ってる）。
