a.katoの記事一覧

そうだ スピードチェック入稿のテストを自動化しよう

ラクスルのサーバサイドエンジニア 加藤です。

今回はスピードチェック入稿(テスト対象が印刷用ファイルの場合)の自動テストについて書いてみたいと思います。

再びスピードチェック入稿とは

チラシや名刺などの印刷をインターネットで注文したことのある方はいらっしゃいますか。

印刷したいものを選んで購入し、自分で用意した印刷データをアップロードして待つと、チラシや名刺などが届きます。通常の通販サイトと違うのは、自分で印刷したいデータを用意し、アップロードする作業です。さらに入稿データはラクスルでチェックし、印刷に適した形式に変換されます。

ラクスルでは、昨年8月末にそれまでオペレータが手動で行ってきたこの工程を自動化、スピードチェック入稿をリリースしました。それまで、1日以上かかってしまうこともあったデータチェックが、その場で完了。印刷物のお届けまでの日数が想定よりかかってしまうということもなくなり、多くのお客様に使われるようになりました。

リリースまでの過程は、スピードチェック入稿リリース秘話でご紹介させていただきました。

スピードチェック入稿のその後

さて、スピードチェック入稿は、その後もどんどん進化してきました。

1. 対応商品の拡大
最初は、チラシ・フライヤーと名刺だけだった対応商品に、ポスター/ポストカード/カード/チラシ折加工/折パンフレットが加わりました。

2. 入稿ファイル形式の追加
入稿ファイル形式も最初はPDFのみでしたが、ai/jpg/png/tiffでも入稿できるようになりました。また、ラクスルで提供しているWEBブラウザから利用できる無料のデザインソフト「オンラインデザイン」で作成していただいたデータも入稿することができます。

3. UXの改善
面裏の入稿原稿向き、折の開き向きなどを実際の印刷物により近い形でご確認していただくために、仕上がりプレビューが生まれました。実際に、ひっくり返したり、開いたり閉じたりして仕上がりを確認することができます。

折加工商品の仕上がりプレビュー

さて、様々な機能追加があると、大変なのがテストです。

ファイルの変換が入るために、テストを自動化しようにも、通常のWebテストのフレームワークだけでは対応できません。悩んでいるうちにも開発は進み、リリースのたびにプロジェクトメンバーがかなりの時間をかけて、データを手動でチェックしてテストをしていました。また、テストの実施もれが発生してしまうことがありました。これでは、チームとして自信を持って開発・リリースすることができません。

テストを自動化するぞ!

なんとかしなきゃとディスカッションしていたところ、「正常リリースで生成された印刷データと変換方法に変更を加えた後に生成した印刷データを、画像に変換して比較したらいいのではないか」というアイデアと、実際にImageMagicのcompareコマンドで検証結果がチーム内でシェアされました。

印刷データ画像

差分なし

差分あり

変換方法を変えて差分ができた場合は、差分箇所が赤く表示されます。これなら、一目で問題に気づけそうです!

このアイデアをとっかかりに、さらに印刷データのファイルに関してテストしたい項目を整理してみました。

1. ファイルの規格、各BOX(*)のサイズ、カラーが注文情報と比較して正しいこと
2. 問題のあるファイルに対して正しくエラーが返されていること
3. 変更前後の印刷データの画像差分がないこと、もしくは差分が妥当であると確認できること

* ドキュメントの用紙サイズ、印刷用の裁ち落としや仕上がりサイズの定義

そして、実際にテストを開発に組み込んでいくために、非エンジニアでも気軽にテストを実施したいと考えました。それぞれテストファイルが30個だとしても、この3項目に対してテストすると3倍の90項目。テストが大変だという理由で改善が進まないのは残念です。

なるべく早く問題に気づけるようにする

早速、設計に取りかかりました。

自動テストの場合は、社内ツールでユーザは自分も含め同じプロジェクトのメンバーです。要件はユーザ向けの機能と違って自由に決められますが、今回は開発がスムーズに進むようにするためなので「開発のなるべく早い段階で問題に気づけるような仕組みを作る」を指針にしました。

スピードチェック入稿のシステムは大きく3つのレイヤーに分かれています。

・フロント:データチェック用のAPIを呼び出し結果を描画
・データチェック用のAPI: フロントから受け取ったリクエストを受けてジョブをキューイング
・バックエンドジョブ:データチェックファイル変換を実施

シンプルにするために、今回の3項目のテストの対象はバックエンドジョブに絞りました。

システム構成

