コスト最適化のために Autify の運用方針を整理しました

RevComm で Software Engineer をやっております、佐藤と申します。
現時点で弊社には4名の佐藤が在籍していますが、今のところ全員の所属部門が大きく違うため、苗字で呼ばれてもあまり困らない日々を過ごしております。

今回は弊社で利用している E2E テストツールの Autify についてのお話です。実際の運用について少しだけ踏み込んだ話になりますので、Autify についての紹介・説明は省いている場合があります。Autify を利用している・利用を検討している方に読んでいただけたら嬉しいです。

最初の実行回数オーバーが契機に

ある月の半ばに「このままいくと Autify の実行回数が当初購入分を超えるかも？」という状況が発生しました。これは弊社の製品 MiiTel の E2E テストツールとして Autify を導入してから初めてのことです。

その時点で、完成形のシナリオ数と現在回している定期実行のペースを元に月当たりの実行ペースを算出したところ、今のプランでは明らかに実行回数が足りないことが判明しました。
そこで Autify の利用方針を定めて最適な実行回数を見積もり、それを持って Autify 社と実行回数を増やす相談をしよう、ということになりました。

導入初期を思い出すと、実行回数は今のプランで足りるのか？ということを検討できるくらいシナリオが出揃った事はかなり感慨深いものがあります。

必要な消費回数の見積もり

MiiTel にはさまざまなマイクロサービス(以下サービス)が存在し、それぞれの実装を行うチームが Autify のシナリオ実装も行っています。また、SLA や障害時のリスクといった必要な実行回数の根拠となる考え方も、サービスによって異なります。

一方、Autify の実行回数は会社単位の数字です。何の制限もなく使っていった結果、あちらのチームが使いすぎて別のチームが困った...という事態は防ぎたいところです。

最終的には、以下のような体系で指針を示し、それに沿って各チームが見積もった数字を合算して全体の消費回数見積とすることにしました。

製品をテストするための実行
- 自サービスリリース時の実行
  - リリース前にステージング環境で実行
  - リリース後にプロダクション環境で実行
- 他サービスの変更に影響を受けるシナリオの実行
  - MiiTel 以外のサービスに影響を受けるシナリオの実行
  - MiiTel の他サービスの変更に影響を受けるシナリオの実行
それ以外の実行
- シナリオ実装時の実行
- シナリオメンテナンス時の実行

製品をテストするための実行

数字を見積もる上では、シナリオ実行を「製品をテストするための実行」と「それ以外の実行」に分ける必要があります。「製品をテストするための実行」はMiiTel の E2E テストとして実行することです。普通に考えたらここについてだけ数字を考えれば良さそうな気がしてしまいます。

一方、「それ以外の実行」とは、シナリオを作成する際に試しに回す実行や、Autify の運用中にテストがコケてしまいメンテナンスする時の実行などです。ここを極力減らす方法も考えがちですが、人間が手を動かす時間を削減したくて導入した Autify の実行回数を減らすために人手を割くようになると本末転倒ですから、大まかにでもこの数字を見積もっておく必要があります。

自サービスリリース時の実行

自分のチームが担当するサービスに対するテストは、リリース時だけ行えば良さそうです。リリース前に不具合をキャッチできるよう、ステージング環境で網羅的な回帰テストを実行。また、プロダクションでも同じ内容でもう一度実行します。同じテストを二度実施するのは、環境差異が動作に影響する可能性を潰したい、お客様に使っていただいている環境でテストが終わっていれば安心という理由です。

つまり、シナリオ数の見積もりは以下のようになります。

フルテストのシナリオ数 × 月当たりのリリース回数 × 2

他サービスの変更に影響を受けるシナリオの実行

MiiTel のサービスの中には、リリース時に他のサービスの変更に影響を与えてしまうものがあります。他のチームのサービスのテストを行うことを考える場合、それに伴うリスクやコストも考える必要があります。そこで、MiiTel 内の他サービス・他社のサービスに変更があった際に影響を受ける箇所のテストを毎日定期実行で回す方針にしました。リリースを行う（影響を与える）側のチームではなく、影響を受ける側がテストについて責任を持てる形になります。

シナリオ数の見積もりは以下のようになります。

影響を受けるテストのシナリオ数 × 31

また、MiiTel 内のサービスであればリリースが行われる可能性が低い曜日が決まっていますから、MiiTel 内の他サービスに影響を受けるテストの場合は以下のようになります。

影響を受けるテストのシナリオ数 × 20

それ以外の実行

すでに説明した、製品をテストするための実行以外のテストです。こちらは実績から見積もるしかありません。現時点ではそういった画面は用意されていないため、テスト結果検索画面で YYYY-MM（対象の年月）を検索してその月を検索して件数を確認しました。今回調べたところでは、全体の実行回数に対し約30%が「それ以外の実行」によるものでした。

シナリオ作成作業のボリュームは作成済みのシナリオ数には関係がないため厳密ではありませんが、いったんこの方法でとりあえずの最大値は決めることにしました。