【QAチームブログリレー4日目】
こんにちは！ エムスリーエンジニアリンググループ QAチームの城本（@yuki_shiro_823）です。普段は担当しているBIR（Business Intelligence and Research）チームで品質向上のためにあれこれしています。
今回はE2Eテスト自動化サービスmablを利用してテストケースを作成・運用していく際に、レビュールールを作った話を紹介します。
前提
エムスリーではテスト自動化にローコード自動化サービスmablを利用しています。 mablとはブラウザの操作を記録することにより、ローコードでテストケースの作成を行えるテスト自動化サービスです。
エムスリーでは複数のチームがあり、mablを導入するときは私の担当するBIRチームでまず導入を行い、効果を検証してから他のチームへ展開しました。
ルールの必要性
mablを他のチームへ展開するにあたり、いくつか問題点が出てきました。
どれが自分のチームのテストケースか分かりづらい
人によってコメントの付け方や何をflowにしているのかが異なる（flowはmablの機能で、一連の操作をまとめて共通部品とし、他のテストケースでも使い回せるようにしたものです）
複数人で運用できるようにしたかったため、自分の作ったテストケースのメンテナンスを他の方が担当する可能性もあります。そのため誰が見ても一定の分かりやすさを保つためにルールを作成することにしました。
ルールの作成プロセス
ルールの作成は、mablでケースを作成している各チームから、分かりやすくするために行っている工夫をそれぞれ持ち寄って行いました。持ち寄ったものの中から、共通ルールとして価値がありそうなものをピックアップしドキュメントにまとめました。まとめたものを各チームで展開し、そこからフィードバックをもらって改善しています。
ルールの詳細解説
作成したルールの一部を紹介します。
命名規則
複数チームでmablを利用しているため、どれが自分のチームのものか明確にするために命名は全般的に以下のルールで行うようにしました。
「チーム名-サービス名-（テスト対象機能）-（実施操作）」
命名ルールはテストケースやラベル、テストケースをまとめたプランに適応しています。テストケースの内部で使うflowやスニペットにも同様のルールを使っています。フィルタして自分のチームに関連するものだけ表示するのが楽になりました。
作成上のルール
「人によってコメントの付け方や何をflowにしているのかが異なる」問題や、複数人でのメンテナンス・運用に対応するため次のようなルールを設けています。
- コメントを適宜入れているか
- 実行内容に応じて適切に結果を確認しているか
- 同手順が複数ある場合flow化しているか
- 1日に複数回実行可能か
- 自動テストと分かるデータで入れているか
- テスト実行時間は長すぎないか
- テストに影響のないステップは削除しているか
それぞれについて少し説明していきます。
コメントを適宜入れているか
mablに限らない話ですが、テストケースが長くなるほど何をやっているか分かりづらくなるため、適宜コメントを入れて説明することとしています。
実行内容に応じて適切に結果を確認しているか
実行した操作に対して、適切に確認するステップを入れるようにしています。手動テストだと暗黙的に確認していることも、自動テストのときには明示的に確認する必要があるのでルールとして明記しています。*1
同手順が複数ある場合flow化しているか
同一テスト内や類似テストにて、同手順が度々出てくる場合flow化することと、既存の汎用flowがある場合、そちらを利用することを推奨しています。ログイン、ログアウトなどよく使う処理はflow化して使っています。
また、既存のflowに手を入れる場合は関係者に連絡を入れることもルール化しています。flow化されているものは基本的に複数のテストケースで使われているので、修正によって他のテストケースが動かなくなることを防止するためです。
1日に複数回実行可能か
こちらもmablに限らない話ですが、自動テストは1日何度実行しても結果が変わらないことが求められます。複数回実行しても結果が変わらないことを作成者が確認し、どうしてもできない場合などは回避策を書くことをルール化しています
自動テストと分かるデータで入れているか
自動テストで入力するデータは、末尾に日付時刻や自動生成したランダム文字列を追加することで、自動テストで作成されたものであることが明確になるようにしています。自動テストと手動テストを同じ環境で使っている際データの区別をつけやすくしたり、自動テストでなにか問題があったときに調査しやすくするためこのルールにしました。
あとは一意に決まる名称にしておいたほうが、assertionを入れるときに楽という理由もあります。
テスト実行時間は長すぎないか
目安として「Step数については100、実行時間については15分以内」を推奨しています。この数字については、これ以上長くなるとメンテナンスする際に面倒という理由で決めました。*2
長すぎる場合は分割を推奨しています。
実行時間についてはmablの公式のドキュメントでも最適化の記事が出ていますので参考になります。
テストに影響のないステップは削除しているか
これはmablのようなキャプチャ＆リプレイを行う自動化ツールで必要になってくる処置です。行った操作をそのまま記録するので、テストケースには不要なステップが残ります。
例えば、ログインIDを入力する手順を記録すると、「ログインIDのテキストボックスをクリックする操作」と「ログインIDを入力する操作」の2つが記録されるパターンです。この場合は「ログインIDを入力する操作」だけあればよいので、「ログインIDのテキストボックスをクリックする操作」は削除します。
クリックする操作が残っていると実行時間がその分長くなってしまうので入れています。
レビューフローのルール
テストケースの作成者が上記の作成ルールに沿っているかセルフチェックした上で、チーム内でレビューを依頼するフローにしています。mablにはブランチ機能があるので、大きな修正を加える場合はブランチの使用を推奨しています。ブランチでレビューし、OKであればmasterにマージします。
ルールの運用と効果
現状、自動テストの作成にこのルールを適用することで、初めて自動テストのケースを作成するメンバーでも一定のレベルを保って作成できていると思います。副次的な効果として、レビューアになると他のメンバーがテストを作成する際に行っている工夫を知って自分が作成する際にも取り入れるなどの効果もありました。
また週一で有志メンバーでmablの勉強会を行っており、その中で不定期で他の人が作成したテストケースを眺める機会を設けています。そこでも他の人が行っている工夫を知れたり、より詳しいメンバーから質問や提案をもらえたりするいい場となっています。
まとめ
mablを複数チームで運用するにあたり、作成ルールをまとめました。課題となっていた点が解消でき、次の効果が得られたと思います。
命名規則で統一したことにより自分のチームのテストケースやプランが分かりやすくなった
ルールに則ることで、誰がテストケースを作成しても一定の品質を保ったものができ、メンテナンスもしやすくなった
テスト自動化サービスを使っている方になにか参考になれば幸いです。
We're hiring！
QAチームでは自動テストを活用しながら、サービスを届けるまでのリードタイム短縮に貢献したいエンジニアを募集しています。 社会に役立つシステムを高品質で素早く届けたいQAエンジニアの方、一緒に働きませんか？ カジュアル面談でより詳しくお話ししましょう！
