ROBOT PAYMENT Engineers Blog

株式会社ROBOT PAYMENTのテックブログです

E2E自動テストサービスAutifyを導入しました

 

はじめに

こんにちは。

請求管理ロボPMの田本(@tamotamo97)です。

今回はE2E自動テストサービスのAutifyを導入するに至った経緯と導入してからどうなったかを書いていこうと思います。

品質向上(ここでいう品質は主にシステム不具合)に関しての施策はどの会社でも色々な施策を実施されていると思います。

1ケースとしてご参考になれば幸いです。

Autify導入前の状況と課題

Webサービスに限らずシステムを運用していくに当たり、不具合はつきものです。

不具合にも色々ありますが、その中でも既存機能の不具合は新規機能よりも既存ユーザーに大きな影響があるため、リグレッションテスト設計にはより多くのコストを投入していくことが定石です。

 

システムを長く運用していくと機能自体の増加、改修による影響範囲は大きくなり、コストは肥大化していきます。

時間とコストは無限ではないので、会社、サービスのフェーズに応じてQCDのバランスを取りながら開発を進めていく必要があります。 

 

コストを抑えながらできるだけ品質のいいものを作ろうと考えると、よく話に上がるのがテストの自動化です。

弊社は運用フェーズでもテスト自動化に取り組みやすいUserInterfaceTest(EndToEnd)を優先的に取り組んでいきました。

初期(2016年頃〜2018年頃)

ノーコードで簡単に始められるSeleniumIDEで書いていきました。

画面を録画しながら作成できるので簡単に作れるのが特徴です。

f:id:tamoryo:20200907124610p:plain

seleniumide

ファイルを保存して、毎回リリース後に手動で実行、をリリース手順書に組み込んで実施していました。 

作成自体は簡単でしたが、毎回原因不明のテスト失敗が多くあり、手動でそれらの原因を確認して再実行するのにかなりの時間を使っていました。

もう一回実行したらなぜか通るというテストも多かったです。。

 

そしてあるあるだと思いますが、毎回の実行とメンテナンスにかなり工数がかかり、機能拡張が優先になると形骸化され運用されなくなっていきました。。

中期(2019年〜2020年)

システム全体に影響があるPHPVersionUPの改修時に、全網羅テストをする必要があり、自動テストを復活することにしました。

SeleniumIDEで辛い思いをしていたので違うものを・・ということでSelenium本体を導入。

f:id:tamoryo:20200907124752p:plain

seleniumgithub

ゆくゆくはCIに組み込んでいきたいと考えていたのでコードで書いていけるものを選択しました。

 

ただここでも同じように原因不明のテスト失敗が多くあり、またそれぞれのブラウザごとに環境を構築するのに時間がかかる(環境ごとに書き方を工夫しないといけない)、仕様変更時のテストコードの改修に時間がかかる、エンジニアのリソースを使う等の課題がありました。

 

PHPVersionUPが完了した段階で一時中断。何かいい方法がないかと模索しておりました。

(Selenium力が高い方はうまく回避されていると思いますが当時チームにSeleniumについてのナレッジがそこまでありませんでした)

現在(2020年〜)

模索中にこんな記事を見つけてすぐ連絡。 jp.techcrunch.com

2019年10月から導入検討、2020年2月に導入、今に至ります。

Autify導入時のススメ方

まずサービスの品質に対してどれくらいのコストを払っていくかを決める必要があります。

今回はすでに発生しているコストをどう最適化していくかという話だったので、導入するかしないかという話で議論になることはありませんでした。

議論になったところが、誰が進めていくか、です。

 

大きな規模の会社では開発部隊のQAが進めていくことがほとんどだと思いますが、導入当時弊社にはQA部隊がなかったためここの調整に時間がかかりました。

E2Eテストを書いていくにあたり技術的な領域が多く、今までエンジニアが書いていましたが、AutifyではGUIで書けることと、そもそもユーザーシナリオはユーザーの利用ケースや業務理解があるCSが主体となって書いていくのが望ましいのではと一旦事業部全体にエスカレーションして議論となりました。

結果、CSの山下が作成、PMの田本がレビューといった形で進めることになりました。 

 

通常時の業務でどの部署も忙しいと思いますが、品質部分にコミットして変革していくことを全部署でコンセンサスを取りながら進めていくことが重要だと感じています。

導入、運用時の工夫

新しく何かを導入する時はできるだけ小さく始めることが失敗した時のダメージも少ないです。

最初から全てのテストケースをカバーすることはスタートまでにかなりの時間を要しますし、できるだけ小さく、業務の基本パターンの正常系のリグレッションテストのみに絞って書き始めました。

書き方の工夫については次回CSの山下の記事で紹介があると思います。

 

Autify導入後の現状

弊社は週に1回定期リリースを行っており、正常系リグレッションテストをリリース後とリリース翌日にスケジューリングして自動実行しています。

自動実行しているので今までのように実行自体を気にしないといけないことはなくなりました。

テスト結果は自動でSlackにOK/NGの通知を受け取れるようになりました。

f:id:tamoryo:20200907125445p:plain

autifyslack

画面の改修があってもAIで自動的に認知してくれるので、今のところ、大きくシナリオの修正をしないといけないといったこともないです。

 

また、原因不明のエラーの発生がほぼなく安定してテストを回せています。

本番で不具合が発生したときは都度エラーになったケースをAutifyに追加し、一度起きたエラーは今後起きない(起きてもすぐ検知して対応できる)体制を作ることができました。

f:id:tamoryo:20200907130404p:plain

autify画面

 

今後について

カバーできていないシナリオテストをどんどん追加していくとともに、本番リリース後のテストのみではなく、開発フローにも組み込んでいきたいと考えています。

AutifyのAPIを利用してCIに組み込んでいく計画もしています。

f:id:tamoryo:20200907125305p:plain



さいごに

Autifyを導入してエンジニア以外の方でもGUIで簡単にE2Eのテストを作成できるようになったこと、運用保守コストが削減され、結果安心して新規開発にリソースをかけれるようになったことに素晴らしい効果を感じています。

また、Autifyのサポートの方のご対応が即レス丁寧ですばらしくこの点もAutifyをおすすめしたい点です。

 

実際にどのようにテストを書いていったか、AutifyでJSを使っての細かい部分のテストの書き方等は導入時にテストを書いてくれたCSの山下が続編ということでブログを書いてくれる予定ですので、お楽しみにどうぞ。

最後までお読みいただきありがとうございました。