はじめまして。QA Engineer(以降QAE)チームのtakamaです。

本記事では、QAEとしてのマインドと、自分がメルペイQAEとして取り組んだことについて紹介します。
具体的には、API自動テスト、ジョブ実行ツールの改修、地味に面倒くさい作業の自動化の3点です。

記事を書こうと思い立った経緯としては、

• 筆者が転職をふと考えた際に、個人的にQAEのイメージがつかなかった
• merpayにおけるQAEの働き方が、当時公開されていた記事を読んでも見えない部分が多かった（イベントや面談などで色々な質問を通じて理解できた）

といった2つの悩みから具体的な働き方を少しでも発信できたら良いなという思いを持ったためです。

本記事では、個人的なmerpay QAEとしてのマインドと取り組みを紹介することで、merpayやQAEへの興味に繋がれば嬉しいと考えています。
（発信の内容は自分の一番興味の強い、自動化などエンジニアリング関連の取り組みにフォーカスを当てています）

QAEとしてのマインド

チームとして目指すところ

• 同チームのmiisanさんが去年書いている記事にも記載していますが、QAEの目標とするマインドは「品質保証をリードし、良いサービスをお客様に届けるためにあらゆることをする人」というものです。

個人として目指すところ

• 現在、QAEチームは、各プロジェクトに対しての専門性が担当に依存している部分があります。また、プロジェクトを兼務して対応してるため稼働が高い状況になる事もあります。これらを少しでも改善するために、極力人に依存しない仕組み作りやQA関連作業を自動化する必要があり、以下の2点に関して注力しています。
  • Technologyの力でQA関連作業を効率化する！
    • 作業の効率化を実施する際に作業が早く終わっても、作業漏れや、確認ミスなど発生しては元も子もありません。そのため、作業漏れや確認ミスなどもなく（いわゆるプロセス品質を落とさず）、確実な作業を効率的に実施できることを目指します。
  • QA関連作業の効率化のためにチームに働きかける！
    • 何も自分で全てやることはないと考えております。全て自分で効率化しよう！と思っても、結局何も出来なかった……ということも往々にしてあると考えてます。そのため、必要ならばチームを巻き込んで効率化を達成することも目指します。

個人的に特に意識していること

• 早く確実に品質保証をするために、なるべく機械的にできるところは進んで自動化した方が良いと考えています。
• 自動化のサービスを適用できるなら検討します。ただフィットするケースが多くもないので、フィットしないなら自分で作る気持ちを持っています。
• 自動化するところに対しては、保守性をとても大事に考えています。
• （よくある話ですが）繰り返し実施しないものは、無理に自動化しません。ただ、自動化にチャレンジすることでスキルアップに繋がる場合はチャレンジした方が良いと考えています。

取り組みの紹介

前置き

• 私が担当しているマイクロサービスは、mercariやCIC（指定信用情報機関）から信用情報を収集し、お客様各個人に対しての与信枠を算出するようなサービスです。
• このマイクロサービスの品質を確認する上での課題として、当初以下のようなことが考えられました（主に人員不足問題）。そのため、作業の効率化、担当依存をなくす取り組みが必須と考えていました。
  • 仕様が難しく、人が足りない！となったタイミングで人を投入しようとしても、QA作業を実施できるようになるまでの立ち上がりに時間がかかってしまい、リリースしたいタイミングにリリースできなくなる可能性があった。
  • 人が欲しい！と言っても、他のチームへのアサインが優先で、人が回せないかもしれないという頭出しがあった。

取り組み1. API自動テスト

前置き

• merpayでは、scenarigoというarchitectチームが提供しているAPIのe2eテストツールがあります。APIのrequestやresponse内容のcheckをyaml形式で記述することが可能です。yamlから呼び出せるプラグインをGolangで記述することも可能です。
  APIテストは一般的にはPostmanが使われることが多いです。merpay QAチームでも利用していますが、個人的にGolangに興味があったのと、GitHub上でレビューをする上でテストコードの内容が圧倒的に見やすかった（※）こともあり、担当したserviceではscenarigoを利用することに決めました。
  • ※ 個人的な意見ですが、当時確認したPostmanのCollectionの内容は、インデントが多い、ダブルクォートが多い、一つのCollectionの中に様々な情報が詰まっており、一つのシナリオを読み解くのが難しかったでした。それに比べ、scenarigoは1つのシナリオがシンプルに書けるため、見やすいと判断しました。
• APIテストをするのは実は初めてでした。なので、どういう風にテストコードを書いて、どういう風に自動化するのか？すら分かってない状態で、自動テストが最初から書ける状態にありませんでした。そのような経緯もあり、ここでは自動テストを書くまでに取り組んだこと（こだわったこと）を紹介します。

取り組み

1. APIテストは全てscenarigoを利用（ツールを統一）

   • scenarigoはシナリオテストを書くことが目的のツールで、テスト実行時のトリガーとして使用するのにはあまり向いていません。そういった場合はPostmanを用いて、実行することが多い傾向にあります。ただ、リグレッションテストとして最終的にscenarigoでシナリオテストを書くという着地が見えていたこともあり、ツールの理解を深める、またテストコードを活用できると考え、あえてPostmanを使わずに同じツールを利用することにしました。

