シナリオテストをやってみて

イートスマートの新人エンジニアが、今回はシナリオテストをやってみて学んだことを振り返っていきます。

シナリオテスト実施の背景

弊社が提供する料理教室情報サイト「クスパ」の方で、新たな機能を追加し、リリースさせるという流れがあります。

実施したシナリオテストについて

今回行うことになったシナリオテストでは、大きく二つの観点から検証が必要になります。
①料理教室を主催する「先生」の教室管理サイト側
②料理教室を探す「生徒」のユーザーサイト側

以下、実施したテストの一部になります。
・先生側のプラン変更に伴い、利用できるようになった機能のテスト
・生徒と先生の双方向性のあるコミュニケーション機能のテスト
・SNS連携を利用した機能、投稿機能のシェアなどに関するテスト

各シナリオについて、デバイス毎(PC、iPhone、Android)によってテストを行いました。

シナリオのサンプルを作成してみる

ここで、もう少し具体的にイメージできるように実際のシナリオ形式に近いサンプルを作ってみます。 シナリオは、プロジェクトの管理者や実装するエンジニアなど複数人が見ることになるので、状況を再現しやすいように 記述するのが望ましいかと思います。
この例では、生徒が料理教室を「お気に入り」登録→「お気に入り」した生徒に対し、先生がイベントを招待→生徒は、イベントの参加に対し、 意思表明ができる→先生は、「参加」を選んだ生徒にのみ「お礼メール」が遅れるというシナリオを想定しています。

スクリプトテストと探索的テスト

テストを実施していく中で、テストの手法としてどんなものがあるのか興味をもったので 調べてみました。

今回行ったシナリオテストは、いわゆるスクリプトテストに属するということがわかりました。あらかじめ設定したテストケース(シナリオ)を用意し、ドキュメントベースで動作確認を行っていきます。おそらく一般的にどこのWeb系企業も行っている手法でしょう。

スクリプトテストと対比される手法として、探索的テストというものがあります。 探索的テストは、あらかじめテストケースを用意せずに、テストを実施していく過程でテストケースを作っていくという手法になります。 メリットしては、膨大なテストケースを予め用意する必要がないこと、テストケースに縛られることなく、バグが潜んでいそうな分野に集中してその都度テスト内容を検討していけるという柔軟性があります。

探索的テストの導入の可能性

今回スクリプトテストを中心に行いましたが、振り返ってみて探索的テストを中心にプロジェクトに導入するというのは難しいと感じました。理由は以下の点になります。

①自分を含めテスターのサービス・機能に対する理解がテスト初期段階で浅かったため
②チェックする機能が広範囲にわたるため、網羅性を担保できない(ゆえに、不具合が潜んでいそうな部分の特定も難しい。)
③テスターとして動員できる人数、リリース時期のスケジュール感の問題

テスト終盤になってくるにつれて、サイトや機能についての理解が深まってきます。そのため、①の問題点は徐々にクリアする余地がでてきます。

まとめると、導入する場合は、スクリプトテストを一巡した後半で、③との兼ね合いを考慮し、同一のテスターが探索テストを実施してみるのはありではないでしょうか。

シナリオテストを実施してみての総括

シナリオテストをやってきて、最初はシナリオってこんなに在庫あるの！？って感じたり、多数のユーザー間の行き来していく中で、いま俺誰アカウントだっけ？となったり、テスターの苦労が少しわかった気がしています。そうすると、既に実施したテストでこういう問題があったから、次のテストもこうなるだろうという予測。あるいは、PCで確認した際に、スマホではどういう見え方になるんだろう？といった疑問が湧いたりします。時には、夢にも出てきます。そういった経験の中で、以前よりもテストの落とし所が見えてきたり、逆に新鮮な発見があったりします。普通に電車でスマホをいじってるだけでは、見過ごすようなものばかりです。

何よりも収穫であったのは、細かい部分に注目してサイトを見るようになるので、自社のサービス自体に詳しくなれたことだと思います。料理教室の先生と生徒双方のサイトを往復し、生徒になったり、先生になったりというような経験は日常でそう作れるものではありません。納期がある以上、テストを手際よくやっていくことも必要ですが、探索的にテストをしてみるという機会も作ってはいかがでしょうか。

以下、参考にした記事になります。 探索的テストについて