はじめに
こんにちは、hacomono SETチームのモーリーです。
こちらはmabl Advent Calendar 2023 20日目の記事です。
hacomonoではリグレッションテストをmablで自動化しており、mablのテスト数は200にも届きそうな状態です。この記事では、新しくhacomono SETチームに参画した私が、mablでリグレッションテストの自動化に取り組む過程で助かったmablの運用ガイドラインについてご紹介します。
hacomonoのmabl関連資料の紹介
hacomonoでは下記のmabl資料を用意しており、新しいメンバーは資料を読み進めながらキャッチアップと実際にテストを作成するようにしています。
1. 自動テスト作成環境の構築方法
- 開発環境の構築方法
- 自動テスト用初期データのインポート方法
- ローカル実行のやり方
2. 運用ガイドライン
- 命名規則
- ブランチ名
- テスト名
- フロー名
- テスト実装フロー
- テストの新規作成方法
- フローの作成方法
- エコーの使い方
- レビュー依頼
- マージ後の作業
mablのテストを動かすまでに助かったポイント
自動テスト用初期データのインポート
通常の開発環境構築手順に加え、hacomonoでは自動テストのための初期データを簡単にセットアップする方法が提供されています。
これにより、新しいメンバーでも１コマンドで環境を初期化し、自動テスト環境を容易に再現できるので、容易に環境の準備が終わりすぐに実装に取りかかれました。
ローカル実行のやり方
mablではクラウド実行とローカル実行があります。この中でローカル実行は何度でも可能ですが、クラウド実行は契約上限までとなります。
実行の種類の情報とやり方がまとまっているおかげで、うっかりクラウド実行の実行回数を使うことなく、すぐにテストの作成が始められました。
運用ガイドラインの助かったポイント
とてもありがたいことに複数人での自動テスト開発を想定した運用ガイドラインがあります。 ガイドラインでは、ブランチ名からテスト名、フロー名まで命名規則が決められており、単純に一覧で見やすくなるだけでなく、新しいテスト作成者にとって命名で悩む必要が少ないことでも助かっています。
ここでは、特に助かっているポイントについて参画者視点で紹介させていただきます。
1. 命名規則
ブランチ名
ブランチ名にはテスト管理番号と作業者の名前で構成するようになっています。 これにより誰が何の作業しているのかわかりやすくなっていて、ブランチの乱立を防いでいます。
余談ですが、mablのサポートの方が調査される際にブランチを作成されることもあるみたいですが、それもひと目で判別がつきます。
フロー名
フロー名には画面のパスを接頭辞として付与していて、フローを探すことや、重複したフローを作成してしまうことの抑制にも役立っています。 細かい書式指定もあり、たとえば画面名を表す場合は「」で囲う、画面上の文言を表す場合は””で囲う、などがあります。
慣れるまで少し大変ですが、あとから検索したりするときにとてもわかりやすいです。
2. フローの作成方法
運用ガイドラインには、基本的にテストはフローで構成する方針が掲載されています。 既にあるフローを組み合わせることでテストの実装が容易になり フローが充実しているおかげで新しいメンバーでも効率的に作業できています。
もうちょっとなポイント
助かるポイントと同時に、一部改善の余地がある点も挙げてみます。
1. 目的のフローが見つかりにくい
運用によりフロー名が統一されていて検索しやすい状態ではありますが、残念ながらmablでフローを複数キーワードできないことと、フローの数がとても多くなったことで目的のフローを探すときに少し手間がかかります。
画面パスで検索したあとにフローを目視で探すのがつらいところで、ある程度の慣れが必要です。 その点に関しては便利なフローの紹介資料もあり、利用頻度の高いフローはキャッチアップできるようになっています。
2. フローを汎用化させるコストが高い
フローは１箇所だけでなく様々な箇所で利用されます。そのためフローにするだけでは、このテストではうまく動いても、あのテストではうまく動かない、というようなことがあります。
操作の記録を利用した場合にこの問題が出ることが多く、ステップの検索の設定から属性を選択することで解決することもありますが、そうでない場合もあります。 そのときはXPathを指定するようステップを作り直したり、javaScriptスニペットを利用したりします。この作業は容易ではないので、場合によってはもう一つフローを作ってしまうのも手かもしれません。
あるとよかったかも運用ガイドライン
あとあとわかって苦労しているポイントについても紹介します。
1. フローの適切なステップ数
フローのステップ数が多い場合、目的のフローを選んだつもりでも目的外の操作を含んでいたり、不要な条件分岐があったり、何に使うパラメーターかわからず操作内容を確認するのに必要以上に時間がかかったりします。
hacomonoではテスト作成後にレビューをするようにしていますが、全てのフローをチェックするのは負荷が高いので、フローのステップ数上限を決めて分割するなどのガイドラインを定めることは役立つかもしれません。
2. 変数のスコープ
mablには環境変数やテスト内の変数などがあります。ただし、mablの変数のスコープは少し自由な使い方ができてしまいます。例えば変数Aを生成したあとに、パラメーターを使わずにフローの中で直接変数Aを利用したり、上書きしたりできます。環境変数も、テスト内で上書きすることができます。
変数の管理をしていない場合、同じ名前の変数を作ってしまうと意図せず上書きしてしまい、うまくテストが実行できないことになります。あらかじめフローで変数を利用するときはパラメーター経由で渡す、などがあると思わぬ失敗を防いだり、可読性が向上すると思います。
おわりに
mablを複数人で利用するにあたり、適切なガイドラインが運用されていれば、新しいメンバーが参画してもつまづくことなく効率的にテスト自動化を進めることができています。 資料からわかりやすい運用ガイドラインとその浸透まで進めてくれていたメンバーには感謝しかありません。
株式会社hacomonoでは一緒に働く仲間を募集しています！
採用情報や採用ウィッシュリストも是非ご覧ください！
