Autifyをより活用するためのポイント
こんにちは。Tably よういちろう です。新しい M.2 SSD を買いました。今から自作PCに搭載するのが楽しみです。
さて、Tablyでは、主にオンラインイベントにて登壇者と参加者とのインタラクションを効率よく行うために、Tably Moderator (以下 Moderator)というウェブサービスを開発して運用しています。
Tablyメンバー自身が登壇するイベントにてModeratorを利用する機会が多かったですが、今ではTably以外の方々にも利用していただく機会も増えてきました。例えば、6月に行われた GDG Tokyo 主催の「I/O Extended Japan 2021 - Assistant + IoT」では、質疑応答に Moderator をご利用いただきました。それ以外にも、数千人が参加した社内研修にてリアルタイムにアンケートを実施したり同時に多くの質問を受け付けて「いいね」が数百個一気に付くなど、大活躍しているウェブサービスです。
さて、そんな Moderator は、機能拡張や改善が日々行われています。高頻度でコードを変更しているような開発プロジェクトでは、通称「デグレ」と呼ばれている「今まで動いていたのに動かなくなった」という事象が度々発生します。手を入れた場所とは直接関係していなさそうな別の機能が動かなくなってしまうと、それに気が付かずにリリースをしてしまい、結果として事故を招く、といった可能性も高まり、とても危険です。
デグレードしてしまったことにできるだけ早く気が付いて事故を未然に防ぐための手段として、リグレッションテストが非常に有効です。リグレッションテストとは、デグレードしてしまった（リグレッション = 回帰してしまった）状態かどうかを確認するためのテストのことを言います。つまり、あるコードを修正した際に、他の機能群に何ら影響が発生していないことを確認するために、一通りの機能を動作確認してみること、です。
「うわ、全機能をテストするの？そりゃ大変だ」と思うかもしれません。もちろん、手作業でリグレッションテストを行うとなると、機能が増えれば増えるほど、実施は非現実的です。しかし、リグレッションテストを自動化して人間がやらなくても済む状態になってくれていれば・・・とても安心ですね。デグレードを恐れることなく、自信を持ってコードに手を入れることができます。
Moderator では、リグレッションテストの自動化を「Autify」というウェブサービスを利用して実現しています。Autify がどういったものかは、以下の一文を読んでいただければ把握していただけると思います。
「ブラウザ操作を記録するだけでテストがノーコードで誰にでも簡単に作れます」
Autify を使いはじめて数ヶ月が経ちましたが、Autify を効果的に利用するためのコツがあることがわかりました。そのポイントを知っているかどうかで、Autify を活用し続けることができるかどうかが変わってきそうです。このエントリでは、Autify を活用するために最も大事なポイントを使用した経験からお伝えしたいと思います。
そのポイントとは、「シナリオをできるだけ小さく作る」です。
大きなシナリオを作ることはとても簡単
Moderator に Autify を導入して最初に作ったシナリオの総ステップ数は、150ステップを超えるものでした。
これは、Moderator を使って登壇者と参加者が「イベントの中でこれは絶対にやるだろう」という「Happy Path = 一通りの正常系フロー」をシナリオにしたものです。このシナリオさえ毎回通っていればほぼ安心だ、というようなものです。
シナリオを構成する個々の要素は、「○○ボタンをクリックした」「○○と入力した」「○○と表示されていることを確認」といった、操作と確認の羅列です。これが150個以上並んでいるシナリオを作った、ということになります。
Autify でシナリオを作る作業は、本当に簡単です。「ただ操作をしていれば良い」だけです。手順が面白いように記録されていき、最後まで操作したあとの達成感は、半端ないです。「作ってやったぜ！」という気分になりますし、記録されたシナリオをリプレイして最初から最後まで通してみたときは、本当に爽快感があります。
多数の操作手順から修正箇所を探すことの苦痛
その後、Moderator に対して何か機能修正をしたとします。例えば、ページ内に出力する文字列を一部変えたとしましょう。さて、その文字列は、テストシナリオのどこで確認していたでしょうか？
そうですね、150個以上の並びから記憶を頼りに探すことになります。しかも、テストシナリオは、「○○ボタンをクリックした」「○○と入力した」「○○と表示されていることを確認」といった、かなり細かいものの集合ですので、ぱっと見ではまずわかりません。そのため、対象の手順を探し出すためには「確かテストシナリオの終盤だったかな？」という記憶を頼りに探すことになります。
もしかしたら、テストシナリオの中で1回だけでなく複数回確認している可能性があります。そう、手順を全部見ていく必要があるでしょう。
想像しただけでも心が折れそうですし、そのシナリオを改善していくことを放棄したくなるはずです。残念ながら、僕はそのテストシナリオをそれ以降見たくなくなりました。
再レコーディングのコストが半端ない
表示文字列の確認だけであれば、まだ良いかもしれません。他にも、「ある機能を呼び出すための操作（画面構成やクリック対象のUIなど）が変わった」という仕様変更が起きたとします。手順自体が変化したので、Autifyでは「再レコーディング」が必要となります。
この再レコーディング、実は「シナリオの自動リプレイ」では再レコーディングしたことにならず、自分で操作をし直していくことではじめて「再レコーディング」したことになります。長大なシナリオの中の一部分を操作し直す、これはかなり難易度の高い作業になりますし、とても気を使う作業です。
また、画面の構成が変わったりしていた場合には、Autify が AI にて追跡を頑張ってくれるとは言え、完全ではありません。そのため、150ステップあるうちの30ステップ目から再レコーディングをしないと行けない場合は、修正対象から以降の手順の全部を含めた120ステップ分の再操作が必要になってしまうと考えたほうが正解です。
すでにある長いテストシナリオをもう一度操作し直さないとならない、その現実を目の前にした瞬間に、やはりそのシナリオを窓から投げ捨ててしまいたくなることでしょう。僕はなりました。
捨てても良いステップ数にしておく
このような事態を避けるために、テストシナリオを作る際に気をつけたいポイントがあります。それは、
「どんなに多くなったとしても、50ステップ以内になるようにテストシナリオを作成する」
ということです。テストシナリオは、小さければ小さいほど良いです。
感覚的には「あるテストシナリオを捨てて再度作り直しても、さして苦労を感じない程度のステップ数」に抑えておくと良いかと思います。50ステップでも多いかと思いますが、とにかく一つのシナリオは「ある機能の動作確認が可能な最低限の手順数」に限定することが大事です。
このポイントに照らし合わせると、僕が最初に作った、
「Moderator を使って登壇者と参加者が “イベントの中でこれは絶対にやるだろう” という “Happy Path = 一通りの正常系フロー” をシナリオにしたもの」
という方針は、完全に間違いでした。テストシナリオの単位を間違えています。もっともっと細かくしておかないといけません。
ある一つの機能のテストしなりを考えた場合に、何か条件が違えば、その条件ごとに別のシナリオにする、というくらい徹底してシナリオを細かくしていくことが良さそうです。
テストシナリオを細かくするメリット
Autify を使う上で最も大事な「テストシナリオの作成単位」に気づいてからは、Autify を使ってプロダクトの品質を落とさないことが「楽しく」感じられるようになりました。それは、テストシナリオを細かく作っていくことで、以下のメリットを得られるようになったからです。
(1) プロダクトが何か変化したときに、テストシナリオを新規に作ることが「楽しく」なった。それは、目の前にある変化した箇所「だけ」を対象にテストシナリオを作れば良い、という気軽さが生まれたから。
(2) プロダクトが何か変化したときに、テストシナリオを修正することが「簡単」になった。関係するテストシナリオ（失敗し始めたテストシナリオ）を作り変えることが手軽になり怖くなくなったから。
(3) プロダクトが何か変化したときに、どこに影響が出たのか、細かく知ることができるようになった。大きなテストシナリオでは、失敗した手順から先の残りの手順は実行されないため、影響が出たかどうかは大きなテストシナリオを何度も実行しないとわからない。
最初に感じていた Autify への印象は、180度変わりました。
まとめ
最初からテストシナリオの最適な作成単位を知っていれば良かったのですが、これも勉強です。いろいろ試す中で、Autify に詳しくなり、よりお気に入りのプロダクトになりました。
ただし、テストシナリオを細かく作っていくことは、実は「テストの実行回数が増える」ことを意味しています。つまり、課金額は残念ながら増えます。テストの細分化の粒度と実行回数はトレードオフの関係になるので、この点には注意が必要です。これに関しては、将来的には課金体系もより柔軟なものになっていくのではないかと期待しています。
もし Autify をこれから使いたいと思っている方には、ぜひテストシナリオを細かく作っていきながら、Autify を活用していただきたいと思います。また、もし既に Autify を使っていて、なかなかメンテナンスが難しいな、という印象をお持ちの方は、テストシナリオの長さについて再考してみてください。何か気づきがあるかもしれません。
このエントリの内容が Autify をお使いの方々の参考になれば幸いです。