4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

VeriServeAdvent Calendar 2022

Day 21

ノーコードテスト自動化ツールにおける自動テストシナリオの分割単位について考える

Last updated at Posted at 2022-12-20

はじめに

新たにUIテストの自動化に取り組むとき、既存の手動テストスクリプトを参考に自動テストスクリプトを実装したり、新たに自動テストスクリプトを実装することになります。
その際、一つのテストシナリオをどのくらいの長さにすればよいのか悩むことがあります。
当然、何をテストするのか、どれくらいテストをするのかという視点も重要ですが、ここでは何をどれくらいテストするのかが決まった上で、自動テストスクリプトをまとめたり、分割したりするときに考慮すべき点について考えてみます。
使用するテスト自動化ツールによっても考慮すべき点が変わってくるため、これまで私が業務の中で携わったノーコード/ローコードテスト自動化ツールであるAutify、MagicPodを使う場合を考えます。

SaaSサービスならではの悩み

OSSのテスト自動化ツールと異なり、契約プランによって作成できるテストケース数や、テストの実行回数の上限が定められている場合があるため、
自動テストシナリオの数をできる限り少なくしたい、という要望があるかもしれません。
ただ、一つの自動テストシナリオの中で様々なことを確認しようとすると、問題が起きることがあります。

ステップ数を考慮する

2022年12月現在、AutifyとMagicPodでは機能的にステップ数の上限は定められていませんが、ステップ数が増加すると、実装環境のハードウェアスペックによっては動作が重くなったり、テスト結果の参照に時間がかかるため、ステップ数の増やしすぎには注意が必要です。

Autifyでは、サポート対象のステップ数は200ステップまでと定められています
https://help.autify.com/docs/ja/what-is-the-maximum-number-of

MagicPodでは、プランにより画像差分チェックステップ数の上限が定められている場合があります。(通常のステップにおける上限はなし)
https://magicpod.com/pricing/

実行時間を考慮する

ISTQB Advanced Level シラバス テスト自動化エンジニアでは、テスト自動化の目的として「テスト実行期間の短縮」や「テスト実行頻度の向上およびテストサイクルに要する時間の短縮」などが挙げられています。
テスト自動化の利点である迅速なフィードバックを享受したい場合は、実行に時間のかかる自動テストを見直す必要があります。

また、自動テストの実行時間が長いと、失敗したテストを調査するための時間や、自動テストスクリプトの保守の際、修正対象のステップに行き着くまでの時間が長くなるといった欠点もあります。
そのため、実行時間が長い自動テストシナリオは分割することができないかを検討してみましょう。

依存関係を考慮する

テストシナリオの中でデータを作成後、作成したデータを使って別のテスト観点を確認するような場合、分割を検討したほうがよいケースがあります。
例えば、ECサイト等でユーザアカウントのサインアップを行ったのち、登録したユーザアカウントでサインインし、注文フローを確認するようなシナリオがあったとき、サインアップとサインインを一連の流れとして行うべきなのかを検討してみましょう。

ただし、テストシナリオAで作成したデータを、テストシナリオBで参照するような場合、ふたつのテストシナリオに依存関係が生まれてしまい、テストシナリオAでテストが失敗したとき、テストシナリオBでもテストが失敗することになるため、テスト失敗時の再実行が容易に行えなくなる可能性があります。
そのため、分割をしすぎてテストシナリオ間での依存関係が生まれないように留意することも重要です。

なお、テストの前提条件を満たすためのデータの初期化などはWebAPIを提供してもらい、UI操作を行わずとも前提条件を整えられるようにすると良いでしょう。

テスト対象やテストのコンテキストを考慮する

テスト自動化の目的によっても変化する部分ですが、迅速なフィードバックを得ることを目的とするのであれば、テスト対象の機能や、テストのコンテキストで分割することを検討します。

例えば、DBのマイグレーションが行われたときにはデータのCRUDを意識したテストを実施したいですし、フロントエンドフレームワークのバージョンアップが行われたときはUI表示を確認するテストを実施したいです。
自動テストの規模が大きくなるほど実行時間も長くなり、フィードバックも遅くなってしまうため、必要なときに必要なテストが必要な分だけ実行できる単位での分割を検討するとよいでしょう。

おわりに

ノーコードテスト自動化ツールにおける自動テストシナリオの分割単位について考えてみました。
実装の際に少しでもご参考になれば幸いです。
また、「こんな視点でも考えたほうが良い」という点があれば、コメント欄にてお知らせいただけると嬉しいです。

4
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?