#presentation Date : 2021-07-30 [https://www.youtube.com/watch?v=Y082c0oKvfk&t=1101s](https://www.youtube.com/watch?v=Y082c0oKvfk&t=1101s) # なぜこの動画を見た # なんの動画か # メモ ## お客様に選ばれるサービスを継続的に届けるために必要なこと ~QAエンジニアの立場で考えてみた~ Mizuki Sakurai さん 本日のメッセージ 「早く行きたければ、ひとりで行け。遠くまで行きたければ、みんなで行け」 メルペイリリース前 - ひとりひとりの裁量が大きくて1人の力でそれぞれのマイクロサービスを担当することが多かった メルペイリリース後 - お客様に選ばれるための価値を継続的に届けるために必要なこと - 新機能開発 - ニーズを満たすための新しい機能 - グロース開発 - 使いたい!と思ってもらえるような開発 - 保守運用開発 現在の品質保証 - Product - プロダクト自体の品質 - 注目されがちだけれどこれが全てではない - Process - 要件定義の段階から参加する - Team - チームとの協力、QAが架け橋になることが重要 「定額払いと」いう機能をリリースしたときの話 - 技術的な難しさやドメインの理解の難度が高い - プロジェクト難度も複数の関係者が関わっていたり、法律的な観点の考慮が必要 Team ![image](https://gyazo.com/bd02e008f55b98fa5db1c36c661138f5/thumb/1000) Process テストポリシーの整備 ![image](https://gyazo.com/4d33230904335fef2baf7b6155b21fed/thumb/1000) テスト環境の整備 ![image](https://gyazo.com/b4f698dea100e584bf0066d6461ff107/thumb/1000) - アーキテクトチームに相談してテスト環境の構築を一緒に行っていった ## Scenario-Based Integration Testing Platform for Microservices Kenta Moriさん メルペイはマイクロサービスアーキテクチャ Pros - Better maintainabillity, testability, deployability - Scalabiliity - リソース観点 - Improved fault isolation - 障害の影響が小さく、限定される - Eliminate technology lock-in Cons - Complex communication - Debugging problems can be harder - 複数サービスにまたがるデバッグの難易度が高い - Deployment challengers - 機能によって調整や前提がが必要だったりする - Global testing is difficult - 複数のサービスを使うテストは難しい 今日は Global Testing の 話 で特に以下の分類での Integration Test や End-to-end Test Microservices Testing Strategies - Unit Test - テスト可能な最小単位のコードテスト - e.g. Go test - Component Test - テスト範囲を1つのサービスに限定したテスト - 外部依存は on memory db や Stub, Mock を利用 - e.g. Go test (Mock や Stub を利用) - Contract Test - Consumer が期待している仕様を満たしているかを確認する - 実際に依存してるサービスから受け取るということをテストする - e.g. Pact + Schema-first development - Integration Test - 実際に外部との通信なども含めた上でテストを行う - 外部サービスの状態なども考慮したテストを行うのでシナリオの検討も難しい - e.g. Postman - End-to-End Test - ユーザーが実際に使うような環境でのテスト - e.g. Appium, XCUITest, Cypress, 手動 自動 Integration Test の仕組み ![image](https://gyazo.com/5da1e6a4a89a3591ef5c87b31d15608e/thumb/1000) # 感想