freeeの開発情報ポータルサイト

トップ > 技術 > 【freee x メルペイ】QA Tech Talk 〜リリースを早めるQA〜 に参加しました

【freee x メルペイ】QA Tech Talk 〜リリースを早めるQA〜 に参加しました

技術 QA

こんにちは、2021年4月にfreeeに新卒で入社したberryです。

今年は5月末にほぼリモートの新卒研修が終わり、6月頭から新卒はそれぞれの部署に配属されていきました。私はQA配属となり、現在テスト技法やテスト自動化の勉強に勤しんでおります。

本記事では2021年6月23日にfreee株式会社と株式会社メルペイさん合同で開催されたイベント、【freee x メルペイ】QA Tech Talk 〜リリースを早めるQA〜について、理解のために各ディスカッションをまとめ、新人なりに考えた/感じたことを残したいと思います。

目次

上流工程で何をやってQAを早めているか

  • メルペイでは
    • 開発段階で開発チームと一緒に要件定義や開発の設計を考える
    • 外部パートナーと仕事をする際は企画段階から初期品質を作ったりしている
      • 開発前の意識のすり合わせなどにQAも入っていく
    • QAをしてバグを見つけるというより、発生する前に防ぐ
  • freeeでは
    • スクラム開発なのでスプリント（一週間）の初めにengとQAそれぞれ開発計画テスト計画を立てる
    • 実装が始まる時にリスク洗い出し会を行い、テスト項目について議論し、プロダクト＆テストをそれぞれ作り始める
    • 実装し次第テストも順次行われるので実装が終わる頃にはQAも7~8割終わっている
    • 実装中にQAで仕様の抜け漏れなどを発見できると、本来なら間違ったまま進めて手戻りが発生していたところをカバーできることがある

まとめ

基本的に根本の部分であればあるほど間違った際に見直さなければならない範囲が広くなってしまうため、そういった部分はなるべく早めにテスト&開発側との議論を行う必要がある。と理解しました。

QAの方たちは難しい仕様をどうやってカバーしているのか

  • メルペイでは
    • 大変で課題になっているが、オンボーディングの充実やメンターとの話し合いでキャッチアップしていく
      • QAが横断的に仕様を理解することによって上流の話し合いにも入っていける
      • eng側はどうしても各マイクロサービスを突き詰めることになり、他サービスとの連携時に齟齬が発生しやすいため、QAが架け橋となって課題やプロジェクトの状態を整理していく
  • freeeでは
    • メルペイさんとほぼ同様
    • サービス間の連携がある場面で、マイナス金額の考慮の仕方が違うことがレビューによって判明したため、横断的な視点を持てるQAの存在は重要

まとめ

開発時にバグが発生するのは、開発対象とそのプロダクト以外との繋ぎ込み部分になりやすい。そのためQAとしてプロダクトに関わる時は、それぞれのサービス同士の知る必要がある仕様を相互に把握できるように動けると良いと感じました。

先ほどメルペイさんの回答にあったQAのオンボーディングとはどのようなことをやっているか

  • メルペイでは
    • マイクロサービスを理解するために、自分の理解を他人に説明したり、処理の流れを説明したりなどして理解ができているかを確認しながら進める
    • 最近はテクニカルな部分も増えてきているため、一筋縄ではいかない場面も増え、難しい課題となっている

まとめ

他人に説明するという行為は理解度チェックにおいてとても強力な手段であり、かかる時間に見合った効果がありそうだと感じました。私も自分が理解できた！と思ったらその物事を説明させてもらう場を作ってみたいと思います。

また、現在私は毎日日報を書いており、得た知識を自分がどう咀嚼したかどうかを含めて先輩方の見えるところに投稿しています。私は内容に関してフィードバックや補足をもらったり、先輩方からは私がどの程度理解を進められているかを把握できるという利点があると考えています。

