ハコベルの中村です。
みなさんのチームではE2Eテストをやってますか？このブログでも紹介した通り、印刷サービスの開発チームでもE2Eの記事が出たばかりですが、ハコベルコネクトの開発チームでも同時期にE2Eテストを構築しました。（事業部も違えば、プロダクトのフェーズも違うので、力をいれたいポイントが異なっていて、読み比べするのも面白いと思いますので是非両方読んでいただけると！）
ハコベルコネクトの関心としては主にこれらの点でした。
この課題を軽減するためにE2Eテスト環境の構築をスタートしました。TestCafe + Browserstack という組み合わせを選択しました。今回の記事ではどのような基準で選定したのか、組み合わせて使用する際に必要な設定を紹介してみます。
ラクスルのサーバサイドエンジニア 加藤です。
今回はスピードチェック入稿（テスト対象が印刷用ファイルの場合）の自動テストについて書いてみたいと思います。
チラシや名刺などの印刷をインターネットで注文したことのある方はいらっしゃいますか。
印刷したいものを選んで購入し、自分で用意した印刷データをアップロードして待つと、チラシや名刺などが届きます。通常の通販サイトと違うのは、自分で印刷したいデータを用意し、アップロードする作業です。さらに入稿データはラクスルでチェックし、印刷に適した形式に変換されます。
ラクスルでは、昨年８月末にそれまでオペレータが手動で行ってきたこの工程を自動化、スピードチェック入稿をリリースしました。それまで、１日以上かかってしまうこともあったデータチェックが、その場で完了。印刷物のお届けまでの日数が想定よりかかってしまうということもなくなり、多くのお客様に使われるようになりました。
リリースまでの過程は、スピードチェック入稿リリース秘話でご紹介させていただきました。
さて、スピードチェック入稿は、その後もどんどん進化してきました。
1. 対応商品の拡大
最初は、チラシ・フライヤーと名刺だけだった対応商品に、ポスター/ポストカード/カード/チラシ折加工/折パンフレットが加わりました。
2. 入稿ファイル形式の追加
入稿ファイル形式も最初はPDFのみでしたが、ai/jpg/png/tiffでも入稿できるようになりました。また、ラクスルで提供しているWEBブラウザから利用できる無料のデザインソフト「オンラインデザイン」で作成していただいたデータも入稿することができます。
3. UXの改善
面裏の入稿原稿向き、折の開き向きなどを実際の印刷物により近い形でご確認していただくために、仕上がりプレビューが生まれました。実際に、ひっくり返したり、開いたり閉じたりして仕上がりを確認することができます。
折加工商品の仕上がりプレビュー
さて、様々な機能追加があると、大変なのがテストです。
ファイルの変換が入るために、テストを自動化しようにも、通常のWebテストのフレームワークだけでは対応できません。悩んでいるうちにも開発は進み、リリースのたびにプロジェクトメンバーがかなりの時間をかけて、データを手動でチェックしてテストをしていました。また、テストの実施もれが発生してしまうことがありました。これでは、チームとして自信を持って開発・リリースすることができません。
なんとかしなきゃとディスカッションしていたところ、「正常リリースで生成された印刷データと変換方法に変更を加えた後に生成した印刷データを、画像に変換して比較したらいいのではないか」というアイデアと、実際にImageMagicのcompareコマンドで検証結果がチーム内でシェアされました。
印刷データ画像
差分なし
差分あり
変換方法を変えて差分ができた場合は、差分箇所が赤く表示されます。これなら、一目で問題に気づけそうです！
このアイデアをとっかかりに、さらに印刷データのファイルに関してテストしたい項目を整理してみました。
1. ファイルの規格、各BOX(*)のサイズ、カラーが注文情報と比較して正しいこと
2. 問題のあるファイルに対して正しくエラーが返されていること
3. 変更前後の印刷データの画像差分がないこと、もしくは差分が妥当であると確認できること
* ドキュメントの用紙サイズ、印刷用の裁ち落としや仕上がりサイズの定義
そして、実際にテストを開発に組み込んでいくために、非エンジニアでも気軽にテストを実施したいと考えました。それぞれテストファイルが３０個だとしても、この３項目に対してテストすると３倍の９０項目。テストが大変だという理由で改善が進まないのは残念です。
早速、設計に取りかかりました。
自動テストの場合は、社内ツールでユーザは自分も含め同じプロジェクトのメンバーです。要件はユーザ向けの機能と違って自由に決められますが、今回は開発がスムーズに進むようにするためなので「開発のなるべく早い段階で問題に気づけるような仕組みを作る」を指針にしました。
スピードチェック入稿のシステムは大きく３つのレイヤーに分かれています。
・フロント：データチェック用のAPIを呼び出し結果を描画
・データチェック用のAPI： フロントから受け取ったリクエストを受けてジョブをキューイング
・バックエンドジョブ：データチェックファイル変換を実施
シンプルにするために、今回の３項目のテストの対象はバックエンドジョブに絞りました。
システム構成
先ほどの指針にしたがって、1. ファイルの規格のテストに関しては、QA環境でスピードデータチェック入稿が使われると必ずジョブ内で自動で実行され、問題が発見されればslackに通知されるようにしました。
ファイルアップロード後の処理の流れ
上記の処理の流れの中で、サムネイルの生成が終わったらステータスは終了にして、フロントが描画できるような状態にしつつ、データチェックエンジンのチェック用のスクリプトが走るような作りです。
2. エラーのテストと 3. 画像比較テスト に関しては、実行するとしばらくQA環境のジョブを占有してしまうので、実行タイミングをコントロールできるように、手動でslackから実行できるようにしました。
実行するとテストケースのYAMLから、上記の処理のファイル検証〜サムネイル生成を行うジョブをまとめて生成、結果チェックまたは画像比較が順次実行されます。画像比較テストの場合はテストケースが何十個もあるため、期待画像を一括に生成するコマンドも用意。テストケースの更新の手間も軽減しました。
テストの結果も、既存ツールに表示しようかと思いましたが、もう少し要件があったため、以下の画像のように、Datacheck APIの管理画面に表示しています。
画像比較テストの結果一覧（差分がない場合）
画像比較テストの結果一覧（差分がある場合）
これで１日〜２日かかっていたテスト作業が、３０分以内で実施できるようになりました！
さらにミスもなくなり自信を持ってリリースすることができるように。ファイルの処理で処理フローに変更が必要になって試行錯誤することがあっても、すぐに確認できると開発効率は上がりますし、様々な改善のアイデアも湧いてきます。
自動テストの開発後、スピードチェック入稿当初からやりたかった複雑な処理変更や細かい改善を無事にリリースすることができました。
自動テストは、テスト自体のメンテナンスも必要ですね。
今回は同じリポジトリにテストケースの定義を含めたため、通常のWebテストフレームワークと同じように機能修正のPull Requestに含めてテストの変更、追加を行なっています。
自動テストに関するREADMEも用意しメンバーにシェア。エンジニアだけでなく、データチェックのエンジンの設定メンバーも、テストケースの変更・追加を行なって、テストを最新の状態に保っています。
スピードチェック入稿の印刷用ファイルを対象にテストを自動化しました。
「開発のなるべく早い段階で問題に気づけるような仕組みを作る」を指針に３つの項目のテストが短時間に実施可能に。これにより、すぐにミスに気づけるようになり、開発効率も向上しました。
テストの自動化は後回しになってきましたが、スピードチェック入稿が進化していく上で重要な施策だったと思っていますし、早速その効果を実感することができました。
「仕組みを変えれば世界はもっとよくなる」
ユーザ価値をさらに向上させつつ、より社内外のサービスと繋がっていくプラットホームを開発していきたいエンジニアを募集しています。是非一度オフィスに遊びにきてください！
