こんにちは、さっちゃんです。
前編の記事では、未経験者向けに行った研修内容と、未経験者のつまずきポイントを紹介させていただきました。
今回の後編では、実際に研修生が行ったテスト設計の紹介と、そこから気付かされたことについて紹介していきたいと思います。
演習の題材について
研修生が行ったテスト設計を紹介する前に、まずはどういったシステムを演習の題材としているか記載します。
題材：WEB上で動作する予約システムの総合テスト（システムテスト）
要件：BtoCのため、一般ユーザーが行うと想定される操作は一通りテストする
仕様：以下に機能と画面を記載
機能一覧
画面一覧
今回、エラーダイアログは様々な画面で発生したり、
同じ画面内で複数エラーが発生する等のパターンも存在します。
また、「予約確認画面」「予約完了画面」については、予約ルート①・②どちらにも存在しますが、同一画面となるためテスト設計時には注意が必要です。
予約ルート①・②で選択できるメニューは以下5種類。
メニュー
・A-1
・A-2
・A-3
・B-1
・B-2
メニューはAとBで組み合わせて予約したり、A-1単体、B-1単体のみで予約することもできます。ただし、「A-1」「A-2」「A-3」はいずれか1つしか選択できません（A-1とA-2で予約、ということはできない）。
メニューの選択数によって、予約される時間の長さが異なります。
1つ選択した場合：30分枠の予約
2つ選択した場合：60分枠の予約
3つ選択した場合：90分枠の予約
細かい仕様はここでは省略しますが、これだけでもテスト設計時に気を付けなければならない仕様がてんこもりですね。
研修生の作成物（ドキュメント）から考えたこと
この演習題材で、研修生にはテスト設計を行っていただきました。
必要があればテスト技法を使うよう伝え、あとはステークホルダー役の講師とチャットや通話などで会話をしながらテスト設計をしていただきます。
完成したものをレビューしたところ、ひとりひとり全く違ったテストケースとなっていて、見ていてとても面白い結果となりました。
大体はテスト技法の使いどころによって異なっているようでしたので、以下にいくつか紹介させていただきます。
状態遷移テスト
まずは、2名の状態遷移図を見てみましょう。
※ここでは、画面遷移を状態遷移の中に含めます。
Aさんの状態遷移図
Bさんの状態遷移図
同じ演習の状態遷移図でも結構違いますね！
大きな違いとしては、Aさんはエラーダイアログは含めず、画面遷移のみ整理しており、
Bさんはエラーダイアログを含めています。
今回の仕様では、出そうと思えば色んな画面でエラーダイアログが出せたり、エラーを2つ以上重複して発生させたりできる仕様になっていますが、それをどこまでテストするかでテストケース数は大きく変わってきそうですね。
同じ演習の状態遷移図でも結構違いますね！
大きな違いとしては、Aさんはエラーダイアログは含めず、画面遷移のみ整理しており、
Bさんはエラーダイアログを含めています。
今回の仕様では、出そうと思えば色んな画面でエラーダイアログが出せたり、エラーを2つ以上重複して発生させたりできる仕様になっていますが、それをどこまでテストするかでテストケース数は大きく変わってきそうですね。
AさんとBさんのエラーに関するテストケース数を集計してみました。
2名とも、1つのエラーに対してのテスト観点は同じで、
・正しくエラーが出るか
・エラーダイアログ内の表示に崩れや誤字脱字が無いか
・エラーダイアログを閉じることができるか
上記3つの観点で確認していますが、対象とする画面数や組み合わせのバリエーションなどにより、テストケース数に170ケース程の差が出ています。
Aさんは予約ルート①側で各種エラーを3つのテスト観点で確認し、予約ルート②では各種エラーを組み合わせた際の挙動のみ確認しております。
また、エラーを確認していない画面もいくつかありますね（E006やE999等）。
Bさんは状態遷移図をもとに、発生が予想される画面すべてで各種エラーを3つの観点×組み合わせた際の挙動を確認するテストケースを作成しておりました。
予約ルート①②で確認観点は変えず、同等の観点・組み合わせで確認しています。
これはどちらが正解というわけではなく、このプロジェクトでのテスト方針がどのようになっているかが重要だと考えます。
例えば、既にリリースされていたり、開発担当者がエラー周りを単体テストでしっかり確認済みであったりなど、ある程度「動くことが保証されている状態」であれば、Aさんのようにカバレッジレベルを少し下げてテストケース数を絞り、他の重要機能に工数を割くことも必要かもしれません。
逆に、「動くことが保証されていない状態」であれば、Bさんのように高いカバレッジレベルが求められることもあります。
また、AさんとBさんの中間くらいのカバレッジレベルが求められることもあります（発生するすべての画面で確認するが、組み合わせはそれほど見ないパターン等）。
どの程度のカバレッジレベルでテストをするか、事前にステークホルダーとしっかりテスト方針を定める必要がありますね。
また、今回Aさんはエラーを確認していない画面がありましたが、どこまでテストしているか目視で分かりやすくしたり、抜け漏れを防止する意味合いでも、状態遷移図を使うことは非常に効果的だと改めて感じました。
続いて、ほかの状態遷移テストも見ていきましょう。
状態遷移テストには、「状態遷移図」のほかに「状態遷移表」というものがあります。
状態遷移図では、システムの全体像や流れをひと目で把握しやすくするメリットがありますが、各状態に対して想定するイベント・想定しないイベントを網羅的に書き表すことはできません。
状態遷移表では、それを可能にする代わりに、システムの全体像や流れは書き表せない為、通常は状態遷移図と状態遷移表をセットで使い、それぞれの利点を活用しながらテスト設計を行うことが多いです。
研修生の中に2名、状態遷移表を使っていた方がいましたので、見てみましょう。
Cさんの状態遷移表
Dさんの状態遷移表
二人とも似た表を作成していますが、実は大きな違いが！
状態遷移表には2種類の書き方があり、「状態×イベント型」と「状態×状態型」があります。
Cさんは「状態×イベント型」で、Dさんは「状態×状態型」です。
ある状態のときに、あるイベントを発生させたらどんな状態になるか？を整理するのに使用できるのが「状態×イベント型」の特徴で、
ある状態のときに、次の状態へ遷移する為にはどんなイベントがあるか？を整理したいときに使えるのが「状態×状態型」の特徴になっています。
これによるテストケース上での大きな違いはありませんでしたが、複雑な開発仕様書から状態とイベントを整理したいときに、どちらのほうが分かりやすく整理できるか？を考えて、選択していきたいですね。
私自身はつい慣れている「状態×イベント型」を使ってしまいがちになっていましたが、「状態×状態型」のほうも考慮していきたいと思いました。
ここまでで4名のテスト技法を見てきましたが、状態遷移テストだけでも、こんなに違いが出るんですね～。
ちなみに、状態遷移図のみを使った2名と、状態遷移表も使った2名の遷移・イベントに関するテストケース数を比較してみたところ、以下のようになっておりました。
Aさん：115ケース
Bさん：235ケース
Cさん：312ケース
Dさん：276ケース
状態遷移表も使った2名のほうがテストケース数が多くなっています。
これは、状態遷移図では書き表せなかった「想定しないイベント」が状態遷移表によって書き表せたことで、「遷移できないこと」「イベントが発生しないこと」を確認するテストケースが入っていることでケース数が増加しております。
開発担当者が想定している部分と、想定していない部分では、後者のほうが圧倒的に欠陥が発生しやすいため、状態遷移表も使ってしっかりテストしていきたいですね！
さて、ここまでは「状態遷移テストを使っている人同士での違い」について見てきましたが、他のテスト技法を使用している人もいましたので、紹介したいと思います。
本システムでは、予約完了までのルートが2種類存在し、どちらのルートからでも「日付を選択」「担当者を選択」「メニューを選択」して予約ができる仕様となっております。
この仕様部分のテストについて、「デシジョンテーブルテスト」や「組み合わせテスト」が使用されていました。
まずは「デシジョンテーブルテスト」のほうから見てみましょう。
デシジョンテーブルテスト
Eさんのデシジョンテーブル
こちらは予約の際に選べるメニューの組み合わせと、その結果（予約合計時間）をデシジョンテーブルでまとめています。
合計15ケースとなっており、例えばルール1ではメニューで「A-1」「B-1」「B-2」を選択して予約を行った場合に、「90分で予約される」ことを期待値として確認します。
このように、複数の入力によって出力結果が変わることを確認する際に、デシジョンテーブルテストはとても有効ですね。
組み合わせのパターンを可視化しておくことで、テストケースの漏れも防止でき、どこまでテストしているのかも一目で分かりやすくなります。
当該箇所のテストについては、研修生たちの中で以下のように粒度が分かれておりました。
①メニューの全組み合わせで予約できるところまで網羅
②各メニューを1つ選択して予約できるところまでは網羅
③メニューの中からいずれか1つを選択して予約できるところまでは網羅
①の粒度でテストしていたEさんにデシジョンテーブルテストを使用した理由について聞いてみたところ、「もしテストしていない組み合わせでの時間計算に欠陥があった場合、そのまま運用するとユーザー同士のダブルブッキングなど重大な問題になると思ったので、100%網羅できるデシジョンテーブルテストを使用したほうが良いと考えました」と説明をされていたので、「なるほどたしかに」と思いました。
本来90分かかる施術なのに、30分枠しか予約されていなかったりしたら大変ですもんね。
続いて、「組み合わせテスト」も見ていきましょう。
組み合わせテスト（二因子間網羅）
Fさんの二因子間網羅
こちらは予約の際に選べるメニューだけでなく、どのルートから予約をするかや、
日付・担当者なども含めた組み合わせで、いずれも「予約できること」を確認しています。
そして、この組み合わせを全て網羅しようとすると、テストケース数が非常に多くなってしまい、工数がかかりすぎることを予想してか、ペアワイズテストを使用しテストケース数を削減しています。
このように、どの組み合わせで入力しても出力結果が変わらないことを確認する際に、組み合わせテストはとても有効ですね。
ペアワイズテストについては、 本サイトの別記事にも掲載しておりますので、ぜひ併せてご一読ください。
EさんとFさんはどちらも「入力の組み合わせ」に着目していましたが、
Eさんは出力結果（予約時間）が”変わっていること”をテストするためにデシジョンテーブルテストを使用しており、
Fさんは出力結果（予約できること）が”変わらないこと”をテストするために組み合わせテストを使用しておりました。
このように、何をテストするか？によって、使用するテスト技法に違いが出ています。
テスト技法は非常に便利ですが、各技法の役割・目的をしっかりと理解したうえで、どれを使用するか考えていく必要がありますね。
今回の演習では、状態遷移テスト・デシジョンテーブルテスト・組み合わせテストの3つのテスト技法が出てきました。同じ演習でもここまで違いが出たことに驚きつつ、改めて様々な視点・観点でのテストがあることを認識させられました。
様々な視点・観点があるからこそ、本来やるべきテストからずれてしまわぬよう、しっかりとステークホルダーと”会話”をしてテスト方針を定めていくことが大切ですね。
最後に
私自身、テスト設計に少し慣れて、漠然とテスト技法を使ってしまっていましたが、そこにはリスクも伴うということ、本当にそれで製品の品質が担保できているのか？や、使用するユーザーにとってはどうか？というのをしっかり考えていかなければ、正しいテストとは言えないな、と改めて思いました。
また、新卒のフレッシュな空気に触れて、自分自身もフレッシュな気持ちに立ち返れた気もしますので、ここからまたたくさん学んでいきたいと思います！