開発中のテストでどういうことをやってリリースを早めているか

  • メルペイでは
    • 開発段階からQAがspecを確認、把握して、テストを書いていく
    • テストを書くとき（一番プロダクトについて詳しいとき）にリグレッションテストを一緒に作る
    • postmanを利用していたが、自社作のAPIテスト用ツールを制作し、使っている
  • freeeでは
    • フィードバックを早くすること
    • 開発時にunitテストを書く文化があったり、ステージングデプロイ時にUIやAPIレベルのテストが走るなど、素早いリターンを意識している
    • 会計帳簿などのドメインとして重要な機能は確実にチェックするようにしている
    • 本当はもっと手前側（開発に近い側）でバグ等を拾っていきたい
    • 手前側でやる基盤やテストの書き方の浸透がまだまだなため、課題となっている

まとめ

フィードバックが早いとリリースが早くなる理由を考えました。最初の質問と同じく間違った前提をもとにコードを書いてしまう手戻りが防げることはもちろんですが、コードを書いた記憶が新しいうちにやり直しができることにもあると思います。私も1週間前に書いたはずのコードを覚えておらず、「この部分のコードがこの書き方でいい理由ってなんだっけ？」と思ってコードを追い直す作業をしなくて済みます。

またフィードバックの早さ以外での部分でも、QAとして目指していきたい理想的な動き方がまとまっていると感じました。

自動テストの実装はQAエンジニアが対応されているのでしょうか？

  • メルペイでは
    • APIテストはQA*1、unitやe2eはengが書いている
  • freeeでは
    • e2eはQA、unitやAPIテストはengが書いている
  • 普通はengが具体度の高い部分を担当して、QAが抽象度の高い部分を担当すると思ったが、何故逆なのか
    • e2eテストをxctest（swiftのテスト）などで書いているため、engが書きやすい
    • 開発とQAが同じ視点で話をしたいため、最終的にはxctestもQAが書きたい
    • QAと開発でラインを分けたくない => 全員品質

*1 配信においてunitテストはQAが書いていると解釈していましたが、後日確認を取ったところunitテストはengの方が書いているとのことでした。

まとめ

2社で完全に逆の結果となり興味深かったですが、使用する言語の面から考えると妥当だと感じました。特にUIテストは要素の指定方法なども手段が豊富なため、同じ言語でもテストの書き方は別物になると考えています。となるとやはりある一つの言語を使って10の作業をするのと、複数の言語で半分づつの作業をするのではやはり後者の方が難しいです。それによってQAとengで書くテストが分かれるのは仕方がないと思いましたが、e2eとunit&APIそれぞれのカバーしているシナリオはお互いに把握できるべきだと私は考えています。

マニュアルテスト、ユニットテスト、E2Eテストなどは（誰が）どういう割合で実施していますか？

  • メルペイでは
    • サービスによる
    • 各チームでどこをどうテストしていくかを考えて、スケジュールやタスク量をなどを鑑みてQAとengで作業量を割り振る
    • GOを使っているが、QAもengもテストを書けるので、柔軟に対応できる
  • freeeでは
    • マニュアルテストはQA
    • unitテストはeng
    • e2eテストはseqチーム

ここでもメルペイさんは誰が何を書くかを分けずにテストを実施しているというお話でした。個人的に感動したのは、「スケジュールやタスク量をなどを鑑みてQAとengで作業量を割り振る」という部分で、作業量のバランスが偏ってしまうことによるQA待ちや開発待ちという時間が発生しにくくなるのは画期的だと感じました。

上流や開発テスト自動化ができるQA人材を生み出すためのキャリアパスはどうなるのか

  • メルペイでは
    • 夢物語かもしれないが、全てをできるQAを育てようとしていて、あえてset（freeeのseq）チームを作っていない
  • freeeでは
    • seqは存在するが、組織としてのステップアップ的にはできる人から教わって全体に伝播するという流れの途中であり、全員が自動テストを書けるようになるための勉強中

まとめ

正社員として長い期間会社に貢献し、QAもテストコードをバリバリ書け、上流工程の話もでき、プロダクトを横断する知識があるという姿を目指すのは、やはり簡単には実現しないと思います。

