This is a post for the Day 8th of Merpay Advent Calendar 2021 written by @tanakaworld from the Merpay Frontend team. Introduction Merpay, a financial service, has been constantly working on quality. The Frontend team started automating Regression Testing two years ago and Integration Testing this year. In this article, I would like to look back and summarize the policy and overall picture of test

Merpay Advent Calendar 2021 の 8 日目はメルペイフロントエンドチーム の @tanakaworld がお送りします。 はじめに メルペイは金融サービスであり、品質の維持・向上に日々取り組んでいます。フロントエンドチームでは、約 2 年前からリグレッションテストの自動化に取り組み始め、直近の 1 年間はインテグレーションテストの自動化にもチャレンジしてきました。本記事ではメルペイフロントエンドチームに於けるテスト自動化の方針とその全体像について振り返ってみたいと思います。 フロントエンドプロダクトに関わるテストは次のものが挙げられます。これらをひとつずつ順番に見ていきたいと思います。 ユニットテスト インテグレーションテスト シナリオテスト リグレッションテスト テストの種類とそのカバレッジ対象 1. ユニットテスト ユニットテストは Jest を用いて、主に

Merpay Advent Calendar 2020 の 8 日目は、メルペイフロントエンドチーム の @tanakaworld がお送りします。 2020 年後半からフロントエンドチームと QA チーム合同で、リグレッションテストの自動化に取り組んできました。E2E テストフレームワークである Cypress でマニュアルテストを自動化し、加えて TestRail を用いてテストケース管理も仕組み化することでワークフローの整備を進めています。本記事では、それらの取り組みについて紹介します。 ワークフロー改善後の全体像 リグレッションテストとは 実装を変更した結果、アプリケーション全体の振る舞いに予期せぬ影響がないかどうかを確認するテストです。メルペイではリリース前 QA の最終フェーズでリグレッションテストを実施しています。Web アプリケーションを End To End (E2E)

「業務はバラバラ」「でも助け合える」メルペイFrontendがスピード重視な開発で見つけた、孤立させないチーム体制 ひとくちに「エンジニア」と言えど、企業や事業によってその役割はさまざま…なんて当然のことですよね。特に、お客さまが触れることの多いキャンペーンページや管理画面、Webページを開発するFrontendでは、企業や事業による特色が出やすいと言っていいかもしれません。 メルカリとメルペイ、同じアプリ内にあってもサービス内容は別々。では、メルペイFrontendチームは今、どういった体制で何をしているのでしょうか？話を聞いてみたところ、返ってきたのは次の3つの軸でした。 ・ For Customer（お客さま向け） ・ For Partner（加盟店さま向け） ・ For Operator（オペレーションを行う社内メンバー） メルペイFrontendチームは、現在10名。この3つを軸

Merpay Advent Calendar 2019 の 13 日目は、メルペイフロントエンドチーム の @tanakaworld がお送りします。 メルペイの管理画面は 2019 年 2 月のサービスローンチに先立ち、2018 年 11 月にリリースされました。私は 2018 年 8 月に入社してから一貫して管理画面開発に関わり、様々な機能開発・運用を行ってきました。その中でフロントエンドエンジニアとして関わったいくつかのプロジェクトをピックアップしてご紹介します。 目次 はじめに メルペイのフロントエンドチーム メルペイの社内向け管理画面 プロジェクトの振り返り 審査業務効率化プロジェクト マイクロサービス分割プロジェクト 課題感 分割の方針 分割後のアーキテクチャ Component v2.0 リニューアルプロジェクト 課題感 デザインポリシー 開発フロー 社内向け管理画面で今後注

はじめに こんにちは、メルペイでフロントエンドエンジニアをしているnaughtLdyです。 メルペイではお客さまや加盟店さまからのお問い合わせに対応するために、専門のチームと専用のアプリケーション（以降、カスタマーサービスツール）があります。カスタマーサービスツールはメルペイの Frontend チームで開発しており、お客さまからのお問い合わせなどに対応するための機能（CS）と加盟店さま向けの機能（MS）を持っています。 当初はそのアプリケーションをお客さまと加盟店さまそれぞれの体験に責任を持つ2チームで開発をしていました。そのため、それぞれのリリーススケジュールを考慮しながら開発する必要がありました。 カスタマーサービスツールは、メルペイの機能追加に合わせて柔軟にオペレーターに機能を提供する必要があります。アプリケーションを分けた方が開発効率が上がり、安定して機能提供ができると判断しアプ

