Webサービス・Webサイト開発の歴史から紐解く食文化　番外編②　～テスト自動化への道～

こんにちは。社長室兼システム部の山城です。

7月から約3ヶ月かけて「Webサービス・Webサイト開発の歴史から紐解く食文化」の執筆をしてきました。今日はその中に入れられなかったテスト自動化の話をしたいと思います。

まず、私の食文化でのキャリアとは

私は2012年12月に食文化に入社し、最初はカスタマーサポートで修業をしていました。最近は必ずしもそうではないのですが、かつての食文化は、会社の仕組みと取り扱う商品とお客様を知るために入社したらまず出荷またはカスタマーサポートを経験するのが基本でした。

出社したらまず、うまいもんドットコムなどECサイトの管理画面にログインし、注文確認、そしてお客様からのメールの確認と返信、電話が来たら誰よりも先に電話に出て（新人ですから！）、夕方には加盟店への未出荷確認。そしてその隙間に商品アップしたり、別で依頼されていたデータ移行の事務の仕事をこなしたりしていました。前職も含め、社会人になってから一度も固定電話を取るという経験がなかったのと内気な性格なので（？）、電話はとても苦手でした。特に、お客様からのお叱りの言葉には慣れることができず、毎回うまく対応できずに、こっそり凹んでいました。

また、入社直後が年末の繁忙期だったので、1日の半分は出荷場へ出向き、青果の検品をしました。ひたすら出荷伝票や冷蔵シールを箱に貼る、とか、段ボールの中から品質劣化している商品をはじくとか。みかんばかり検品していたような・・・。検品落ちした商品は、勉強のために持ち帰り事務所で試食することもありました。

そして入社から3ヵ月ほど経った頃に、正式配属という形で新規事業部とシステム部に配属になりました。3ヵ月のカスタマーサポートで経験を積んだことによって、会社の仕組みとサイトの会員のペルソナをかなり深くまで理解することができ、その後の円滑な業務遂行につなげることができました。

配属当時はシステム部は別の担当がいたので私はサブ的立場で、新規事業部がメインでした。時代で言うとこの頃です。社長にくっついて打合せして提案して議事をまとめてフォローして決まったことを具体化する・・・の日々でした。そして2013年にシステム担当だった先輩社員がマーケティング部の重要任務に抜擢されて、その玉突き的な人事異動で私がシステムをメインで担当することになり、それ以降、システム周りを私が担当しています。

社長室に配属されたのは2015年に育休明け復帰した時です。前任者の退職によりそこにポジションが空き、任命されたのですが、最初に言われたのが、「山城さん、豊洲移転、よろしくね」でした。白紙の計画書とともに。引継ぎ以上。仕事復帰したらかなり重い仕事が降ってきた・・・と思ったのを記憶しています。この話はどこかでまた紹介したいと思います。

さて、そんなこんなで2013年から本格的に食文化のシステムを担当するようになりました。前職の経験があったので、すんなり合流はできましたが、仕様書がほとんどないとか（今はあります）、テストケースがないとか（今はあります）、故に本番リリース後のバグが多いとか（今はかなり減りました）、リリースのスピードが異常に速いとか、開発統括のKenji氏がマルチすぎるとか、良くも悪くもカルチャーショックは多々ありました。

テスト自動化の提案

そして、私には、以前からどうしてもやりたかったけど、心の奥底に眠らせていたことがありました。それはテストの自動化です。

これまで、AmazonPayの対応や定期購入機能の導入など、会員向けの規模が大きい開発案件が発生した時、短期の派遣社員を採用し、テストをしてもらっていました。テストそのものは経験のある方が来てくれていたので軌道に乗ってしまえば問題なく進むのですが、仕様を説明するのが結構大変でした。また、複数ブラウザによるリグレッションも相当人件費がかかっていました。

その人件費を積み上げていったら、いつかはテスト自動化コストが有利になることもわかっていたのですが、売上が際どく、システム維持コストすらカットが求められていたところに、テスト自動化というどちらかというと保守的な提案を社内にあげる度胸が私にはなく、胸に秘めているだけになっていました。

ですが、2020年以降収益が改善してきた頃、ここぞというタイミングで検討を始めました。まずは、ネットで調べて出てくるテスト専門会社に問い合わせをし、色々なツールをのデモを見て比較検討し、見積もりを取りました。途中、RPAツールの方がいいのかとか、テストそのものをアウトソースした方がいいのではと横道にそれたりもしましたが、半年かけてMagicPodを導入することに決めました。UIは最後まで候補に残っていたもう1つのツールの方が上でMagicPodの方がギーク向けだったのですが、最低限の機能要件を満たしていることと良心的な月額コストに加え、Seleniumベースなので将来スクリプトがダウンロードできるようになる可能性と、エンジニアっぽい社風やビジネスマインドに共感し、採用を決めました。そして社内の稟議を通し、契約、実装へ。

テストケースは、会員様向けのユーザー画面が1,239件、食文化のサイト運営チームやカスタマーサポートなどが使用する管理画面が1,885件、加盟店が使用する店舗管理画面が101件ありました。そのうち、バグが出た時に影響が多いユーザ画面、さらにその中でも重要な機能である会員登録、ログイン、お買い物に関するケースに絞って自動化することにしました。

最初2ヵ月はMagicPod社が紹介してくれたベンダーに委託し、正常系フローを実装してもらいました。お届け先が自分or自分以外、支払い方法がカードor代引きor銀振orAmazonPayorポイント、のしありorなし、日付指定ありorなし、クーポン利用ありorなし、などの購入バリエーションを網羅し、データパターンを作るのが結構大変でした。

その後は、食文化の開発部隊が引き継ぎ、テストの合間にコツコツとメンテをし、現時点では、エラー系も含め、944ケースのうち774件のケースを自動化しました。環境制約やツールの制約で実装できないケースや画面の表示確認など自動化に向かないケースが118件あるので、それを差し引くと、93%のカバー率です。なかなか高いのでは！？ちなみに、残りのマイページなどの機能も自動化したいとは思うものの、まだ着手はできていません。

これを、深夜2時にAndroid Chrome、4時にiOS Safari、6時にPC Chromeにクラウド環境で自動実行させ、朝一でテスターが結果確認をし、クラウド実行できないFireFoxとEdgeは専用のテスト端末で私が出勤後にランダムで実行する、というアナログ運用をしていました。していたのですが、先日、ついにFireFoxとEdgeがクラウド対応し、日々の自動実行に組み込むことができました。本当の意味での自動化を達成です。

テスト自動化と合わせて体制強化を図ったことにより、案件ごとにテスト担当の派遣社員を雇うことはなくなり、細かいバグも日々の自動テストのタイミングで気づくことができるようになりました。特にブラウザごとのリグレッションテストは、同じことの繰り返しを人がやる慣れによる確認ミスも防げるので、工数削減以上の効果が得られました。また、MagicPod側の不具合が出た際や原因不明なエラーも迅速にお返事およびご対応いただけており、ツールだけでなくサポート体制もとても満足しています。（あ、決してMagicPodの回し者ではございません。）