一方で全プロダクトを横断する知識はなくともプロダクト群の基盤関係の整備を進めていくことによって、1プロダクトが外と通信を行う部分は基盤を経由することが多くなるはずなので、基盤周りとプロダクトに横断的な理解があるQAというのはステップアップの段階として目指せるのではないかと新人ながらに考えています。

リリースした後の改善活動はどうしてる？

  • メルペイでは
    • 自動化の部分
    • 新規でサービスを作るときはマニュアルテストになってしまうが、ファーストリリースの直後に頑張って自動化する
    • 後からもう一度テストして欲しい、となったときに16時間かかっていたマニュアルテストがサッと回せるようになった
  • freeeでは
    • バグを大事にしていて、再発しないように原因究明をして知見を蓄える
    • 会計帳簿や帳簿のまとまりなどは一朝一夕では身につかないため、税理士のPMの方からシナリオを作ってもらって質の良いテストを行なっている

まとめ

freeeでは税理士のPMがシナリオと作るという非常に幸運なケースだと思いました。しかし、他の分野でサービスを作っている企業にてドメイン知識を持った人材が社内で継続的に協力してくれるような状態を維持するのは簡単なことではないと感じました。採用活動の難しさの理由の一端を垣間見た気がします。

技術的負債に対してなにか取り組み等はされていますか？

  • メルペイでは
    • リリースを急がないといけない場合、負債を抱えた状態でもリリースしないといけないことがある
    • 負債が溜まってしまうと新しくリリースができなくなる
    • 負債を棚卸してどういう負債があるかを確認し、負債の再発防止方法を検討していった
  • freeeでは
    • 最初はバグが出てしまってPMの方が謝罪に行ったりすることもあった
    • バグの振り返り、言語化できていなかったが考慮が足りなさそうだと思っていたところを洗い出したりしていた
    • コードが書かれた年代に着目し、いつバグの元となるコードが入ったか、この年代の部分のコードは手をつけなくて大丈夫そうだ、というのをengと共に確認していった

まとめ

2社ともチーム内でバグや負債を一旦集めて分析するという工程が入っており、何かのきっかけで見直しをしようという動きがないとそもそも工数を取れないようなイメージを受けました。意識的に負債の棚卸しを出来ればいいなと思います。とはいえ纏まった工数を取るのも大変そうです。

使用性テストはいつどうやっているか

  • メルペイでは
    • ユーザビリティ専門の部署がやっている
  • freeeでは
    • ユーザビリティテストは普段のテストの中でやっている
    • アクセシビリティテストも時間が取れた時にガッとやっている

まとめ

メルペイさんではQAとユーザビリティは分けているという点が印象的でした。どんなサービスを作るかという点ではなく、サービスをどうやってより良くしていくかという点がQAの関わっていくポイントであると理解しました。

JSTQBやIVECなどの知識をQAにどう活かしているか

  • メルペイでは
    • 知識が馴染んでしまっていて活かせている事に気づいていないかもしれない
    • 採用などでは意識しない
  • freeeでは
    • プロダクトの知識やドメインの知識が重要

まとめ

資格の知識が馴染んでしまってそれを使っているかどうかわからない状態は、実務経験と知識が混ざり合うことで発生すると考えています。人によって適したやり方はあるはずですが、知識から入っていくという人もいると思っています。

QAが負荷試験や性能試験のテスト環境を準備するか

  • メルペイでは
    • SREチームが主体となってやっていく
    • セキュリティ面をfreee以上に重視しないといけないため、セキュリティチーム（freeeのpsirt）と一緒に考えていく
  • freeeでは
    • freeeプロジェクト管理立ち上げの時、eng, QA, SRE三位一体でやった（ガトリングを使った）

まとめ

負荷やセキュリティはドメインによってそれぞれ必要なボーダーが変わってくるため、全体を俯瞰する視点の必要性を感じました。

終わりに

今回、QA Tech Talk 〜リリースを早めるQA〜という形で配信を視聴しました。結果としてメルペイさんとfreeeそれぞれのQAの組織内での動き方を比較しながら考えることができ、とても勉強になりました。
末筆になりますが、このような機会を設けてくださったメルペイさんに心より感謝申し上げます。

