こんにちは、hacomono QA部SETチームのモーリーこと森島です。

SETチームでは現在E2Eテスト自動化に積極的に取り組んでおり、その中でもmablで作成・実行する自動テスト作成を最も活用しております。
hacomonoでどのようにmablを活用しているかイマの状況をお伝えしたいと思います。

mabl運用状況

実行頻度

参考：１月の合計実行数

QA部では主に２週間に１度の定期リリースタイミングに合わせて、リグレッションテストを実施しています。
このリグレッションテストの位置づけは、機能テストが完了したあとリリース前にこれだけはインシデントが起きたら困るという部分に対して全体的に実施している最後の確認です。
リグレッションテストには手動テスト・自動テストがあり、自動テストはmablで実行しています。
自動テストの実行はイマはSETチームが担当しており、手動テストはQA部の各プロダクトチームのQAメンバーが実施しています。

その他に基盤の変更など影響範囲が想定しづらい場合も、簡易かつ全体的にテストを実行できる自動テストを実行して失敗が少なければリリース判断を、失敗数が多ければ失敗傾向から追加で手動テストを実施する範囲を決定したりしています。

mablの具体的な数値

プラン数

４個のプランに分けてクラウド実行しています。

これは複数の目的があり、ひとつは自動テスト実行環境がイマは２つという制約があるため環境ごとに分けて実行して並列実行できるようにするためです。
もうひとつはhacomono内でテスト同士で同時に成立しない設定項目を検証するにあたり実行する口を分けることで間違えて実行しないようにするためです。
さらにテストの種類でも分けており、hacomonoで複雑な設定をしているシナリオテストやすべての機能で画面遷移、新規作成、参照や削除ができることだけのテストなどの違いがあります。

最大の並列実行テスト数はイマは４６です。
mablの魅力のひとつでもある大量の並列実行に強いという点を活かして、テストを作成するときに並列実行できるかどうかを判断してプランに組み込んでいます。
リリースごとに機能が増えているので進行形で自動テストを増やしているため、今後はもっと並列実行数があがるかもしれません。

プランの中でも並列実行と逐次実行の使い分けをしており、イマは画像のような状態です。

hacomonoでの逐次実行の使い所は、先ほど説明した「テスト同士で同時に成立しないhacomonoの設定項目」を検証するためです。
自動テストの実行の流れとして、大部分のテストに当てはまる前提条件かつ相互に影響しない設定を並列実行で実施して先に確認し、このテストにしか当てはまらない設定を逐次実行で分けて後から確認しています。
これによりテスト同士の影響による正しい結果が得られないことを防いでいます。

逐次実行はやはりテスト実行時間が長くなるため、できるだけ並列実行できるように検討していますが
イマはこの逐次実行内の判断が少し曖昧であるため、本当は逐次実行でなくても問題ないテストも含まれている可能性があります。
時々（イマは気分で）逐次実行のテストの中で並列実行できるテストはないかを整理しています。

テスト実行の成功率は87%です。
この数値は普段から意識していないですが、mablのダッシュボードに表示されているので公開します。
87%が高いとは思いませんが、日々テスト実行してたくさんの失敗数に悩まされている我が身としては体感より上の数値だと感じました。
他にmablをご利用の企業様はどれくらいの成功率でしょうか、高い成功率の場合はぜひコツを教えてください。。。

最近の２ヶ月は８７%でした。

昨年末の２ヶ月は８０%でした

フロー数

有効なフロー数は約１８００個です。
これは他社の利用よりも多いのではないかと推測していますが、理由としてテストはすべてフローで構成している背景があります。
すべてフローにすることでテストが操作単位で見えて可読性が高い便利な面もあれば、mablではひとつのフローを再利用する時に選択までにステップ数が多かったり、フローをコピー＆ペーストができない点などフローを利用するのが不便な点もあり、各企業で方針が分かれるのではないかと思います。