こんにちは。株式会社UPSIDERのNishidaです。
入社から半年が経ち、現在はProcessorチームでバックエンドの品質保証（QA）に取り組んでいます。
本記事では、UPSIDERの決済インフラを支えるProcessorチームにおけるBackend QAの実践と試行錯誤についてご紹介します。
🔧 Processorチームとは”止まらない決済を支える存在”
まずは、私が所属しているProcessorチームについて簡単にご紹介します。
Processorチームは、UPSIDERのカード決済における「心臓部」にあたる領域を担当しています。
Visaなど外部ネットワークとの連携、不正検知、UXとのバランス、非同期なシステム設計など、非常に多くの要素が絡み合う複雑なチームです。
このチームの大きな特徴は、「止まらないこと」自体がプロダクト品質そのものであるという点です。 そのため、設計や運用においては直感ではなく、データと再現性に基づく高精度な判断が求められます。
🧩 QAとして向き合う課題
Processorチームでは過去にいくつかのインシデントを経験してきました。
その経験をきっかけに、以下のような課題が浮き彫りになりました：
- 異常系パターンへの理解・整理の不足
- テスト観点の網羅性・構造化の不十分さ
- 属人的なテスト設計・運用による検証のばらつき
こうした背景から、現在はリグレッションテストの自動化と再現性のあるQA体制の整備を進めています。
🛠 自動化に向けた具体的な取り組み
現在は、結合テストレベルにおけるリグレッションテスト自動化を中心に整備を進めています。
たとえば、以下のようなパターンを自動化の対象としています。
- 少額／高額の決済パターン
- 決済区分・サービス種別による挙動差
- 特定条件（オプション・時間帯・曜日など）付きの決済処理
- カード種別ごとの正常／異常系パターン（物理・バーチャル・ワンタイムなど）
- 限度額超過・日次／月次制限に関するフロー
- カード状態（未アクティブ・一時停止・期限切れ）での決済可否
- 認証条件の違いに伴う動作差分 など
とくに工夫している点として、上記の「カード状態（未アクティブ・一時停止・期限切れ）での決済可否」の検証では、UI上では見えない決済リクエストの裏側を観察する必要がありました。
実装当初は、それぞれの状態に応じたレスポンスが返ってくれば十分と考えていましたが、実際には想定していた期待値と挙動にわずかなズレがあるケースが見つかりました。
そこで、「レスポンス内容とDBの状態をセットで見る」内部整合性を意識して、観点を入れるようにテストに取り組むようにしています。
これらを整理し、再現性のある構造として落とし込むことで、品質の継続的な担保を可能にする基盤づくりを進めています。
🤝 開発フェーズからの関与も強化中！
QAとしての役割は、テストの実行だけではありません。
現在では、開発初期段階からテスト設計に関わることで、より早い段階での品質リスクの可視化と対処ができるようになってきました。
- 新機能における異常系パターンの洗い出し
- テスト観点のレビュー・体系化
- 実装意図とQA観点のすり合わせ
こうした活動を通じて、チーム全体で品質をつくる文化を根付かせようとしています。
🎯 最後に：Backend QAのやりがいと難しさ
バックエンドQAは、UIや画面だけでは完結しない検証が多いため、ログ、DB、APIレスポンスなど、「裏側のすべて」を観察する力が求められます。
特にProcessorのような領域では、ミスが直接ビジネスインパクトに繋がるため、検証の一つひとつに高い精度が必要です。
それでも、信頼される決済インフラを裏から支えることに大きなやりがいを感じています。
ここまでお読みいただき、ありがとうございました。
この記事を通じて、UPSIDERのQAへの取り組みや、決済を支える裏側に少しでも興味を持っていただければ嬉しいです。
