概要
🎅🎅🎅🎅🎅🎅 メリークリスマス！ 🎅🎅🎅🎅🎅🎅
本稿は、自動E2E自動テストサービス（以降、単にテストサービス）について、実際にトライアルしてみた結果の振り返り記事です。テストサービス初心者なので、見当違いな内容が含まれているかもしれません。気軽な読み物として楽しんでいただけたらと思います。
本稿で取り扱うサービスは Autify, MagicPod, mabl, BugBug の４つです。また、付録に「サービス選定をする前に知っておくべきこと」をつけました。 そちらも併せてお楽しみください。
サクッと紹介: 今回テスト対象となった SALESCORE について
会社の営業さんが商談の状況などを入力するとダッシュボードが作られ、「目標を達成するには今月末までにあと N 件〇〇しましょう！」といった売上につながる示唆が得られるサービスです。
シンプルに見えますが、 DOM 構造は結構複雑です。 テストサービスの導入を考えている企業は、きっと SALESCORE と同じくらい複雑なWebサービスを運営されていると思っています。
前置きはこれくらいにして、それでは本編をどうぞ！
各社比較
Autify
検討したプラン: Autify Standard
さすが大手だけあって、使い心地は良かったです。チャットでのサポートもかなり受けやすく、即日返信が来ることも多かったです。ただ、値段が高くて見送りました。今回イチオシの BugBug Pro と比べると約９倍の価格でした。（いまググったらIT導入補助金2023の対象らしく、最大半額まで補助金が出るらしいですが、元々が高いです。）
あと、 DOM の自動選択の精度が SALESCORE についてはいまひとつでした。
Autify Standard は年間 30 万ステップまでテスト実行可能です。これは一日一回テストプランを実行すると半年で使い切る数です。以下に試算方法を示します。
| 項目 | 数 | 備考 |
|---|---|---|
| テストの平均ステップ数 | 40個 | ログインやチェックしたい機能の実行・検証を入れたらこれくらい |
| テストプランに紐づけるテストの数 | 40個 | BugBug の CEO 曰く、このくらいの数が管理しやすくてお勧めらしい |
| テストプランの実行回数 | 1回/日 | |
| １年間にテストを実行できる日数 | 187.5日（300,000/40/40） | 半年 |
これからわかる通り、ステップの追加購入が必要です。 「CI/CD ツールと連携してたくさん回せますよ」というテストサービスも多いですが、計算したらステップ数足りないことに気づくことも同じくらい多いです。 どうせステップ数で制限がかけられているので、テストサービスは日次実行さえできれば良いのでは、とさえ思っています。
MagicPod
検討したプラン: ブラウザテストプラン・スタンダード
Autify と BugBug は Chrome のシークレットモードで、 mabl はネイティブアプリでテストを作成するツールですが、 MagicPod は違います。 MagicPod でテスト作成をするときはリモートの VM を立ち上げ、その GUI をブラウザの iframe に映して操作します。 そのため、テストしたい自社のウェブアプリがブラウザの中に小さく表示されます。超独特です。
SALESCORE は中量級くらいの Web アプリですが、MagicPod でテストを作ろうとすると重すぎて途中で止まってしまうことがありました。テスト作成の UX が良くなかったため、今回は見送りました。
mabl
検討したプラン: STARTUP
ネイティブアプリをインストールしてテストの作成、実行をします。デザインが優れていて、使っていて安心感がありました。また、2024年１Qから 1000 台のブラウザでWebサイトの負荷テストを実施できるようになるとのことで、パフォーマンス測定ができる数少ないテストサービスです。
今回 mabl の導入も見送りましたが、一番の理由は全体的に Autify の方が SALESCORE に適していたからです。
BugBug
検討したプラン: BugBug Pro
今回のイチオシは BugBug です！🎉
BugBug はポーランド🇵🇱が産んだ “Automation testing made ultra-simple” をスローガンとするテストサービスです。めっちゃシンプルで使いやすく、テスト業界では破格の年間契約で $1,188、月極契約で $119 です！ テストでどんな効果が得られるか不明瞭な段階で、スモールスタートが切れるのがとても良いです。ローカルでもクラウドでもテストを実行でき、実行可能回数は無制限です。百聞はトライアルに如かずなので、ぜひ一度ご自身で試してみてください。ちなみに、一番イイ感じにSALESCORE の DOM を選択してくれるサービスでもありました。
ローカルテストだけでよければ Free プランもあります！
まとめ、あるいはサービスの選び方
今回、４つのテストサービスをトライアルして比較しました。その結果、必ずしも有名な製品が自社にとって最適ではないことがわかりました。
サービス選定係の僕たちは、有限の時間を使って自社にとって最適な製品を探す必要があります。 多くの場合、インターネット検索によって候補を３つの製品に絞り込み、トライアルをしたりデモを申し込んだりします。大きな企業は、大金を叩いてその三本指の中に入り込めるように広告を打っています。本来は製品のもつ性質によってサービスを選ぶべきですが、お金の力でそのプロセスが歪められてしまっています。
今回、 SALESCORE に最適なテストサービスとして BugBug を選びましたが、これは他の３製品と比べて無名で広告もみたことがありません。しかしながら、他のどの製品よりも圧倒的に SALESCORE に合っている製品でした。有名なものと同じ数の無名な製品のトライアルに申し込み、実際に触ってみることで、効率的に自社にピッタリなサービスに巡り会えるのではないかと思います。
付録、サービス選定をする前に知っておくべきこと
ノーコードは幻想です
ノーコードでテスト作成は幻想です。
ノーコードでテスト作成は幻想です。
大事なことなので2回言いました。
だいたいのサービスが「コーディング不要で、プログラマじゃなくてもテストが作れる！」と標榜していますが、ここはテック業界です。宣伝文句を真に受けてはいけません。
確かに、テストサービスを使ってブラウザをポチポチしていたらテストは作れます。しかし生成されたテストを見てみると全然違うところにあるフィールドを指定していたり、あるいは、もっと深い DOM 階層の文字列をとりたかったのにその上の div 要素をとってしまっていたりします。しかも、テストを１つにつき２,３個そのような誤ったステップがあります。
この場合、きちんと意図通りの DOM を指定し直さなくてはいけません。ブラウザでマウスをポチポチするだけでは不可能です。Developer Tools を使って DOM ツリーを読んで、適切なセレクタを考えなくてはいけません。普段コーディングしていない人には難しいと思います。
優れたサービスを使えば、コーディングの量を減らすことができます。これはプログラマにとっても素晴らしいことです。しかしながら、結局のところコーディングからは逃れられません。逃げても良いですが、意義のあるテストができる場合はかなり限られるでしょう。
XPath について勉強しよう
もしあなたが僕のように（幸運にも）テストサービス選定係になった場合には、１つ目のサービスを試しながら XPath について勉強するのを強くお勧めします。 XPath は多くのテストサービスで使われている DOM の指定方法です。 CSS セレクタみたいなのですが、 CSS セレクタとは違い、現在選択されている要素の上・下・横の要素を選択することができます。正しいテストを書く近道です。BugBugの記事がわかりやすいです。エンジニアなら１時間もあれば学習できるでしょう。
前節で強調した通りどのようなテストサービスを使うのであれ、ノーコードで意味のある正しいテストを完成させるのはほぼ不可能で、現実的には XPath を書く必要があります。テストサービスを比較する時にはぜひ XPath が書ける状態で比較しましょう。
くれぐれもノーコードでテストが書けたという理由でサービスを選んではいけません。なぜならそのサービスの DOM セレクタのアルゴリズムが変わったり、今後もっと複雑な UI をテストすることになった場合に、結局コーディングが必要になるからです。テストサービスはコーディング前提で評価しましょう。
デモを受けるよりまず触ろう
それぞれのテストサービスのウェブサイトに行ったら「デモ申し込み」ボタンを押す前に「トライアル申し込み」ボタンを押しましょう。百聞はトライアルに如かず 、結局自分がこれからテストを作って管理していくので、それをまずやってみるのが一番早いです。「デモ申し込み」ボタンを押すのは自分でテストを作ってからにしましょう。その経験をもとに質問タイムにするのが自分にとっても相手にとっても一番効率的な時間の使い方です。
以上、ここまでお読みいただきありがとうございました。良いお年を！
Discussion