エムスリーテックブログ

エムスリー(m3)のエンジニア・開発メンバーによる技術ブログです

mablを一年運用してみた成果と課題

こんにちは! エムスリーエンジニアリンググループ QAチームの城本(@yuki_shiro_823)です。担当しているBIR(Business Inteligence and Research)チームでローコード自動化サービスmablを運用した所感を紹介します。

前提

エムスリーではテスト自動化にローコード自動化サービスmablを利用しています。 mablとはブラウザの操作を記録することにより、ローコードでテストケースの作成を行えるテスト自動化サービスです。記録によるテストケース作成やテスト実行に加え、AIを活用したオートヒーリングや画面崩れ検知の機能などを備えています。

www.mabl.com

私が担当しているBIRチームで2021年8月に導入を始めまして、今では全社的に利用が広がりつつあります。その時に行った内容は、2021年のソフトウェアテスト自動化カンファレンスで発表したこちらをご覧ください。

speakerdeck.com

この記事では導入して一年経った所感をまとめます(mablの基本的な機能などについては触れていません)

今期行ったこと

導入し始めてから2022年4月頃までに行ったことは、以下2つです - 既存サービスの自動テスト作成 - 2021年下期で新規開発したサービスの自動テスト作成

2022年の上期では主に以下2つを行いました。

  1. ユースケースの整理
    1. 見合わないものは捨てる
    2. 観点を追加
  2. 整理したユースケースに沿ってmablの削減、追加

メリット

自動テストが整備されたことで感じているメリットは2点あります。

リグレッションテストが必要なときにすぐ対応できる

セキュリティツールの警告であがってきたライブラリのアップデートなどにすぐ対応できます。ライブラリのアップデートの怖い点は、コードの変更は1行程度で済む割に影響が思わぬところにでる場合があることだと思います。

自動テストが整備されていないと手動のリグレッションテストに2日程度かかっていたのですが、ボタンかコマンド一発であとは結果のチェック(とFailedのケースがあればその確認)で済むようになりました。開発エンジニアからも「全体的にリグレッションしてほしい」というリクエストのハードルが下がったという嬉しいフィードバックをもらっています。

QA環境を正しい状態に保ちやすい

自動テストを定期実行していると、環境の変化にすぐに気付きやすくなります。例えば、DB操作のツールの実験をQA環境で行っていてデータが一部壊れてしまったことがありました。その時はデータがあることを前提に動く自動テストが正しくFailedになったことで検知し、原因を調べてもらいすぐに直してもらったことがありました。

環境の変化に気付いてない場合には、新規機能のテストで環境を使う際に、本来かけたくない待ち時間が発生してしまうこともあります。自動テストの定期実行で環境の変化にすぐ気付きやすいので、必要になった場合すぐに環境が使える状態がキープできてます。

デメリット(というか自動化により発生するコスト)

デメリットというと微妙なのですが、やはり自動テストを導入したことで発生するコストもあります。とはいえ、コストが発生してもメリットの方が上回っているので、自動テストを継続していく価値があると考えています。

継続的なメンテナンスコストが発生する

自動テストを作成しても、機能追加や仕様変更に伴って継続的にメンテナンスするコストが発生します。mablの場合は、AIを活用したオートヒーリングによりちょっとしたUI変更などには対応してくれます。しかし、ユースケースレベルで変更が入った場合は自動テストの修正・追加が必要になります。

サービス終了などでテストが必要なくなった場合は、テストケースを適切に削除するなどの活動も必要になります。

とはいえ、こちらは発生タイミングがテスト対象のシステムに何らかの変更が入った場合なので必要なコストだと考えています。

不安定なテストを作ると本来かけたくないコストが生じる

私のチームでは現在約300件の自動テストがありますが、何件か不安定なものがあります。テスト対象システムに変更がないのに、特定の何件かのテストにメンテナンス時間の多くを取られるので、あまりかけたくないコストだと思っています。

さて、不安定なテストにはいくつか傾向があります。

1. ステップ数が多い

2. Xpath/CSS Selctorを使っている

それぞれ少し詳しく見ていきます。

1.ステップ数が多い

こちらの Dai Fujihara さんの記事の「掟2. 小さく作る」に詳しく書いてありますが、自動テストはなるべく小さく作るべきです。

daipresents.com

ステップ数が多いと、失敗するタイミングがそれだけ多くなりますし、何より失敗した時の再現や調査も大変面倒です。ベストプラクティスの記事にはmablのテストケースを作るうえでの有益な内容が詰まってますのでぜひ一読をお勧めします。

ただ、どうしてもユースケース上ステップ数が多いことを許容してメンテナンスし続けているものもあります。

2.Xpath/CSS Selctorを使っている

要素の特定にXpathやCSS Selctorを使う場合もありますが、こちらを使うとUI変更の影響を受けやすくなったりオートヒーリングの恩恵を受けにくくなってしまいます。

私のチームでは開発エンジニアの協力を得て要素にidやclass名を付けてもらい、要素の特定をしやすくしてもらっています。これでXpathやCSS Selctorの問題でFailedになることは減っています。一部でXpathを使ってますが、特定しやすいclass名があることで比較的柔軟な要素の指定の仕方ができるようになっています。

コラム:mablの実行環境の違い

mablの実行環境は大まかにクラウドとローカルの2種類があります。クラウドはAIを活用したオートヒーリングやテストケースの実行順序の指定など様々な便利機能が使えますが、実行回数は上限があります。一方ローカル環境だと使えない機能があったり、mablが提供するコマンドではテストケースの実行順序が指定できません。ただ、実行回数は無制限です。

詳しくはこちらのmablのFAQをご覧ください。

help.mabl.com

クラウド実行を前提にしてテストケースを作った場合、ローカルで上限回数を気にせず実行したいとなったときに実現できない(または実現するのに一工夫いる)ことがあります。テスト対象システムの変更頻度を考慮して、クラウド環境のみか、ローカル環境でも実行したいのか、最初に住み分けの方針を決めておくべきだったと思いました。

今後の課題

mablを使った自動テストは概ね軌道に乗っていると思いますが、先ほどあげた環境の住み分けや、安定性のアップなど課題があるため今後も継続的に改善していく予定です。 また、運用を継続してデータも溜まってきているので、BigQueryと連携させて統計データの分析もやってみようと思っています。

まとめ

メンテナンスに課題はあるものの、mablで自動テストが整備できていることによるリグレッションのハードル低下や、QA環境を自動テストが通る状態に保てているメリットは課題を上回るものがあります。今後もよりよい運用を模索しつつ、自動テストを継続していこうと思います。

We're hiring!

QAチームではチームで協力しながら、サービスを届けるまでのリードタイム短縮に貢献したいエンジニアを募集しています。 社会に役立つシステムを高品質で素早く届けたいQAエンジニアの方、一緒に働きませんか? カジュアル面談でより詳しくお話ししましょう!

jobs.m3.com