先ほどの指針にしたがって、1. ファイルの規格のテストに関しては、QA環境でスピードデータチェック入稿が使われると必ずジョブ内で自動で実行され、問題が発見されればslackに通知されるようにしました。

 

ファイルアップロード後の処理の流れ

上記の処理の流れの中で、サムネイルの生成が終わったらステータスは終了にして、フロントが描画できるような状態にしつつ、データチェックエンジンのチェック用のスクリプトが走るような作りです。

2. エラーのテスト3. 画像比較テスト に関しては、実行するとしばらくQA環境のジョブを占有してしまうので、実行タイミングをコントロールできるように、手動でslackから実行できるようにしました。

実行するとテストケースのYAMLから、上記の処理のファイル検証〜サムネイル生成を行うジョブをまとめて生成、結果チェックまたは画像比較が順次実行されます。画像比較テストの場合はテストケースが何十個もあるため、期待画像を一括に生成するコマンドも用意。テストケースの更新の手間も軽減しました。

テストの結果も、既存ツールに表示しようかと思いましたが、もう少し要件があったため、以下の画像のように、Datacheck APIの管理画面に表示しています。

画像比較テストの結果一覧(差分がない場合)

 

画像比較テストの結果一覧(差分がある場合)

これで1日〜2日かかっていたテスト作業が、30分以内で実施できるようになりました!
さらにミスもなくなり自信を持ってリリースすることができるように。ファイルの処理で処理フローに変更が必要になって試行錯誤することがあっても、すぐに確認できると開発効率は上がりますし、様々な改善のアイデアも湧いてきます。

自動テストの開発後、スピードチェック入稿当初からやりたかった複雑な処理変更や細かい改善を無事にリリースすることができました。

自動テストを使い続ける

自動テストは、テスト自体のメンテナンスも必要ですね。

今回は同じリポジトリにテストケースの定義を含めたため、通常のWebテストフレームワークと同じように機能修正のPull Requestに含めてテストの変更、追加を行なっています。

自動テストに関するREADMEも用意しメンバーにシェア。エンジニアだけでなく、データチェックのエンジンの設定メンバーも、テストケースの変更・追加を行なって、テストを最新の状態に保っています。

まとめ

スピードチェック入稿の印刷用ファイルを対象にテストを自動化しました。

「開発のなるべく早い段階で問題に気づけるような仕組みを作る」を指針に3つの項目のテストが短時間に実施可能に。これにより、すぐにミスに気づけるようになり、開発効率も向上しました。

テストの自動化は後回しになってきましたが、スピードチェック入稿が進化していく上で重要な施策だったと思っていますし、早速その効果を実感することができました。

ラクスルでは、絶賛エンジニア募集中です。

「仕組みを変えれば世界はもっとよくなる」

ユーザ価値をさらに向上させつつ、より社内外のサービスと繋がっていくプラットホームを開発していきたいエンジニアを募集しています。是非一度オフィスに遊びにきてください!

スピードチェック入稿リリース秘話

ラクスルの数少ない女子エンジニアの加藤です。

今回は、8月末にリリースしたスピードチェック入稿のリリースまでのプロセスを書いてみたいと思います。

スピードチェック入稿とは

そもそも、チラシや名刺などの印刷をインターネットで注文したことのない方もいらっしゃるかもしれません。

ラクスルは、印刷物を扱うECサイトです。通常のECサイトと違って、商品を選んで配送先と決済方法を選んでもらうだけでは注文は完結しません。お客様が印刷するデータを入稿するという印刷ならではのステップがあります。

また、印刷用データはラクスルで印刷に適しているかどうかチェックして、適していない場合、お客様は再度入稿する必要があります。

これまで、ラクスルではデータが印刷に適しているかどうか、オペレーターが一つ一つチェックし、場合によっては微修正をしていました。人手でやっているため、印刷データが確定して実際に印刷工程に進む準備ができるまでに1日以上かかってしまうこともあり、急いで印刷物が欲しいというお客様の要望になかなか答えられていませんでした。

そこで、サイトを訪問している最中にその場でチェック結果がわかるようなシステムを開発しようということになりました。それが「スピードチェック入稿」です。

スピードチェック入稿画面

スピードチェック入稿画面

プロジェクトの始まり

入社してしばらく経ちそろそろ会社に慣れてきたかと思っていた4月末、プロジェクトのミーティングに呼ばれました。データチェックを自動化する理由が共有されて、成功させるぞという強い意志が感じられましたが、参加メンバーのドメイン知識が十分ではない状況で、議論も少し混乱気味。私個人としては不安がありつつも、とにかくやってみようという気持ちでミーティングを終えました。

