こんにちは。アイキューブドシステムズでCLOMOの品質保証（QA）チームメンバーのt-yamadaです。QAチームの中で、特に自動テストをメインに担当しています。
自動テストを担当しているものの、実はあまりプログラマー寄りのエンジニアではありません。そのため、細かい開発知識よりも、テストエンジニアとしてどのように自動化に取り組み、失敗し、どのようにしたらうまくいったのかを紹介しようと思います。
テスト自動化の導入まで – 膨大に増加するテスト工数
CLOMOは次々と新しい機能が増えており、それに合わせてテストの試験項目が増え、必要工数も爆発的に増加しています。
私が入社した2013年からCLOMOに自動テストが導入された2015年までで、試験項目数が4~5倍くらいに増加しており、そのまま運用を続けると試験項目数に対してテスターが足りなくなってしまうのは目に見えていました。
テスト自動化の導入 – Selenium IDE
2015年の秋のことです。
当時、私はテスターでしたが何回も繰り返される同じテストに若干飽き始めていました。 そんなある日、開発チームからQAチームに移籍してきたWさんがテスト自動化を導入するプロジェクトを立ち上げました。
私は特に強い意思はなかったですが「なんだか楽しそうだな」くらいの気持ちで自動化のチームに参加させてもらいました。
こうして、CLOMOのブラウザテスト自動化プロジェクトが始まりました。テスト自動化ツールは、当時もっともポピュラーで非プログラマーでも利用できる Selenium IDE が導入されることになりました。
Selenium IDEはコマンド、対象、値（commanad, target, value）で一つのコマンドを構成します。
手順としては、右上の赤いポッチを押すと記録モードとなり、ブラウザーを操作した内容を記録することができます。あとは、テストケースとして正常に動作するよう手動で記録した内容の一部を修正します。
この手順で当時は非プログラマーだった私でも、テスト自動化を進めていくことができました。
「これは便利だ」と思ったのもつかの間...
Selenium IDEを使った自動テストは、非プログラマーでも自動テストが作れる魔法のツール...ではありませんでした。
当時は、マトリックステストを自動化するのに、共通のステップを設計することなく、一部の入力値が異なるだけのテストケースを Selenium IDE ですべて手作業で記録をしていました。
そのせいもあり、いざ大量のテストケースをSelenium IDEに投入し始めたところ、平均で1時間に4ケースほどしか作成することができませんでした。当時は3人でテストケースを自動化していましたが、3人掛かりで1日あたり約100ケース作るのが関の山でした。
自動テストのテストケースは全部で5,000項目ほどを運用する予定でしたが、このペースではテストケースを作成している間に機能が追加・変更され、追いつくことができませんでした。
また、自動テストに3人を固定でアサインできる状況も長くは続かず、その後自動化メンバーだった2人がプロジェクトから離れてしまいました。自動化プロジェクトのメンバーが私一人になってしまうと、CLOMOの機能追加や変更に伴うテストケースのメンテナンスがあまりにも広範囲で手が回らず、自動化したテストケースは半年でほとんど使うことができなくなってしまいました。
Selenium IDEでの自動化は、非プログラマーでも直感的な操作で自動化できるため導入しやすいという点では良かったものの、以下の点の改善が必要でした。
- テストの実装速度
- テストケースの保守性
- マトリックステストでシナリオを共通化する仕組みを作る、など
保守コストを軽減 – Excelマクロの導入
自動テスト導入プロジェクトが私一人となり、2017年の春からSelenium IDE運用時の課題であった「テストの実装速度」と「保守性」の改善を進めました。
非プログラマでもこれらを達成できる方法をいろいろ探した結果、Excelマクロを使用してSelenium IDEで動作するテストケースを自動で生成する方法にたどり着きました。
Selenium IDEは「コマンド」「対象」「値」の3つの値を手がかりに自動化シナリオを作成しています。つまりこの３つがあればブラウザを自動操作することができます。
マトリクステストの共通項目と個別項目を ○ をつけるだけで自動生成できるようにした
1行に試験ステップを１つ記載し、右側で○を付けたものだけを列ごとにSelenium IDEのシナリオとして生成するマクロを組みました。
各試験ステップにはボタンクリックやテキストの入力、対象には要素の位置、値には入力する内容などを設定します。
Selenium IDEでは共通ステップも個別ステップもすべて手作業での記録が必要だったのが、このマクロにより、共通ステップは１度だけ記録するだけで済むようになりました。また、個別のステップもCSSセレクタや入力テキストを変える程度のものがほとんどだったため、手作業での記録を逐一行う必要がなくなりました。
テストケースの作成効率が大幅に向上したことで、2018年までの１年で約6,000件のテストケースすべてを自動化が完了できました。
自動テストの本格運用に向けて – Selenium IDEからの完全脱却
テストケースの自動化が完了したところで、「CIで定期的に回せるようにしたい」という声が社内から上がってきました。
Selenium IDEには、Ruby/RSpecのエクスポート機能があり、これを使って自動テストケースを全てRSpecに置き換えました。
変換しただけだと、一部のテストケースが正常に動作しないところがあり、手作業での微修正が必要でした。
Excelマクロから直接Rubyコードをエクスポートするようにした
定期的に自動テストを運用することを想定すれば、6,000件を超える自動生成されたテストケースに対して手作業で微修正を加える運用がボトルネックになることは明らかでした。
もはやSelenium IDEはRuby変換機能しか使っていなかったため、最初からマクロでRSpecのコードを自動生成して手作業を無くすことができればさらに効率化できると考えました。
コードの自動生成のパターンはあまり多くなかったため、直接RSpecコードを生成するように変更する対応は3ヶ月程度で終わりました。
また、RSpecコードをGit管理するようにしたことで、CIからは git clone して bundle install と bundle exec rspec するだけでシンプルに自動テストが動作するようになりました。
運用がシンプルになったことで、自動テストの夜間実行なども開始されました。
さらなる課題… – 見えないタイムアウトエラーとの戦い
2018年秋までで前述のように自動テストの運用体制は整い、全てがうまくいくように思えました。しかし、実際の運用は「タイムアウトエラー」との戦いが現在まで続いています。
Selenium WebDriverの仕組み上、どうしてもDOMの変更検知が漏れてしまうことがあり、テストの完走ができずにタイムアウトエラーとなってしまうことがあります。リトライをすればOKになることがほとんどなのですが、「リトライをすればOK」なのか「本当にバグっている」なのかを切り分ける作業が必要です。
現在は、自動テストのテストケース数が9,000件を超えてきており、切り分け作業の工数が無視できないくらいに大きくなってきました。
そのため、DOMの変更検知に強いPuppeteerやPlaywrightなど他のツールを併用することで改善ができないかの検討・調査を現在進めています。
まとめ
今の状況になるまでいろいろなことがありましたが、CLOMOの試験項目は約6割くらいを自動化できました。
現在はSeleniumの弱点であるタイムアウトによるエラー率の高さを補うために他のツールの検討調査中ですが、自動テストケース数が1万を超える日も近く、今後はより効率よく短時間で自動化テストが回せるような仕組みも考えていきたいです。