2. yaml（テストコード）の共通化 ＆ 可読性を上げるためのルール決め

   • プログラミングと同じ考えで、APIを同じ様に呼び出す、かつ確認パターンを増やしたいようなケースでは共通yamlを作成し、共通yamlに対するinput/outputをコメントに明記するような形を取りました。

効果

• 取り組み1のツールを統一したことに対しては、API単体テスト→結合テスト実行時のトリガー→シナリオテストのように、それぞれ前のテストコードを少しだけ使い回すことができました。最終的にシナリオテスト（自動化のテストコード）を書く上で、効率化に少しだけ繋がりました。
• 取り組み2の共通化に対しては、（よくある話ですが）テストコードのメンテをする際に、修正箇所を絞ることができたため、仕様変更に対する全テストやり直しも気軽に実行することができました。
• テスト実施を自動化できた結果、リグレッションテストで大活躍してます。また、仕様変更に対する再テストが発生しましたが、自動化していない時に比べ、実行工数がテストコードの修正も含め約1/2となりました。

取り組み2. ジョブ実行ツールの改修提案

前置き

• 担当したマイクロサービスでは、ジョブ（バッチ処理）で実行する機能が多々あります。QA時には、内製のツールを利用して、テストデータの下準備→ジョブを実行の流れで、検証を実施していました。その際、実行結果の確認は直接Spannerのテーブルを見て、一つ一つの項目を目視確認していた実態がありました。

取り組み

• merpayで利用しているテストツールのAssert検証ができるように、内製ツールに対して機能を追加する相談の実施
  • Spannerのテーブルデータをダンプする機能自体は内製ツールに備わっていたため、Assert検証ができるようになれば機械的にチェックできると考え、開発チームのエンジニアに相談し、実装をしていただきました。
• 記載イメージ

  Assert:
  　Conditions:
  　　- File: xxx.csv
  　　　Records:
  　　　　- Key:
  　　　　　　ID: aaa-bbb-ccc
  　　　　　Want:
  　　　　　　UserId: yyyxxxzzz
  　　　　　　Status: 1

• 実装後に得た気づきですが、該当の値が存在しないことをチェックできるようにすることで、確認チェックの幅が広がりました。

効果

• 導入前は以下の手順で確認していました。
  1.ツールでジョブ実行
  2.WebブラウザでSpannerの画面を開く
  3.クエリ実行
  4.内容確認
• 導入後は以下の手順となりました。（圧倒的手順削減！）
  1.ツールでジョブ実行
  2.Assertの結果を確認
• 目視確認がなくなったことで、確認ミスも低減でき、何より実行の手間が軽減できました。また、再実行もできるようにテストコードを書くことで、そのままリグレッションテストにも利用できます。導入前よりもはるかにリグレッションテストの速度が向上しました！
• QAチーム内でも「2倍以上工数が削減され、かつ目視よりも確認の信頼性が格段に向上してすごく良かった！」などの声をいただいています。
  また開発エンジニア側からも、「結果(エビデンス)が以前よりも遥かに見やすくなり、分かりやすい！」、「Assert処理の実装工数はあまりかけてないが、QA工数がかなり軽減でき費用対効果が抜群！」などの声がありました。

取り組み3. 地味に面倒くさい作業を自動化

前置き

• QAを実施する上で、上述の紹介したツールだけだと確認できないこともあります。そういう場合は、Webブラウザ上で操作したり、結果を目視で確認したりすることが多いです。しかし地味にその作業が面倒だったりするので、チャレンジの意味も含みで、shellやPythonを用いて一部作業を自動化したりしました。

取り組み

1. GCP Container Registryにおける、特定のコンテナイメージのタグ名を取得スクリプトの作成
   • gcloud container images list-tags + --filterを用いることで取得自体はできます。ですが、さらにもう一歩、取得データをクリップボードにコピーできるpbcopyコマンドを用いて、特定のタグ名をクリップボードへコピーするスクリプトを作成しました（後はペーストするだけの状態）
2. GCP Strage（GCS）における、特定のファイルの存在有無チェックスクリプトの作成
   • gsutilコマンドを用いて、GCSからファイルをダウンロードをすることができます。それを利用し、ダウンロードができたらOK! ダウンロードができなかったらNGを出力するようなスクリプトを作成しました

効果

• いずれもコマンド一つで実行できるため、ブラウザ操作のストレスから解放されました！
• GCP関連のサービスに触れるのがmerpayで初めてだったので、知見が増えました！

最後に

• 2020年は、筆者にとってあっという間の1年（育休を挟んだので、一層早く感じつつ）で、ここに書ききれない頑張ったことや失敗したこともありました。やりたいと思ったことを声に出していけばトライさせてくれる環境なので、好きなように仕事をしています（笑）。今後ももっと自動化の部分に力を入れて、お客様へよいサービスを早く確実に届けていきたい思いです。
• 今回紹介した内容がQA Engineerの仕事の全てではないですが、本記事でmerpayのQA Engineerに興味を少しでも持ったなら幸いです。
  現在merpayのミッション・バリューに共感できるQA Engineerを募集しています。一緒に働き、切磋琢磨できる仲間をお待ちしておりますので、興味を持っていただいた方は是非とも募集要項をご覧ください。

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