MODDのテスト自動化への取り組み

株式会社クロスワープ eコマース事業部
エンジニアの鈴木と申します。

ブログを通じまして、
MODDの運用とエンジニアリングを支える、
様々な取り組みについてご紹介できればと思います。
宜しくお願い致します。

今回は、MODDのテスト自動化への取り組みを一部ご紹介します。

Selenium x Bitbucket x AWS EC2 x Slack

MODDではブラウザの自動テストに
Selenium を利用しており、全体像は以下のようになっています。

赤い矢印は人手が介入するところで、青い矢印は自動 or 手動で実行されます。

①テストケースをSeleniumIDEで作成してBitbucketにプッシュします。

　MODDではテストの作成に専属の人はアサインされていません。
　非エンジニアも含めてすべての人がテストケースを作成します。
　今はコンサルチームの新人 Ｙ口君が特に頑張ってくれています。
　テストケースに加えて、テストの実行単位ごとにテストスウィートも登録します。

②Bitbucketにプッシュされた内容は、slackに投稿されます。

　slack はこちら。

③テスト実行のタイミングで、AWS EC2のインスタンスが立ち上がります。

　このインスタンスは、事前にSeleniumインストールなどの環境構築がされており、
　テスト非実行時には、寝かしてあります。（今回この部分の詳細は割愛いたします）
　インスタンスが立ち上がったら、実行前にBitbucket から最新のテストを取得して
　テストスウィートが開始されます。

④実行結果はslackに投稿されます。

　こんな感じです。
　Slackには、エラーログとテスト結果の詳細へのリンクのみ出力されます。

⑤実行結果をチェックします。

　実行結果に不審な点がある場合には、手元でテストケースを実行して確認します。

　テストケースの量がふえて実行時間がネックになる場合には、
　EC2インスタンスの数を増やして並列化します。
　この時、テストの実行単位はテストスウィートを分割することで管理します。

エンジニア x 非エンジニア

　どれだけテストの自動化を進めても、
　サービス品質保証の最後の砦はやはり人だと思いますので、
　テストの自動化だけではなく、
　チームの全員がテストに対する意識を高められるような
　運用の仕組みにしていきたいです。　（まだまだ道半ばではありますが…。）

　ご参考までに、selenium実行用のEC2で動いているpowershellスクリプトは、
　以下のような感じです。

最後に

どこまでのテストをseleniumで自動化するのかという決めが重要です。
テスト自動化にかかるコストと効果のトレードオフを理解していないと、
膨大に無駄な時間を浪費してしまいます。

あとはツールに縛られたくないので、slackがメールになっても、
AWS EC2がAzure仮想マシンになっても良いように考えておきます。

ブラウザテストの宿命で、
ユーザインタフェースの変更に伴う、テストケースのメンテナンスが結構発生します。
ある程度諦めて受け入れるしかないのですが、
たまにはコミットログを見返してやると、失敗しやすいテストや変更に弱いテストの傾向が見えたりすることもあります。

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