CROOZ TECH BLOG

~読んだらわかるSHOPLISTの裏側~

CROOZ TECH BLOGとはクルーズ株式会社の開発チームが技術について共有するブログです
開発の中での発見や知識を広めてオモシロカッコイイ〇〇をツクリます。

【デバッグ効率化②】デバッグにかかっていた2,500時間を削減する話【Autifyを使ってみた結果】

こんにちは。クルーズ株式会社、社長特命執行部執行責任者の松島です。

社長特命執行部ってなんでも屋なのでなんでもするんです。仕事の範囲はボーダレス。

今回自分からは当社が運営しているファッションECサイト『SHOPLIST.com by CROOZ』にて自分がオーナーとして取り組ませてもらっているプロジェクト、「本当に必要な実装の時間を確保するために、無駄なデバッグ時間を削減」の話の第2回目をお話ししていきたいと思います。

◆結論、Autifyだけでは開発+運用には耐えられなかった

補足しますが、Autifyだけで開発+運用に耐えられなかったのはSHOPLISTの開発方式や開発手法等諸々の影響によるところが大きいと考えていますので、Autifyがサービスとしてどうこうという話は全く別物となります(自分個人としては非常に優秀なツールだと思っています)。

 

なのに何故Autifyだけでは開発+運用には耐えられなかったのかは後述します。

 

なお、この記事においては2021年10月時点でのAutify社の仕様を前提とした話となっています。Autify自体が非エンジニアでも使えるツールであるため、非エンジニアの方も小難しい話がでてきたな?と思わず、見て頂ければ幸いです

◆Autify導入の経緯

導入の理由ですが、自分が2021年10月時点で各種UI自動テストツールを見て回った中で一番シンプルでかつ必要な汎用性を保持していたためというシンプルなものです。

 

このデバッグ時間の削減の話が出てきた際に会社としては元々全環境を1つのツールでテストを実施できたほうが楽だろうという事で某クライアント型ツールを導入しようとしていて、実際に検証もすすめていました(弊社CTOの鈴木が進めていました)。

 

ですが、某クライアント型ツールは自分が研修に参加した事で非エンジニアには習得が不可能と判断、最終的にはAutifyの導入に切り替えました。

 

単純に会社としては

・「GUI

・「昔から長く使われていて」

・「全プラットフォーム対応可能」

というツールスペックから非エンジニアでも使えるだろうと導入を進めていたのですが、

 

実際には

・「ツール固有仕様が多い」

・「エンジニア経験が無ければツールとしてのパフォーマンスが発揮できない」

という部分が強すぎたため、某クライアント型ツールは非エンジニアには使えないと判断。

 

当時10数個のツールを検証した結果、Autifyが目的と合致したため導入したというのが経緯になります。

◆Autifyと某クライアント型ツールの比較

松島個人の解釈が多く含まれますが、以下のような差があります

 

◆Autify

〇自分は1日でシナリオ作成から簡単なテストの定期実行までできた

GUIChrome拡張機能を使う必要があるが利用が簡単

〇専門用語が少ないというかメインとなるUIがそもそも少ない

×ヘッドレスブラウザで動作するのを前提としているためリプレイが無い

 ※これはシナリオ作成のところで疑似リプレイみたいな使い方ができる

×ツール自体は非常に簡単だが管理側の整備が追い付いてない為、

 運用ルールを敷くことが超大事

 ※シナリオ管理周りがかなり粗いため、

  大規模サービスであれやこれやと大量のテストボリュームがあることを

  実施するには向かない

 

◆某クライアント型テストツール

×レクチャーに参加したが1日ではテストシナリオを完成させることができず

 定期実行のやり方等は全く分からないという状態だった

GUIはクライアントの専用ツールで使いこなせば細かい厳密な対応ができる

×専門用語が多すぎる、操作UIも複雑

〇リプレイは何回でもリプレイ機能の利用が可能

〇このツール専門の職人のような領域になるとDB連携したりかなり高機能

〇大規模サービスであまり変更が定常的にかからない事を実施するのに向いている

 ※シナリオ作成コストが高い為この判断

厳密にできたり、使いこなすことでパフォーマンスが高いのはあくまで某クライアント型テストツールだと思いましたが、今回は会社の方針も非エンジニアが扱えるという事からAutifyを選択しました。

エンジニアチームで昨日の全ても使い倒して扱っていくツールを選定するという前提で判断するという話だった場合はまた別の選択をしたかもしれません。

◆Autifyだけでは開発+運用には耐えられなかった理由

ここはAutify社の仕様によるところになりますし、カンファレンスに参加されている方なら一度は聞いたであろう話です。

・Autifyには月の実行回数に応じた課金があった

この課金体系が原因で開発+運用にはとても耐えられないものでした。

 

・デフォルトの月の実行回数は1,000回です(契約にもよる)。

・1,000回だと30日x30シナリオを実行しただけで900回消費してしまう

・シナリオ作成後の自動実行テストを試せるのは100回/月しか残らない

 

さらに

・環境が変わるごとに1回の実行回数を消費してしまう

 ※Chrome,Edge,Safariの3つのブラウザで実行するとシナリオ1つにつき3回かかる

・PCとSPで別のシナリオを使うため環境でさらにシナリオ1つにつき2回かかる

 

上記を整理すると

・1つのシナリオを3つのブラウザで、PC,SPそれぞれで毎日10回実行すると

・3(ブラウザ)x2(PC,SP)x10回x30日=1,800

 

一応この1,000回という実行回数は契約上回数追加が可能なのですが、上記の回数の増加式からすると100回や200回増えたところで焼け石に水です。

エンジニアからすれば、開発中は環境で変更をしたら

・自動で全チェックしたい

・全チェックして問題があったら修正→再度全チェックしたい

というような事が成立するのが理想的です。

 

1日1人エンジニアが開発中に10回ぐらい上記の全チェックをぶん回していた場合

・3(ブラウザ)x2(PC,SP)x10(回)=600回

・600(回)x10(回開発実行)x30(日)=180,000回

上記のように非現実的な数字になりましたね。

シンプルにAutifyだけでは開発運用に耐えられなかったのは、回数制限制約が厳しいという事につきます。

 

おそらく運用している企業では工夫をして扱っていると思うのですが、回数が厳密すぎてその工夫をすることでまた開発の管理コストを圧迫しそうだなという事で、すべてをAutifyでやるのはやめよう!という判断に至りました。

◆次回は…

今回は意図せずAutifyを導入しようとしたけれど解決しなかったよという話をしただけになってしまいました。

 

自分個人としてはAutify自体は非常に優秀なツールだと思っています。

そのため次回はAutifyの有効活用の仕方、活用ポイントについてお話しようと思います。是非、エンジニアの方にも非エンジニアの方にも役立てていただければと思います。