解約日と締め日が重なる契約へ、翌月分の料金が請求される
解約日と締め日が重なる契約で、状態遷移の処理順が設計書と異なると、解約済みの契約へ翌月分の課金要求が送信されます。契約者の申告で判明します。
GENZ, Inc.
GENZの第三者検証
サブスクリプション管理システムを
GENZの第三者検証
サブスクリプション管理システムを第三者の視点で検証します
検証範囲の定義とテスト設計の起点から引き受けます。課金・契約遷移・会計連携までを対象に、リリース判断の材料となる報告書を提供します。
支援事例
支援実績5,000件以上
サブスクリプション管理システムでよくある不具合
サブスクリプション管理システムでは、契約状態の遷移と日付の境界値が重なる条件で不具合が表面化します。単体の計算では正しく見えるため設計段階では検出されず、初回の課金サイクルで請求誤りとして現れます。
解約日と
プラン変更時の日割り計算で、計算順序の違いにより請求金額が一致しない
端数処理をどの段階に置くかで結果が変わります。料金表とDB設計書で計算順序の定義が一致していないと、特定の変更日でのみ請求金額が合いません。
決済のタイムアウト後に課金要求が再送され、同一月に二重で課金される
決済代行との通信がタイムアウトした際、再送制御の不備で課金要求が二重に送信されます。異常系の応答を発生させる手段がないと本番で表面化します。
再開後の課金期間に休会分が含まれる
休会から再開した契約で、課金期間の起算日の定義が実装と一致していないと、休会中の日数を含んだ金額が請求されます。遷移の検証漏れで発生します。
月次バッチが締めに間に合わず会計へ連携されない
契約件数の増加で月次バッチの処理時間が伸びると、締め時刻までに請求データが確定せず、会計システムへの連携が翌月へ持ち越されます。
残存した不具合により生じる問題
課金の誤りがリリース後に表面化すると、請求の訂正は契約者対応と経理処理の両方へ広がります。次の締め処理までに終えなければ翌月へ持ち越されます。
静的テスト（レビュー）でおさえるべき観点
実行前の文書同士を照合するのが静的テストです。料金規定・画面仕様・API定義・会計連携・バッチ運用の各対で、設計段階の解釈差をレビューで検出する観点を整理します。
端数処理の解釈差が残ると、特定の日付条件でのみ請求金額が合わない不具合がリリース後の初回課金で表面化し、返金と再請求が手作業での対応となるおそれがあります。
料金規定と設計書の金額定義を照合する
日割り・按分計算の計算順序と端数処理の定義が、業務側の料金表とDB設計書で一致しているかを逐条で照合します。単体の計算結果は正しく見えるため、丸め位置と適用順を文面で突き合わせます。
確認する資料
- 料金規定
- DB設計書
- 画面仕様書
遷移条件の不一致が残ると、休会中の課金や解約後の再請求といった契約状態と請求の不整合が起き、サポート部門への申告が増えるおそれがあります。
契約状態の遷移図と、画面仕様の操作可否の条件を照合する
プラン変更・休会・解約の遷移が、画面仕様上の操作可否の条件と対応しているかを照合します。遷移図で許可された状態移動が、画面のボタン表示や入力制御の条件分岐に反映されているかを確認します。
確認する資料
- 状態遷移図
- 画面仕様書
- 要件定義書
応答コードの分岐漏れが残ると、与信失敗時の課金漏れや二重課金が検知できず、売上計上の訂正と契約者への個別説明が必要になるおそれがあります。
決済代行のAPI定義と、自社の応答コード分岐の設計記述を照合する
決済代行のAPI定義の応答コードと、自社側の設計記述にある分岐処理を照合します。与信失敗・二重課金・再送の各コードに対し、例外処理とエラー発生パターンの記述が欠けていないかを確認します。
確認する資料
- API定義
- 基本設計書
- 詳細設計書
会計連携の項目差異が残ると、仕訳一覧の訂正が月次・年次の決算作業へ波及し、内部統制の評価で指摘を受ける材料になるおそれがあります。
会計システムの受け入れ仕様と売上計上データ設計を照合する
会計システムの受け入れ仕様が求める項目と粒度が、請求データから売上計上へ渡す設計に含まれているかを照合します。連携方式がファイルかAPIかで手順が変わるため、仕訳一覧の単位まで照合します。
確認する資料
- 受け入れ仕様
- 連携設計書
- 要件定義書
締め時刻や再実行手順の不一致が残ると、月次バッチが件数増加後に処理時間へ収まらず、課金処理の遅延や二重実行が発生するおそれがあります。
締め時刻・再実行手順の運用規定と、バッチ処理の設計記述を照合する
締め時刻・課金日の定義と、夜間バッチの再実行手順が、運用規定と設計記述で一致しているかを照合します。月末日のない月をまたぐ条件や処理時間の見込みが記述されているかを確認します。
確認する資料
- 運用規定
- 運用設計書
- バッチ設計書
- 詳細設計書
動的テストの設計・実行のポイント
サブスクリプション管理システムのテストは、課金計算・状態遷移・外部連携の単位で段階に分け、確認対象を明示します。
STEP 01
ユニットテスト境界値分析と同値分割で項目を設計します
どう確かめるか
料金計算と状態遷移の単位で、境界値分析と同値分割によりユニットテストを設計する
日割り・按分の計算順序と端数処理を料金表とDB設計書で照合し、プラン変更・休会・解約の状態遷移と日付の境界値の組み合わせへ展開します。単体では正しく見える定義差を表面化させます。
- 01料金表とDB設計書の計算順序・端数処理の定義を照合します
- 02日付の境界値と契約状態遷移の組み合わせを項目化します
- 03計算結果の期待値を業務側の条件から導出します
OUTPUTテスト項目書
STEP 02
統合テスト異常系を含めて連携先と突合します
どう確かめるか
決済代行・会計システム連携を異常系も含む統合テストで検証する
決済代行サービスとの与信失敗・二重課金・再送、会計システムへの請求データ連携を、正常系だけでなく例外処理とエラー発生パターンまで含めて検証し、売上計上と仕訳一覧の整合を確認します。
- 01与信失敗・二重課金・再送の例外処理を発生させて検証します
- 02請求データと売上計上・仕訳一覧の整合を確認します
- 03連携先のテスト環境の範囲を事前に確定します
OUTPUT不具合票と追跡一覧
STEP 03
システムテスト締め日をまたぐ業務シナリオで流します
どう確かめるか
申込から月次課金・会計連携までを、締め日をまたぐシナリオでシステムテストする
申込・プラン変更・休会・解約から月次課金・会計連携までを、締め日をまたぐ一連の業務シナリオとして流し、遷移の組み合わせで請求金額が一致することを実運用に近い条件で確認します。
- 01申込から解約までの遷移を締め日をまたいで流します
- 02プラン変更・休会を含む請求金額の一致を確認します
- 03決済連携から会計連携までの終始を通しで検証します
OUTPUTテスト結果報告書
STEP 04
パフォーマンステストと回帰テスト件数増加時の処理時間と修正影響を確認します
どう確かめるか
契約件数を増やしたパフォーマンステストと、修正反映後の回帰テストを実施する
契約件数を増やした条件で月次バッチの処理時間を測定し、締め時刻へ収まることを確認します。不具合修正後は影響範囲を特定して回帰テストの範囲を決め、既存機能への波及を検証します。
- 01契約件数を増やした条件で月次バッチを実行します
- 02処理時間が締め時刻に収まることを測定します
- 03修正の影響範囲を特定して回帰テストを実施します
OUTPUT回帰テスト範囲の根拠資料
GENZが代行するテストの種類
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 締め日・課金日・解約日の境界値を組み合わせ技法で検証します
- プラン変更・休会・解約の遷移を含む回帰テストの範囲を定義します
- 与信失敗・二重課金・再送を発生させて決済連携を検証します
- 請求データと会計システムの売上計上・仕訳一覧を突合します
テスト設計の起点から引き受ける第三者検証
どの組み合わせを残すかを決めるテスト設計そのものが詰まりの起点にあります。GENZは検証範囲の定義から実行・報告までを第三者の視点で担い、リリース判断の材料として提出できる水準で納品します。
料金と契約の整理からテスト設計へ
締め日・課金日・解約日の境界値と契約状態の遷移の組み合わせを整理し、日割り計算の計算順序と端数処理まで含めて検証範囲を定義します。
外部連携の境界まで検証範囲に含める
決済代行との与信失敗・二重課金・再送の例外処理と、会計システムへの売上計上と仕訳一覧の突合まで検証範囲に含めます。
既存の体制と運用を保ったまま検証を足す
開発ベンダーとの進捗会議や既存のテスト項目書の運用を置き換えず、スプリントと並行して検証の層だけを追加する形で伴走します。
判断材料として使える報告書と証跡を納品
検証範囲・実施結果・残存不具合を部門会議へ提出できる形式の報告書として納品し、監査対応で参照できる証跡の管理まで支援範囲に含めます。
ご相談から納品までの流れ
サブスクリプション管理システムの検証は、初回のヒアリングから報告書の納品まで段階を分けて進めます。
ヒアリング
料金体系・契約状態の遷移・連携方式を聞き取り、検証の対象範囲を整理します。
テスト設計と見積もり
境界値と契約状態の遷移からテスト設計し、検証範囲と必要工数を提示します。
テストの実施と結果の共有
テスト項目書にもとづき検証を実施し、不整合を不具合票として起票します。
報告書の納品と修正後の再確認
検証範囲・実施結果・残存不具合を報告書にまとめ、修正後の再確認も担います。
ご検討中の企業様へ
サブスクリプション管理システムの検証範囲と優先順位をGENZへご相談ください
テスト設計の起点から第三者の視点で引き受け、検証範囲の定義とテスト項目書を成果物としてお渡しします。ご相談では、検証範囲の切り方と優先順位、必要工数の考え方をお示しします。