mablでのテストケース管理や運用ノウハウまとめ #mabljapan

この記事ではQA自動化ツールmablの運用方法をまとめます。とりあえずmablの基本的な使い方は mablが公開しているドキュメントやよく使う機能を日本語訳したこちらを参考にしてください。

mablの登場人物

mablには以下のような概念でテストや関係するものを整理しています。まずはそれぞれの意味合いを解説します。

Environment

テストする環境です。一般的には、DEV、STG、Production（本番）のようになっていると思います。

それぞれの環境に対して、次に登場するApplicationを設定することで、テスト対象（Application）とテスト環境（Environment)を整理できます。

本番でのテストは注意が必要ですが、基本的にひとつケースを作れば、それぞれの環境で動かせるはずなので、実行回数は増えますが（mablは実行回数ベースの料金システム）、テストケースを複数環境で活かせるのは大きなメリットです。

さらに、後述するPlanでクロスブラウザを指定できるため、

ひとつのテストｘ環境ｘクロスブラウザ

と簡単にスケールさせられます。

Application

テスト対象となるアプリケーションです。URLで区別します。

Applicationごとにフィルタをかけて表示できるため、テスト対象が多い場合や、アプリごとに担当者が分かれる場合は、フィルタを活用すれば便利です。

Plan

テスト実行計画です。テストをどうやって実行するか設定できます。クロスブラウザの設定や特定のHTTP Headerを設定するのもここでやります。

Planの運用をはじめるまえに、どのタイミングでテスト実行するかの設計が必要です。以下の例でタイミングを整理しますが、開発プロセスによって多少の違いがあるかもしれませんが、一般的に下に行くほど実行タイミングが多くなっていくはずです。

まずはリリースやデプロイをベースとしたテストのタイミングです。

リリースごと（本番）
デプロイごと（STG）
デプロイごと（DEV）
デプロイごと（ローカル環境）

採用する開発フローによって違いがありますが、ソース管理ベースのタイミングも検討できます。

タグがつけられた
マスターにマージされた
リリースブランチができた
コミットごと

次に定期実行による、既存機能が壊れていないかの確認テストです。

週末実行（特に時間の長いテストを中心に）
夜間早朝実行（1日1回）
営業時間実行（9時〜17時で2時間毎など）
指定した時間ごと（1時間毎など）

Test

テスト本体です。mablはE2Eテストにぴったりなサービスなので（APIの単体テストも可能だけど）、Testはブラウザを介したE2Eテストシナリオとなります。テスト作成で考えるべき点は以下です。

テストの粒度

どの粒度のテストにしていくかを決めるために、ステップ数や実行時間を基準にできます。

最大ステップ数：長すぎるシナリオを抑制
最大実行時間：長すぎるシナリオを抑制

経験則ですが、ステップ数が多すぎるとメンテが大変なので、50ステップ（5分以内で終わるレベル）以下が理想です。

実行時間は「テストで待てる時間」が基準になります。毎回のリグレッションで1時間待てるのであれば、最大1時間以内のテストになります。

最大1時間とは、直列実行だと全テストを1列につなげて1時間以内。並列実行だと1テストが1時間以内になります。ステージを分ける場合はそれぞれのステージが直列になりますね。

ただ、1時間のテストは長すぎます。途中で失敗したら残りの部分のテストができません。テストケースの作り方で工夫はできますが、経験的に15分以内におさめておくのが良いと思います。

テストの特性

テストの特性によってTest自身やPlanを分けたて実行したほうがいい場合があります。

たとえば、バッチ処理を待つ必要があるテストなど、特定の時間がかかってしまうテストは、それにひきずられて他のテスト実行時間が長くなってしまうのを防ぐため、別のPlanに分けたほうがいいはずです。

さらに、複数ユーザでメッセージをやり取りするテストなど、ひとつのテストでやるか、別々のテストでやるか検討が必要です。

ひとつのテストにまとめると、「Aユーザでログインしてメッセージを送ってログアウト、Bユーザでログインして受け取っていることを確認」・・・とステップ数が倍増してしまいます。仮にAユーザのテストに失敗したら、Bユーザのテストは実行されません。

逆に分けた場合、「AユーザがUI経由でメッセージ送信 ⇒ DBでデータ確認」「APIでメッセージ送信 ⇒ BユーザがUI経由でメッセージ確認」といったテスト実装も検討できます。

完璧なエンドツーエンドテストを実装するのが理想ですが、やるのがむずかしいなら無理をしないでできる方法を考えるのがおすすめです。「やればできる」を求めすぎると「やりすぎて疲れる」になりがち。

テストケース管理

mablではラベルを使ってPlanやTestを整理できます（Web 2.0的）。ケースが少ないうちはそれでいいですが、ケース量が多くなる（つまり、mablが使われるようになるにしたがって）と管理が複雑になってくるため、mablの中の人にも改善要望を話しました。

一方で、世の中のテストケースは、大分類〜小分類や、機能別での整理が多いように思います（Web 1.0的）。よって、テスト設計はスプレッドシートやみんな大好きExcelで整理し、実装をmablに落とし込み、ラベルを付けて整理するのが現段階の現実解でしょう。

ラベルの観点は以下が考えられます（カッコはラベル例）。

インターフェース別（Browser、API）
実行環境別（PC、Mobile)
テストの優先度（優先度高、中、低）
テストの種類（スモークテスト、リグレッションテスト・・・）
アプリケーション（フィルタはありますがアプリ名やドメインをつけておくと見やすいです）
テストのステータス（作成中ならWIP、レビュー街ならReviewなど）

ラベルはいくらでも付けられるのがメリットなので、とりあえずたくさんつけておいて、あとで整理すればいいと思います。大切なのは簡単に探し出せる状態にすることです。

また、ラベルで絞り込んだケースをAPI経由で呼び出せたりするため、実行したい単位でのラベリングも有効でしょう。

まとめ

ここではmablの運用を整理してみました。だいぶ使い込むようになりましたが、やりながら気がつくことも多いので、アップデートがあればまた更新したいと思います。

また、こういった運用検討や、テスト自動化戦略やロードマップについて相談を受ける機会が増えているので、資料を整理してだれでも同じレベルでアウトプットが出るようにできないものかと考え中です。