アペルザ社（以下、アペルザ）は製造業やメーカー向けのECやCRMをSaaS型で提供するスタートアップです。製造業に特化したメーカー・商社向けの販促・営業活動支援クラウドサービス「アペルザクラウド」や、製造業のエンジニアが活用する製品のカタログサイト「アペルザカタログ」、生産財通販サイト「アペルザeコマース」など、様々なサービスを積極的に開発しています。
最近は、AIとOCR機能を駆使してFax画像をデータ変換する「アペルザクラウド WebFAX」を開発中です。こちらはモダンなUIとテクノロジーになっており、E2Eテストによるリグレッションテストの重要性が高まっています。
アペルザのプロダクトは毎日使われる業務アプリです。つまり、サービスが止まると業務が止まってしまうため、高いレベルのサービス品質が求められます。さらに、毎日使われるため、サービスのUI/UXに「手触りの良さ」が求められます。
アペルザは、これまでもE2Eテストに積極的に投資していました。マークダウン形式でE2Eテストを作れるオープンソースフレームワークGaugeの利用は長く、現在も一部のテストで活用されています。しかし、メンテナンスコストの増加など、一般的なテストフレームワークの問題に直面していました。
詳細は「QAをチームではなく、活動に」アペルザのQAへの取り組み」を参考
これらの問題を解決するために、3年間もの間、試行錯誤を続け、現在はmablを中心としたE2Eテストを運用されています。
佐々木氏は、mablの導入検証の中心人物であり、mablの利用を開始してから1年少しほどの間、Software Engineer in Test（通称：SET)として、テスト自動化を開発全体に推進し、改善を続けながらアペルザの品質をリードし続けています。
今回は、mablユーザとして多くの経験を持つ佐々木氏に対して、テスト自動化の実運用のプラクティスを伺いました。
佐々木氏が実践するプラクティスは単純なものが多いですが、これまで課題に直面するたびに試行錯誤されてきた実践知です。たとえば、テストケース管理は、スプレッドシートを使ってマニュアル、自動ともに管理しています。
日々の機能テストなど、マニュアルテストはスプレッドシート上に項目や手順が書かれています。自動テストは少し違い、機能の一覧が広く浅く書かれています。さらに、それぞれの項目にプロダクト名、優先度、実行したい環境（STG、本番など）が書かれています。
優先度について詳しく書くと、アペルザのE2Eテストの優先度はSからA、B、Cの4段階になっており、システム障害時の影響度に関連しています。つまり、障害時に影響の大きい機能は「S」といった形になっているため、エンジニア側との共通認識にもつながっています。
E2Eテストを追加するときは以下の観点でチェックします。
もしこのチェックがなれば、どんどん機能がリリースされるたびに、どんどんE2Eテストも増えていってしまいます。アペルザではある程度の量のリグレッションテストを自動化していますが、それをメンテナンスできる量にも限りがあるため、こういった判断を行い、よりスコープを絞ってリグレッションテスト、E2Eテストを活用しようとしているのです。
前述の通り、アペルザにはすでに自動化されたE2Eテストがありました。これらの資産を活かしながら、どのように mabl に移行していったのでしょうか？
まずは、E2Eテストでカバーできていなかった主に新しい機能から mabl でテストを作成していきました。そして、それが一段落すると、修正が発生した既存の自動テストからmablに置き返って行きました。
一気に置き換えるのではなく、ちょっとずつこつこつと mabl へのマイグレーションを進めました。現在はリグレッションテストとして計画している自動E2Eテストのカバレッジは90％を超え、mablへのマイグレーションも70％近く完了しています。
カバレッジについては、優先度Sのテストは100％にしたいと考えていますが、
から、重点的なプロダクトやサービスのテストだけを自動化していく形になりつつあります。
佐々木氏が定義した優先度をもとに、Plan（テストをたばね、定期実行する設定のこと。テストスイートに近い考え方）が作成されています。
優先度Sプランには、優先度がSのテストだけが入っており、Aなら優先度Aのテストだけが入っています。優先度だけで区別しているため、E2Eテストを新しく作る人がいれば、どこに何を追加すればいいか簡単にわかる設計です。
実行は、Sは毎日、ABCは週に1回、日中や夜間に実行しています。リリース前などはSTGデプロイのタイミングでテスト実行しています。
大切なテストであれば、日中エンジニアが作業しているときにテスト実行し、問題があればすぐに通知するのがポイントです。アペルザではSlackによるコミュニケーションが活発ですが、E2Eテストの通知も、開発関係者の目にとまるSlackチャンネルに通知することで、品質への取り組みが徐々に浸透していき、だんだんとコメントをくれるメンバーも増えてきています。
1年以上、mabl の運用を実践し続けてきた佐々木氏に mabl の価値について教えていただきました。
テストだけでなくテスト環境を含めて考えると、70％ぐらい運用コストは削減できているのではないかと感じます。 ーー アペルザ佐々木氏
ひとつめは、テスト実行環境のコストが削減できる点だと言います。mabl はSaaS型のサービスなので、はじめから様々な機能がそろっています。わかりやすいテスト結果レポート画面、SlackやCI/CDへのインテグレーション、クロスブラウザ環境、JSやネットワークエラーの検知・・・といった様々なイニシャルコストがゼロになる点は大きいはずです。
Gaugeは社内にあるPCで動かしていたりもしますが、mabl は完全にクラウド上で実行可能です。テストはローカルでも簡単に動作確認でき、最近だとデスクトップアプリのリリースによって、より高速にローカルテスト実行できるようになりました。
E2Eテストは動かし続けるのが大切です。止まるとそこからまた動かすのに大きな労力がかかります。継続的に改善し、継続的にテスト実行するのが大切だと感じています。 ーー アペルザ佐々木氏
もうひとつは、テストコードのメンテナンスが下がった点です。自動テストのコードを書くのは楽しいけれど、時間が経ち、コード量が増えるとそのメンテナンスコストも増加していきます。
mabl の直感的なUIや、Flowとよばれる共通部品、AIによるテストの自己修復によって、キャプチャ＆リプレイ型のテスト自動化ツールの弱点はだんだん解消されてきました。その結果、E2Eテストのメンテナンスコストも下がってきました。
やはり忙しいときはエラー通知を放置してしまうこともあるようですが、簡単に修正対応できることが、心理的な辛さを軽減してくれていると言います。
現在は、佐々木氏を中心に、さまざまなメンバーが品質活動に参加しています。
アペルザには佐々木氏の他に、スクラムプロセス全体をリードするQAエンジニアが1名いて、スクラムサイクルを回す活動と、エンジニアリングで生産性と品質を高めていく活動を、連携しながら進めているのはとても興味深い点です。
自動テストによって、リリース前の不安が、安心に変わったのは大きいと佐々木氏は言います。その余裕を活用し、現在は、単体テストやAPIテストなどよりプログラム内部の品質向上に取り組み、品質活動を「開発チーム全体の活動にする」ゴールを目指しています。
