2024年12月17日 JaSST nano vol.43 すなかわ コドモンの決済基盤のテストの紹介

2 ● コドモンについて ● 決済基盤の紹介 ● 決済基盤のテスト戦略 ● まとめ ● 最後に AGENDA

自己紹介

4 ● 名前　すなかわ / ミジンコおじさん (X: koppamijinko) ● 経歴 2014 〜 2018 大学受験予備校のチューター 2018 〜 2023 第三者検証会社 2023 〜 コドモン ● 趣味 野球観戦、映画、旅行 ● 好きなテスト技法 デシジョンテーブルテスト ● プライベートでは二児の父（男女の双子）

コドモンについて

6 Mission

7 すべての先生に 子どもと向き合う 時間と心のゆとりを こんなプロダクトを開発しています メインプロダクトは、保育・教育施設向けWebアプリケーション。 保護者と施設のやり取りを支えるモバイルアプリケーションや、施設職員向けモバイル版 アプリケーション、外部サービスと連携するAPIなども開発しています。

8

最初に

10 今回のスコープ テスト 分析 テスト 設計 テスト 実装 テスト 実行 主にここで、 一部設計や実装の話 ※自動テストの詳細や実行した結果等は、対象外となります。

決済基盤の紹介

12 決済基盤の紹介 ● 決済基盤に関して ○ コドモンのプロダクトのうち、集金業務のキャッシュレス化を 支える機能 ○ 現在は、クレジットカード決済とコンビニ決済を取り揃えてい る

13 決済基盤の紹介 ● 処理のイメージ 帽子、クレヨン、カバ ン(10,000円)を クレジットで！ 10,000円 クレジット / 一括 10,000円 クレジット / 一括

決済基盤のテスト戦略

15 決済基盤に対するテスト対象分析 ● 基本機能から見た注意するところ ○ 各サービス(用品販売やいつでも請求)からの決済リクエストを 受け付けて、決済代行業者に連携している ○ 実際にユーザーが決済するまでに様々なサービスの結合部分を 意識する必要がある ● 特に怖いリスク ○ 金銭を扱うプロダクト かつ 結合部分の齟齬が起きた時の損害が ダイレクトに信用失墜に繋がる ○ 決済代行業者は、コドモンがハンドリングできない範疇にいる ため、外部起因のデグレードの可能性がありうる

16 テスト対象分析 → テスト戦略 1. テストレベルが上がるごとに結合部分を増やしていく 例) Unit Test ではBackendの関数やクラス単位でのテスト Integration Test では In / Out を意識した機能検証 2. Integration Test において、プロセス間結合外の世界はモックを準 備し、自動テストにおいて挙動の確認を行う 3. 決済基盤 ＋ 決済代行業者の結合部分は、決済代行業者のテスト環 境と接続した状態での結合試験も準備し、自動テストを行う 4. System Test は、ハッピーパスの自動テストに加えて、マニュアル テストも実施。必要に応じて、非機能テストも実施 5. 本番環境でも実際の決済ができるかをチェックする

17 機能テストのテストレベルの範囲に関して

18 特に重視したのはIntegration Test ● 決済基盤が公開しているAPIの機能担保 ● 決済基盤＋決済代行業者の結合部分の機能担保 ● サービスを全て繋げた時の業務フローの確認(System Test) ☆自動テストで準備することで、機能担保し続けることができる

19 決済基盤が公開しているAPIの機能担保 ● テストの目的 ○ 正常系のパラメータのパターンや 順序、タイミングを考慮した準正常系の機能担保 ● 受け付けているリクエストのパラメータもさまざま ○ 決済手段 ■ クレジットカード ■ コンビニ決済 ○ 金額 ○ 施設ID（決済代行業者の審査通過済でないと決済不可） など

20 決済基盤が公開しているAPIの機能担保 ● 図にするとこんな感じ ● アサートする対象 ○ HTTP Status Code ○ Response Body の値 / (準正常系の場合) Error Code ○ 決済基盤DB のカラム値

21 決済基盤＋決済代行業者の結合部分の機能担保 ● テストの目的 ○ 決済基盤のCUJ(クリティカルユーザージャーニー)となるフ ローが決済代行業者の変更によって守れなくなることはないか ということを検知したい そのため、決済基盤単体のIntegration Testではモックとして いた決済代行業者もテスト環境(または 本番環境)に繋いで実施 ○ 決済ネットワークにおける様々なエラーのエラーハンドリング はあえてテスト内容から除外した（重要なエラーコードは単体 のIntegration Testでカバー）

22 決済基盤が公開しているAPIの機能担保 ● 図にするとこんな感じ(赤いところをアサート) ● 決済データが作られてからの状態遷移を1スイッチカバレッジが 100％になるように作成 ● テスト完了後の決済データの後続処理の確認

23 サービスを全て繋げた時の業務フローの確認(System Test) ● テストの目的 ○ QAエンジニアやエンジニアの観点だけでなく、 プロダクトマネージャーやデザイナーの観点を取り入れる ○ 方針は下記の通り ■ 業務要件として必要な要件が満たせているか ■ クリティカルな不具合がないかどうか （例：請求金額や請求先の不備 など） ■ 他社との強みとなる機能が正常に動作しているか ● 上記は、ステージング環境で自動テストを行っている

まとめ

25 決済基盤のテスト戦略のまとめ ● 紹介したことのまとめ ○ サービス間をブリッジするサービスとなるので、In / Out にす ごく意識したIntegration Test を準備 ○ 自分たちでコントロールできない決済代行業者に対しては、 決済代行業者の提供している環境と繋いだIntegration Testの 実施をしている ○ 開発に関わるエンジニア以外のビジネスサイドに近い観点も自 動テストで守っている

26 決済基盤のテスト戦略のまとめ ● できていないこともある ○ 用品販売＋決済基盤のテストの自動化 ■ 手動検証で守っている状態 ■ テスト環境構築の都合でまだできていない ■ CDCを組むかはチームで検討中 ○ 負荷試験の定期的な実施 ○ 今は決済基盤と用品販売を同じチームで見ているため、 お互いの仕様に詳しいメンバーで保守ができている ■ 今後チームが別れたり、別のチームが決済基盤を使うと なった時のテスト戦略の見直しが必要になる

最後に

WEBアプリケーションエンジニア ● プロダクトの価値向上のための開発 ○ 新規開発や機能改善 ○ リファクタリング ○ 開発生産性向上 ● 機能単位のリプレイス開発 QAエンジニア ● 品質保証戦略の策定 ● 品質に関する知識・技術の普及推進 ● ソースコード品質向上のためのCI/CDパイプライン構築 ● テスト設計・実装 エンジニアリングマネージャー ● 採用・評価運用の改善の推進 ● 開発ロードマップの議論の推進 ● 開発部全体のプロセス改善の推進 ● 自己組織化の促進 やることの例 やることの例 やることの例 28 色々な職種・役割において仲間を募集中です 採用ページは 右のQRコードから ご確認下さい👉

29 Xやブログで情報発信中！

30 ピックアップブログ

31 ゴールドスポンサーとして 協賛しています！ スポンサーセッションも やりますので、ぜひ 聞いてください！

No content