コドモンの決済基盤のテストの紹介 / Introduction to the Payment Infrastructure Testing of Codmon

Transcript

1. 2024年12月17日 JaSST nano vol.43 すなかわ コドモンの決済基盤のテストの紹介
2. 2 • コドモンについて • 決済基盤の紹介 • 決済基盤のテスト戦略 • まとめ • 最後に AGENDA
3. 自己紹介
4. 4 • 名前　すなかわ / ミジンコおじさん (X: koppamijinko) • 経歴 2014 〜 2018 大学受験予備校のチューター 2018 〜 2023 第三者検証会社 2023 〜 コドモン • 趣味 野球観戦、映画、旅行 • 好きなテスト技法 デシジョンテーブルテスト • プライベートでは二児の父（男女の双子）
5. コドモンについて
6. 6 Mission
7. 7 すべての先生に 子どもと向き合う 時間と心のゆとりを こんなプロダクトを開発しています メインプロダクトは、保育・教育施設向けWebアプリケーション。 保護者と施設のやり取りを支えるモバイルアプリケーションや、施設職員向けモバイル版 アプリケーション、外部サービスと連携するAPIなども開発しています。
9. 最初に
10. 10 今回のスコープ テスト 分析 テスト 設計 テスト 実装 テスト 実行 主にここで、 一部設計や実装の話 ※自動テストの詳細や実行した結果等は、対象外となります。
11. 決済基盤の紹介
12. 12 決済基盤の紹介 • 決済基盤に関して ◦ コドモンのプロダクトのうち、集金業務のキャッシュレス化を 支える機能 ◦ 現在は、クレジットカード決済とコンビニ決済を取り揃えてい る
13. 13 決済基盤の紹介 • 処理のイメージ 帽子、クレヨン、カバ ン(10,000円)を クレジットで！ 10,000円 クレジット / 一括 10,000円 クレジット / 一括
14. 決済基盤のテスト戦略
15. 15 決済基盤に対するテスト対象分析 • 基本機能から見た注意するところ ◦ 各サービス(用品販売やいつでも請求)からの決済リクエストを 受け付けて、決済代行業者に連携している ◦ 実際にユーザーが決済するまでに様々なサービスの結合部分を 意識する必要がある • 特に怖いリスク ◦ 金銭を扱うプロダクト かつ 結合部分の齟齬が起きた時の損害が ダイレクトに信用失墜に繋がる ◦ 決済代行業者は、コドモンがハンドリングできない範疇にいる ため、外部起因のデグレードの可能性がありうる
16. 16 テスト対象分析 → テスト戦略 1. テストレベルが上がるごとに結合部分を増やしていく 例) Unit Test ではBackendの関数やクラス単位でのテスト Integration Test では In / Out を意識した機能検証 2. Integration Test において、プロセス間結合外の世界はモックを準 備し、自動テストにおいて挙動の確認を行う 3. 決済基盤 ＋ 決済代行業者の結合部分は、決済代行業者のテスト環 境と接続した状態での結合試験も準備し、自動テストを行う 4. System Test は、ハッピーパスの自動テストに加えて、マニュアル テストも実施。必要に応じて、非機能テストも実施 5. 本番環境でも実際の決済ができるかをチェックする
17. 17 機能テストのテストレベルの範囲に関して
18. 18 特に重視したのはIntegration Test • 決済基盤が公開しているAPIの機能担保 • 決済基盤＋決済代行業者の結合部分の機能担保 • サービスを全て繋げた時の業務フローの確認(System Test) ☆自動テストで準備することで、機能担保し続けることができる
19. 19 決済基盤が公開しているAPIの機能担保 • テストの目的 ◦ 正常系のパラメータのパターンや 順序、タイミングを考慮した準正常系の機能担保 • 受け付けているリクエストのパラメータもさまざま ◦ 決済手段 ▪ クレジットカード ▪ コンビニ決済 ◦ 金額 ◦ 施設ID（決済代行業者の審査通過済でないと決済不可） など
20. 20 決済基盤が公開しているAPIの機能担保 • 図にするとこんな感じ • アサートする対象 ◦ HTTP Status Code ◦ Response Body の値 / (準正常系の場合) Error Code ◦ 決済基盤DB のカラム値
21. 21 決済基盤＋決済代行業者の結合部分の機能担保 • テストの目的 ◦ 決済基盤のCUJ(クリティカルユーザージャーニー)となるフ ローが決済代行業者の変更によって守れなくなることはないか ということを検知したい そのため、決済基盤単体のIntegration Testではモックとして いた決済代行業者もテスト環境(または 本番環境)に繋いで実施 ◦ 決済ネットワークにおける様々なエラーのエラーハンドリング はあえてテスト内容から除外した（重要なエラーコードは単体 のIntegration Testでカバー）
22. 22 決済基盤が公開しているAPIの機能担保 • 図にするとこんな感じ(赤いところをアサート) • 決済データが作られてからの状態遷移を1スイッチカバレッジが 100％になるように作成 • テスト完了後の決済データの後続処理の確認
23. 23 サービスを全て繋げた時の業務フローの確認(System Test) • テストの目的 ◦ QAエンジニアやエンジニアの観点だけでなく、 プロダクトマネージャーやデザイナーの観点を取り入れる ◦ 方針は下記の通り ▪ 業務要件として必要な要件が満たせているか ▪ クリティカルな不具合がないかどうか （例：請求金額や請求先の不備 など） ▪ 他社との強みとなる機能が正常に動作しているか • 上記は、ステージング環境で自動テストを行っている
24. まとめ
25. 25 決済基盤のテスト戦略のまとめ • 紹介したことのまとめ ◦ サービス間をブリッジするサービスとなるので、In / Out にす ごく意識したIntegration Test を準備 ◦ 自分たちでコントロールできない決済代行業者に対しては、 決済代行業者の提供している環境と繋いだIntegration Testの 実施をしている ◦ 開発に関わるエンジニア以外のビジネスサイドに近い観点も自 動テストで守っている
26. 26 決済基盤のテスト戦略のまとめ • できていないこともある ◦ 用品販売＋決済基盤のテストの自動化 ▪ 手動検証で守っている状態 ▪ テスト環境構築の都合でまだできていない ▪ CDCを組むかはチームで検討中 ◦ 負荷試験の定期的な実施 ◦ 今は決済基盤と用品販売を同じチームで見ているため、 お互いの仕様に詳しいメンバーで保守ができている ▪ 今後チームが別れたり、別のチームが決済基盤を使うと なった時のテスト戦略の見直しが必要になる
27. 最後に
28. WEBアプリケーションエンジニア • プロダクトの価値向上のための開発 ◦ 新規開発や機能改善 ◦ リファクタリング ◦ 開発生産性向上 • 機能単位のリプレイス開発 QAエンジニア • 品質保証戦略の策定 • 品質に関する知識・技術の普及推進 • ソースコード品質向上のためのCI/CDパイプライン構築 • テスト設計・実装 エンジニアリングマネージャー • 採用・評価運用の改善の推進 • 開発ロードマップの議論の推進 • 開発部全体のプロセス改善の推進 • 自己組織化の促進 やることの例 やることの例 やることの例 28 色々な職種・役割において仲間を募集中です 採用ページは 右のQRコードから ご確認下さい👉
29. 29 Xやブログで情報発信中！
30. 30 ピックアップブログ
31. 31 ゴールドスポンサーとして 協賛しています！ スポンサーセッションも やりますので、ぜひ 聞いてください！