8月からcuriosity, Inc.に入社しました． curiosityは最新テクノロジーを用いたアトラクションを企画・開発しているベンチャーで， 元米YahooのエンジニアであるPoly氏と，元米DisneyのSatoh氏によって，2015年に設立されました． 体験エンターテインメントをはじめとするアトラクションや，ロボットの企画開発，映像・デザイン制作，研究開発など事業領域は多岐にわたります． 過去の原体験と今 社会人になって4年半経ち，過去を振り返りました． 元々Webエンジニアになろうと思ったのは，ものづくりが好きだったからです． 昔から自分の頭の中に想像したものを形にするのが好きで，子供の頃は粘土・折り紙・LEGO・木材・金属などでひたすら手を動かしていました． 特に迷路をかくのが好きで，なぜか物心つく前からひたすら紙に迷路をかきまくっていました． ゲームボーイやスーファミから

背景 開発で既存のREST APIの調査・改修に関わったので、とりあえず正しく動く確認できる環境を作りたかった。 Google Chromeアプリの「ARC」などがよく紹介されていて、単発でのチェックにはとても良いけど、「まとめて動作試験」だと人力作業になってしまうし、パラメータの共有などがしづらい。 テストのコード化 ということで、コードでの動作確認方法として、「Frisby+Jasmine」を使ってみた。 参考文献も多く、確かに便利。JSONでやり取りする場合の内容チェックもやりやすい。 ただ、テストは「インプット→アウトプット」の組み合わせチェックとなるので、その分かなり定型コードを書かなければいけない。 なので、APIに渡すJSON(インプット)、APIから返るJSON(アウトプット)、をGoogleスプレッドシートで集中管理できると嬉しい。 今回は、簡単にスプレッドシートからデー

TL;DR; Railsアプリケーションから、noreply@my-domain.comのような形式でドメインメールを送りたい． メールサーバーはAmazon SESを使用 RailsアプリケーションからAmazon SES APIを用いてメール送信リクエストを送る DNSはRoute53を使用 ドメインはお名前ドットコムで取得 今回はRailsアプリケーションからSDK経由でメール送信するが，他のアプリケーションでもAWSの設定は同じ．DNSやドメイン取得も他のサービス使ってもよい． (追記)2017年8月現在 Messaging に名前が変更されてる (追記)2019年12月現在 CustomerEngagement に名前が変更されてる Simple Email Service > US West(Oregon) と選択していくと，今まで通りのSES画面に遷移する． 検証環境 Rai

MacローカルでMySQL5.6.xとMySQL5.7.xを同時に起動して、アプリケーション毎に接続するバージョンのすみ分けができるようにする。 Multiple MySQL Versions with HomebrewとかでHomebrewで両バージョンをインストールして brew switch で切り替える方法でも運用してたが、切り替えやログファイル削除が面倒だったり、Rails -> MySQLのアクセスで不具合が発生したりと面倒だった。 それとDockerを使いたかったので今回はDockerでやってみた。 前提条件 macOS Sierra 10.12.6 Docker Toolboxがインストールされていること Macローカルで， mysql がインストールされていること (ローカルMacからコマンドから接続するのに必要) Dockerセットアップ Dockerホスト作成

『初めに、BeskyAirとはなんだったのか？、ターゲット層の選び方、サービスのローンチの仕方、スイッチングコスト、投資家の選び方、これから』 『初めに』 さて、約１年ぶりのブログ更新。今日はとんでもなく悲しく、頭にきて、そして学んだことがあったので日本語だけで（this is only in japanese)ブログを書きたいと思う。 今日、2年間ずっと開発して、考えて、ユーザーテストして、UI/UXのABテストして、web作って、ブートストラップで完璧なレスポンシブにしてローンチしたサービスが1日で無くなった。 作るにあたって膨大な時間、お金、そして投資家さんたちの夢をかけてやっただけにめちゃくちゃショックなので、誰かが同じような過ちをしないよう、ここに書き留めておこうと思う。 『BeskyAirとはなんだったのか？』 そもそも、どんなサービスをローンチしたのかの前に、キャビンアテンダ

google-spreadsheets-parserを使って， スプレッドシートで管理しているデータをテストで使用する． 背景:データの二重管理をなくしたい あるJSモジュールのパラメタライズドテストコードを書いていた． パラメータとそのテスト結果はGoogleSpreadsheetで表管理していて，ビジネス・エンジニア共に使用していた． はじめはSpreadSheet上にそれらの値をJSで扱える形式にconcatenateとかしてコピペしていたが， バリエーションが膨大になり，データ二重管理の問題が発生しメンテナンスに難があった． 普通にパラメタライズドテストを書くとこんな感じ grunt x karma x jasmine の環境構築手順はこちら．