なぜシナリオのステップ数を少なく抑えた方が良いのでしょうか？

概要

多くの場合において、シナリオのステップ数は少ないほうが好ましいと言えます。この記事では、シナリオを小さく保つことのメリット、また、どうすれば既存のシナリオを小さく切り分けていくことができるかについて説明します。

シナリオのステップ数を少なく保つことによって以下のような効果が得られます。

• 小さいシナリオは、あまり複雑になりません。簡単に読み解き、理解することができます。
• リプレイに時間がかからないので、素早く再レコーディングや調整を行うことができます。結果として、メンテナンスコストが低くなります。
• テストの実行時間が短くなります。シナリオのアップデートを行った後、すぐに実行結果を確認することができます。
• シナリオ内で発生した問題を、他のシナリオから分離しておくことができます。ある箇所でバグが見つかり、その結果テストが失敗したとしても、他の部分を確認するシナリオは成功するでしょう。結果として、あなたのシナリオのセットは全体として安定的に動くようになります。

反対に、シナリオが長くなればなるほど、結果は不安定 (QA用語では「Flaky (フレーキー)」) になる傾向があります。

テストを小さく作る方法

1. チェック項目をリストアップする

たとえば、あなたが自社のブログサービスをテストしているとしましょう。

すると、チェック項目の一覧は以下のようになるはずです。

1. ブログサービスのロゴがページの上部に表示されている。
2. 新しいユーザーを作成することができる。
3. 既存のユーザーアカウントでログインを行うことができる。
4. ブログ記事を投稿することができる。
5. 既存のブログ記事を編集することができる。
6. 既存のブログ記事を削除することができる。
7. 既存のブログ記事に対して「いいね」をすることができる。
8. 「いいね」を取り消すことができる。
9. ログインした後、ログアウトを行うことができる。
10. 既存のユーザーを削除することができる。

これら一つ一つの項目が、シナリオを構成する最小単位となります。

2. チェック項目のリストを小さなグループに分ける

小さければ小さいほど良いと考えてください。一つのチェック項目のみでグループを作れるなら、そうしましょう。

あるいは、カテゴリー毎（ユーザー関連のシナリオ、ブログ記事関連のシナリオ等）に分けることもできます。

もしかすると、あるチェック項目は、他のチェック項目の結果に依存しているかもしれません。たとえば、既存のユーザーを削除するためには、あらかじめユーザーを作成しておかなければなりません。この場合は、この二つの項目を同じグループに含めても良いでしょう。

E2E (エンドツーエンド) テストの利点の一つは、依存関係排除することが難しいか、一緒にテストすることが望ましい機能や操作をまとめて検証できることです。ただし、こうした依存関係は必要最小限に留めるようにしましょう。シナリオの中にあまりにも多くの依存関係が存在すると、一箇所で予期せぬ問題が発生しただけで、全てがうまくいかなくなってしまいます。シナリオの中に長い準備作業を含めるよりも、後述のフィクスチャを用意することをお勧めします。

さて、以下がグループ分けしたチェック項目の例です。

• シナリオ 1: ロゴの確認
  • ブログサービスのロゴがページの上部に表示されている
• シナリオ 2: ユーザーの作成と削除
  • 新しいユーザーを作成することができる
  • 既存のユーザーを削除することができる
• シナリオ 3: ログインとログアウト
  • 既存のユーザーアカウントでログインを行うことができる
  • ログインした後、ログアウトを行うことができる
• シナリオ 4: ブログ記事の投稿と削除
  • ブログ記事を投稿することができる
  • 既存のブログ記事を削除することができる
• シナリオ 5: ブログ記事の編集
  • 既存のブログ記事を編集することができる
• シナリオ 6: 「いいね」とそのキャンセル
  • 既存のブログ記事に対して「いいね」をすることができる
  • 「いいね」を取り消すことができる

このグループ毎に、小さく切り分けられたシナリオを作るようにしましょう。

3. ステップグループを使う

グループ分けされたリストをよく見ると、ほとんどのシナリオでは、何かを検証する前に事前にログインを行う必要があることに気づくでしょう。ログインを行うステップを、複数のシナリオに対して個別に、手作業で追加していくのは面倒です。かわりに、これらのステップを再利用可能なコンポーネント、すなわちステップグループにまとめ、シナリオの先頭に配置することができます。

ステップグループを使用してもシナリオのステップ数が減るわけではありませんが、複数のシナリオで重複している箇所をまとめることで、メンテナンス性を向上させることができます。

「小さいほど好ましい」という原則はステップグループにも当てはまることを覚えておいてください。ログイン作業のためのステップグループに、ログインとは関係のない操作を記録するのは避けたほうが良いでしょう。たとえば、ログイン画面の UI をチェックしたいのであれば、それは別のシナリオに切り出すべきです。

4. フィクスチャを用意する

Fixture (フィクスチャ) とは、あなたがテストを行うにあたって必要となる前提条件のことです。テストの実行前に用意しておくデータも、フィクスチャに含まれます。たとえば、ログインとログアウトを検証するために必要なユーザー、編集機能を検証するために必要なブログ記事などを指します。

このようなデータはシナリオの中で作ればよいと思われるかもしれません。しかし、作成のための UI が頻繁に変化する場合には、テストの安定性が損なわれます。開発チームが、ユーザー作成を行うサインアップページを改修している場合などを想像してみてください。開発作業の影響で「シナリオ 2: ユーザーの作成と削除」の実行結果は不安定になる可能性があります。それでも、あらかじめユーザーデータを作成しておけば、「シナリオ 3: ログインとログアウト」はその影響を受けずに検証を行うことができるでしょう。他の条件によって影響を受けない、一貫したデータを用いてテストを実施することで、安定性が高まります。

フィクスチャを手作業で用意するのは、最もシンプルなアプローチです。一方、ビルドやデプロイプロセスの中に、テストデータを自動で作成するような仕組みがすでにあるなら、 Autify の CI/CD 機能を活用して、より効率的にテストを進めることもできるでしょう。