プロジェクトは、ラクスルで提供しているデータチェック業務理解から始まりました。実際に、オペレーターの方が作業している所をメンバーみんなで見させてもらう時間もとりました。

・どんなデータが入稿されるのか
・どんなデータのどんな点を確認しているのか
・どんな修正を行っているのか
・どんなメールをお客様に送っているのか

最初はこのような基本的なポイントを一つ一つ確認していき、データチェックのドメイン知識の理解を深めていきました。

デザインと設計のプロセス

スピードチェック入稿のデザインチームはデザインスプリントを実施。毎スプリントごとにお客様からのフィードバックを受けてデザインが進みました。

使う人はどんな印象を受けるのか、どんなところで操作に詰まったり、戸惑ったりするのか。私自身はデザインチームではありませんでしたが、週ごとのデザインとフィードバックのシェアや、お客様へのインタビューの同行を通じで、ユーザ理解を深めることもできました。

ビジネスチームによるデータチェック要件の詳細化とデザインと同時並行で、システムの設計も始めました。

システムは、すぐにWebで時間のかかる処理を実装するときのオーソドックスな構成に決定。
・フロント:データチェック用のAPIを呼び出し結果を描画
・データチェック用のAPI: フロントから受け取ったリクエストを受けてジョブをキューイング
・バックエンドジョブ:データチェックやPDF変換を実施

システム構成

システム構成(模式図)

デザインスプリントが進んでいる間に、最小単位で連携して動くものを実装していきました。

初めて一緒に仕事をするメンバーで構成されたチームでしたが、REST APIなど共通した設計スタイルがあると設計検討も早く進むのを改めて感じました。

自走チームの開発スタイル

メンバーが各作業を進める中、試行錯誤したのはコミュニケーションとタスク管理でした。

ビジネスメンバー、デザイナー、エンジニアそれぞれに違うバックグラウンドを持ち、比較的自由に仕事をするメンバーが揃ったため、仕事自体はすごく速く進むのですが、みんなが協力しないと一つ一つの機能が動きません。

どんな風にコミュニケーションするか、どんな風にタスクの状況を共有したり管理したりするか。朝会や毎週の振り返りで、率直に意見やアイデアを言い合って、改善して進めました。

振り返り

毎週末の振り返り

以前のブログ記事では、開発スプリントやペアプロの紹介もありましたが、今回はペアプロは実施せず、また開発スプリントは回しつつも運用は比較的ゆるめ。それぞれのメンバーのやりやすさを優先させつつ、アクションが滞らないようにコミュニケーションをとって乗り切りました。

やっぱり何か起こる結合とテスト

いくつかのコンポーネントが連携するシステムの開発では、結合とテストの段階になって様々な考慮漏れが判明してスケジュールが遅れるというのが開発でよくある光景ではないでしょうか。

今回のプロジェクトでは、かなり前段階で様々なケースのテストデータを準備したりエラーケースの検討をしてきましたし、結合して動かすこともその都度行なっていましたが、それでもやはり本格的な結合やテストの段階で色々な問題が起こりました。

例えば、初めは入稿している原稿の縦横の方向を自動判別しようとしていましたが、チラシでは判定できるけれども、名刺では判定できないケースがあるということが間際になってわかったりしました。

もちろん前倒して考慮できればベストだと思いますが、初めての要素があるプロジェクトではなかなかそうもいかないものです。このプロジェクトでは見つかった時にその都度、チームで学習しながら、一つ一つアクションを決めていきました。

リリース!

風邪でチームメンバーが次々と休んでスケジュールが遅れ気味になったり、間際で解決が危ぶまれる課題が発生したりと、様々なことがありましたが、8月末に当初の予定通りリリース。日程的にタイトな状況になっていても、みんなでランチに行ったりとチームの雰囲気を保ち、コミュニケーションを密に取れるようにしていたのも、逆に予定通りのリリースに不可欠だったかもしれません。

リリース後も、スピードチェック入稿の状況をチームでモニタリングしながらの対応や改善、対象商品の追加が続き、多くのお客様に使われるサービスに育ってきました。フェーズが移り変わるとチームの状況ややることも変わっていきますが、これからもビジネスメンバー・デザイナー・エンジニアの垣根を超えて、お客様の体験がよくなっていくような開発を続けていきたいと思います。

 

ラクスルでは、絶賛エンジニア募集中です。
「仕組みを変えれば世界はもっとよくなる」
世界が変わっていく瞬間を一緒に体験したいエンジニアの方、お待ちしています♡