この記事は Autify Advent Calendar 2022 の21日目の記事です。
昨日は VeriServe Advent Calendar 2022 の20日目に「PICTで制約条件をORでなくINで書いたら組み合わせ生成が爆速になった話」という記事を投稿しましたので、良かったらそちらもご覧ください。
はじめに
現在、私は株式会社ベリサーブで、GIHOZ（ギホーズ）というテスト技法クラウドツールの開発に携わっています。GIHOZの開発チームはアジャイル開発を採用しており、新機能の開発に合わせて、フロントエンドのコンポーネントのテストコード、バックエンドのAPIのテストコード、AutifyでのE2Eテストのシナリオ、といった形で、いくつかの自動テストを作成して品質を担保するようにしています。この記事では、これらの各テストを「コンポーネントテスト」「APIテスト」「E2Eテスト」と呼びます。
これらのテストを作るときに考えないといけないのが、「コンポーネントテスト・APIテスト・E2Eテストで、それぞれどんなテストを実施するか？」ということです。
今回は、その検討のためにテスト開発の方法の一つとして有名なVSTePというやり方を試してみました。
VSTePの詳細は、以下のスライドなどで解説されています。
VSTeP × Autify でのテストづくり
GIHOZで最近公開した「オーガニゼーション」という機能に関して、どんなテストを実施するか検討してみました。実際に使ったツールはMiroです。
1. テスト観点図の作成
VSTePでは、最初にテスト観点図を作成します。上記の資料では、テスト観点は「何をテストするのか（テストケースの意図）のみを端的に記述したもの」と説明されています。テスト観点図は、テスト観点をツリー構造で階層的に記述していきます。
たとえば、オーガニゼーションに他のメンバーを招待したり権限を管理したりする機能に対するテスト観点を以下のように挙げてみました。これで十分なのかというツッコミがありそうですが、あくまで一例として見ていただければと思います。
この例では、オーガニゼーションのメンバー管理の機能を階層構造で分解していって、動作に影響する条件もテスト観点として洗い出した形になっています。
オーガニゼーションのメンバー数には上限が設定されており、上限を超える場合は招待の送信ができない仕様のため「オーガニゼーションのメンバー数」というテスト観点が出ていたり、招待のメールには有効期限が設定されているため「招待メールの有効期限」というテスト観点も出ています。
オーガニゼーションの機能全体に対するテスト観点図は以下のようになりました。画像が粗いですが、サイズ感は伝わるかと思います。
2. テストフレームの作成
テスト観点図を作成したら、テストフレームと呼ばれるものを作成していきました。テストフレームは、前述の資料では「テストケースのひな形」や「テストケースの構造を表すテスト観点の組み合わせ」と説明されています。
ということで、テストケース（Autifyであればテストシナリオ）を作るために必要な観点の組み合わせを考えて、以下のようにテストフレームを作りました。メンバー招待をテストするためのテストフレームの例です。
全体ではもっとたくさんテストフレームを作りましたが、この記事では割愛します。
3. テストフレームごとにどのテストで実施するか振り分け
どのテストフレームを、コンポーネントテスト・APIテスト・E2Eテストのどのテストで実施するかを振り分けました。コンポーネントテストやAPIテストで実施できるものはそれらに振り分けて、E2Eテストはユーザがよく使う部分でハッピーパスを通すようなテストを、主に振り分けています。
たとえば、一番上のテストフレームは、オーガニゼーションのメンバー数に応じて招待の送信ができるかどうかを確認するテストを表し、これはコンポーネントテストとAPIテストに振り分けました。
上から二番目のテストフレームは、招待メールを送信して実際にメンバーが参加できることを確認するテストを表し、これはE2Eテストに振り分けました。
コンポーネントテストではメンバー数に応じてフロントエンドの操作制限が切り替わること、APIテストではメンバー数に応じてAPIの実行結果が変わること、E2Eテストでは招待メールを実際に送信してメンバーが参加できること、といった形で確認する内容を振り分けた形です。
4. Autifyでのテストシナリオの作成
ここまでできたら、E2Eテストに振り分けたテストフレームについて、Autifyでテストシナリオを作成していきます。
GIHOZ開発チームではJiraでバックログを管理しているので、E2Eテスト作成のタスクをバックログに入れて、受け入れ基準として、作成するテストシナリオを書き出して管理するようにしました。下図はその一部です。受け入れ基準の第2階層の1行が、テストフレーム1個に対応します。
バックログにMiroのURLを貼ってそちらを参照するようにしても良かったかもしれませんが、テストフレームを作成した人とAutifyでテストシナリオを作成する人が別々の場合、文章で書いておいたほうが認識の齟齬が少ないかなと思って、今回はこのようにしました。
Autifyでは、受け入れ基準の第2階層の1行を、1個のテストシナリオとして、シナリオ作成しました。下図はAutifyで作成したシナリオの一部です。
Autifyでのシナリオ名は、長くなり過ぎないように、受け入れ基準の第1階層の文字列を使っているものもあります。Miro上のテストフレーム・Jira上のバックログの受け入れ基準・Autify上のシナリオの紐づけを管理する方法については、検討の余地がありそうです。
おわりに
どんなテストをAutify（＋それ以外の自動テスト）で作るかを検討するために、VSTePというテスト開発の方法を試してみた、という記事でした。
なんでもかんでもAutifyで自動化しようとするのではなく、「どんなテストをどのテストで作るのか」をきちんと考えて適材適所でAutifyを活用することで、より良いQAができると思います。
今回はVSTePを試しましたが、「どんなテストをどのテストで作るのか」を考えるやり方はVSTePだけではありません。チームごとに様々なやり方ですでに実施されていることもあるかと思います。
他のやり方を調べて試したり、チームでどんなやり方が良いかを議論して改善していくと良いでしょう。GIHOZの開発チームも、引き続きチームで議論してテストのやり方やAutifyの活用の仕方を改善していこうと思います。
Autify Advent Calendar 2022の記事の割には、あまりAutifyの話をしなかった気はしていますが、Autifyを活用する方法の一案ということで、ご容赦ください。汗