参考資料

  1. オンボーディングとは何か？

    オンボーディングの達成度合いを図る目安として、各技術領域ごとに独自のKPIを立て、進捗確認をサーベイにて実施しています。リモートでのオンボーディングの状況を定量的に可視化することで、適切なサポートができるよう仕組み化しています。

    • 新しい分野への配属直後では、「各種スキルに対してどの程度の技量が求められているか」以前に「そもそも各種スキルは何があるのか」という段階である場合も多々あると思った。サーベイのコストを考えなければ、独自のKPIを立てて進捗確認を行うのはとても効果的だと感じた。

  2. Postmanについて

    • jenkinsのAPI単位バージョンのようなものだった
      • APIリクエストを送り、そのレスポンスの内容をテストでき、jenkins同様環境変数なども設定できる。
      • リクエストを投げ、そのレスポンスを次のAPIのリクエストに含めるなどの結合テストを行ったりもできる。
      • jenkinsのjob, SUITEのようにテスト、コレクションがある

  3. メルペイでのxcresult活用事例

    • メルペイではPRが出たときや夜間にCircleCIが起動し、テストの実行結果をTestRailで管理したい。
    • 実行されるXCUITest（スマホ用テスト）の結果をFastlane（Seleniumのスマホ版）のカスタムアクションでTestRailにAPIで連携したい。
    • テスト結果のResult Bundle（*.xcresultファイル）はXcode上で確認できるが、そのままでは人が読めない＆機械的に読み取るのが難しい。
    • Appleが提供しているxcresulttoolを用いることによってxcresultファイルをjson等に変換し、集計できるようになる。

  4. メルペイ iOS にスナップショットテストを導入した話

    • iOSで画面のスナップショットをそのまま画像として比較することができる

  5. 自作ツールについて書かれている記事 APIテスト用のツールscenarigを実装した話のようです 記事内の自動化に対する考え方が興味深かったので抜粋します

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

    • 単純作業は機械にやらせる
    • 保守性が低いとメンテナンスコストだけかかってしまうテストが生まれてしまう

    • 繰り返し実施しないものでもスキルアップを意識してわざと書くというチャレンジは興味深かった

    • 元々内製ツールを用いたテスト時にジョブの実行結果を目視で確認していた

    • Assertを使ってテスト結果を確認するために内製ツールに機能を追加したい旨をエンジニアに相談し、実装してもらった
    • 結果、工数が2倍以上削減され、さらに目視による確認ミスもなくなった
    • と、目覚ましい効果があった模様

    個人的には「発想はあったが、エンジニアに依頼して頼るところはちゃんと頼る」という姿勢を見習いたいと思いました。仮に無理をして自力で全て実装できてもバグを埋め込む可能性は上がり、工数も余計に取ってしまうため、誰がやるといったスコープは意識したいです。

  6. 技術的負債への取り組み：より良いサービスを継続的に届けるための新しい習慣ができるまで

    • リリースラッシュによりリソースを割けず、マイクロサービスとして切り出すべき機能を既存のシステム上に実装し、技術的負債を追うことを選択したが、やはり後続のブロッカーや保守運用コストの増大を引き起こしてしまった

    • チーム内にあった「ヤバそう」という空気を実体化することを説明し、丁寧に振り返りを行った

      発生した障害の振り返り・共有 障害発生から解消までの対応率の数値化 暫定対応などチケットの対応率を数値化

    • 自動テストも作成し、デグレチェックにかかるコストを削減した

    • 結果、問題の発生に対して迅速に対応をし、チームとして再発防止策を考える風習が生まれ、数字にも現れた

    感想としては、問題に対するチームとしての向き合い方が改善されたように感じました。技術的負債の発生の原因を探るプロセスを共有したことによって開発メンバーも新たに発生したバグに対する向き合い方が変わったりなど、取り組める構造を作り出していくことがQAの役目なのかな、とも思いました。

  7. Cypress + TestRail による Frontend E2E テストの効率化について

    • Cypressというe2eテストのフレームワークをTestRailで集計する
    • 集計の行き着く先はTestRailが多い