課金システムのテスト設計に必要な観点を考えてみた

こんにちは、テストエンジニアの ナカノ です。私は以前、とあるプロジェクトで「お金に関するシステム」に関するテスト設計・実施を行う機会がありました。

「課金 ＝ お金」というわたしたちの日常生活に密接に関わるモノのシステムにおいて不具合が発生してしまった場合、ユーザーに対する損失は多大なる影響を与えることになります。そのため、一般的なシステムに加えて様々な状況やリスク等を考慮しながらテスト設計を行う必要があると感じました。そういった経験を基に、今回は「お金に関するシステム」においてテストで使用できるような観点を考えてみました。

※今回ご紹介するケースはあくまで1つの事例・観点であり、全てのカバレッジを網羅するわけではありませんが、少しでも参考にしていただけたらと思います。

お金に関するシステムとは？

はじめに、今回のメインテーマである「お金に関するシステム」についてどのようなものがあるか、一例をご紹介したいと思います。

1. オンライン決済システム：Eコマースや店舗での支払い等、Webシステムやアプリで決済を行うシステム
2. 金融機関システム　　　：金融機関（銀行・証券・保険）が利用する業務システム
3. 資産運用システム　　　：AI等を利用して資産運用を取り扱うシステム
4. 仮想通貨取引システム　：金融機関を介さずに仮想通貨の取引を行うためのシステム

上記で挙げたものの中では特に「オンライン決済システム」がもっとも身近に感じられるシステムなのではないでしょうか。最近はお店でのタッチ決済やネットショッピングなど、モノやサービスの購入をオンライン上で済ませることが当たり前の時代となり、またシステムの需要も増えてきました。本記事では、そういったオンライン決済システムの中でも「課金システム」や「決済」についてピックアップして、テストの観点をご紹介していきたいと思います。

汎用的なテスト観点について

まずはじめに大前提として、他のシステムテストなどでも共通と言える汎用的なテスト観点を挙げてみます。

• 汎用的なテスト観点例）
  • 表示　　　　：仕様通りの文言やアイテム等が適切に表示されているかを確認する
  • レイアウト　：レイアウト崩れ等が発生せず適切に描画されているかを確認する
  • 入力　　　　：テキストボックスやテキストエリア等に文字列が入力できることを確認する
  • 画面遷移　　：仕様通りに各ページ等に画面遷移できるかを確認する

挙げればキリがないので他は割愛しますが、このような汎用的なテスト観点はどのようなシステムにおいても重要な確認項目となります。

数値のバリデーション観点について

次に数値のバリデーションについてご紹介します。課金システムや決済システムでは、「お金＝数値」を入出力する機能が想定されるため、「バリデーション（入力値が正しい形式や範囲に合致しているか）」もとても重要な観点となります。

• 「数字」に関するバリデーション観点例）
  • 小数点あり　：100.1、0.1234　など
  • 記号あり　　：+100、-1234　など
  • 指数表記　　：1e2 (=100)、1e12 (=1,000,000,000,000)　など

また、半角数字以外を入力したときの挙動を確認する観点も考慮する必要があります。

• 「文字」に関するバリデーション観点例）
  • 全角数値　　　　　：１２３４５　など
  • 数値以外の文字種　：ひらがな・カタカナ・漢字・アルファベット・記号　など

数値の入力が可能なシステムの場合、「境界値」に不具合が潜んでいる可能性が高いため、値の有効・無効の範囲を確かめる観点も重要なポイントとなります。

• 「境界値」に関するバリデーション観点例）
  • 最小値の境界値　　：最小有効値の境界値、最小無効値の境界値　など
  • 最大値の境界値　　：最大有効値の境界値、最大無効値の境界値　など

境界値分析については、こちらの『「境界値分析」をテスト設計に取り入れる』でも紹介しているので、ご興味がある方は是非読んでみてください！

以上が数値に関する観点の一例のご紹介となります。他にもシステムの仕様や条件によって様々な要素や観点の考慮が必要なため、実際の作業では仕様やテスト条件を見逃さないように、十分注意してテスト設計を行う必要があります。

課金システム特有のテスト観点について

続いて、「課金システム」特有のテスト観点について考えてみます。課金システムでは、テスト対象となるシステムの仕様によって課金に関する各機能の実装が異なるため、本記事ではいくつかの代表的な機能をピックアップしてテスト観点をご紹介します。

クレジットカード決済

Eコマースサイト等の課金システムの場合、ほとんどの機能仕様としてクレジットカード払い、コンビニ払い、口座振替といった「決済方法」が選択できるようになっているかと思います。本記事ではその中でも決済代行システムを利用した「クレジットカード」について、観点を検討してみました。

対象の課金システムが決済代行システム（ECサイト等の運営と決済機関との間で第三者が決済を仲介するシステム）を利用している場合、「テスト専用のカード」を使用して架空のデータで決済処理を行ってテストすることができる場合があります（実際に決済は行われません）。通常、テスト専用のカードのデータとしては、①正常に決済できるカード と ②決済処理を作為的に失敗させるカード の2種類あります。さらに、①正常に決済できるカードには、「カードブランド」の種別（基本的には国際的な5ブランドなど）や「カード属性」として「デビッドカード」や「プリペイドカード」などの種類があります。一方、②決済処理を作為的に失敗させるカードには、エラーの種別として「残高不足」や「限度額オーバー」といったデータが用意されていることがあります。

• クレジットカードの因子例）
  • 決済に成功するケース：
    • カード種別　　　　　：国際的な5ブランド、デビットカード、プリペイドカード、海外発行カード　など
    • セキュリティコード　：4桁、3桁
    • 名前の文字列長　　　：有効桁数最小、有効桁数中間、有効桁数最大　など
    • 有効期限　　　　　　：最短期限、中間期限、最長期限　など
  • 決済に失敗するケース：
    • エラー種別　　　　　：残高不足、限度額オーバー、取扱不可　など

クレジットカードの条件の注記

例えば、上記記載の「決済に成功するケース」のようなパターンについては、システムの特徴やテストの規模感等を考慮したうえで、「全網羅」とするのか「水準網羅」とするのかといった、どのような条件でテストを行うのかをテスト設計段階でステークホルダーや開発側と協議して合意を形成したうえで決定する必要があります。

• クレジットカードの因子例を基にした因子・水準リスト

• 因子・水準リストを基にした全網羅のパターン例

すべてのパターンをテストケース化する「全網羅」でテストしようとした場合、8 × 2 × 3 × 3 = 144パターンとなるため、テストケース数は大きく増加します。全パターンの組み合わせで確認できるため、ケースの抜け漏れなどは防ぐことができますが、その分テストに必要な工数が膨らむ傾向があります。

• 因子と水準を基にした水準網羅のパターン例

１つの水準に対して最低限１回は確認を行う「水準網羅」の場合は、「全網羅」ほどの複雑な組み合わせは確認できませんが、例えばシステムの特性として任意の組み合わせで確認できればよいといった条件の粒度感が提示されているのであれば、比較的有効となる確認方法となります。

課金方法種別と残高

課金方法種別について

課金システムにおける課金方法では、主に「都度課金」と「継続課金」が挙げられます。「都度課金」では商品やサービスの決済ごとにその都度課金する方法に対して、「継続課金」ではサブスクリプションシステムの月額使用料などに代表される設定された金額が毎月決められた日に課金される課金方法となります。各課金方法に関するテストについては、対象システムの仕様に即した各機能が動作するか（都度課金であれば決済時に毎回課金する方式となっているか、継続課金では決済時は課金せず決済日に引き落とされるか　など）といった単体的な機能の確認に関するテストが有効となるでしょう。

残高について

課金システムでは、事前にチャージされているお金やポイントを「残高」として取り扱い、そこから決済を行う機能仕様が備わっている場合があります。残高は決済前後の状態が重要なポイントとなるため、以下のような観点を抽出すると有効な確認となるでしょう。

• 都度課金時の決済金額と残高の関係に着目したバリデーション例）
  • 決済金額 ＜ 残高（決済できるか／決済後の残高情報が適切か）
  • 決済金額 ＝ 残高（決済できるか／決済後の残高情報が適切か）
  • 決済金額 ＞ 残高
    • 決済可能な額を追加で課金（決済できないか／決済後の残高情報が適切か）
    • 決済のキャンセル（決済できるか／決済後の残高情報が適切か）

継続課金であっても同様に、設定された決済日に対して自動で課金額が引き落とされるシステムとなるため、決済日当日に上記観点を応用することができます。

年齢による課金額制限

システムによっては、使用するアカウントの年齢に対して課金できる金額の上限が定められている場合があるため、年齢や金額の境界値等の仕様を十分に確認し、テスト設計を行う必要があります。仕様を整理するためには、以下のようなデシジョンテーブルが有効となるでしょう。

• 課金額制限の仕様例）
  • 15歳までは月額で課金できる上限金額を 5,000円 までとする
  • 16歳から19歳までは月額で課金できる上限金額を 20,000円 までとする
  • 20歳以上は上限金額なし とする

• 上記仕様を基にしたデシジョンテーブル例

デシジョンテーブルについては、『いまさらデシジョンテーブルというものを考えてみた』でも解説されています。こちらもご興味がある方は是非読んでいただければと思います！

決済タイミングとステータス

近年、市場はクレジットカードやスマホから決済を利用するようなシステムにおいて、二重決済（システム上の欠陥等により同じ金額が２回決済されてしまう現象）などのトラブルが発生する事例が増えてきました。原因としては、システム側で請求したはずの履歴がないために再請求が行われるケース（システム間の連携不備）や、注文時と商品発送時などで送信されるデータがそれぞれ2回分決済されてしまうといったケースがあるようです。そのため、課金システムにおいても決済を行うときのタイミングやそのときの各ステータスの変化に着目するような観点は重要なポイントとなります。例えば、決済時のアイテムやコンポーネント間での確認であれば「機能テスト」が、決済処理とそのステータスといった各処理の連携に関する確認であれば「状態遷移テスト（または画面遷移表や状態遷移図を用いたテスト設計）」がそれぞれ有効なテストとなるでしょう。

• 機能テストの観点例）
  • 正常系：
    • 決済処理を行ったとき、関連するステータスが適切に変化するか
    • 決済処理を行ったとき、関連する履歴が適切に反映されるか
    • フロントシステムから決済処理を行ったとき、バックエンドシステムや基幹システムなどに決済した情報が適切に受け渡されるか
  • 異常・特殊操作系：
    • 同時処理（複数ブラウザ等から同タイミングで決済したとき二重決済されないか）
    • 割込処理（決済処理中などで別の決済情報が割り込みしたとき各決済が適切に処理されるか）
    • 連続操作（決済を確定するボタンを連打したとき二重決済されないか）

※上記で記載している当該処理・操作時の期待結果はあくまで想定で記載しているため、実際のテスト設計時は対象システムの仕様を考慮する必要があります。

• 状態遷移テスト例）
  • 決済に関する各ステータスの仕様例
    • 仮売上： 決済が完了して注文が入った状態
    • 処理中： 売上処理・キャンセル処理を行っている状態
    • 決済完了： 実売上処理が正常に完了した状態
    • 決済失敗： エラーが発生して決済処理が失敗した状態
    • キャンセル： ユーザーが注文のキャンセルを行った状態

• 上記仕様を基にした状態遷移図例

状態遷移図については、『幅広いソフトウェアとテストレベルで適用可能な状態遷移テスト』にて解説されているため、詳しい内容はこちらでご確認いただけます！

その他の機能

その他に、例えば「ポイント」を付与・利用できるような機能や、「クーポン」に対応しているような機能があれば、課金額への影響に関するテスト観点や今回ご紹介した「残高について」周りのテスト観点をかけ合わせてテスト設計を行うと有効となる場合があります。その他にもテスト対象となる課金システムによって様々な機能やサービスがあるため、各機能仕様やテスト条件、テスト環境やテストの規模感などに応じて、適切なテスト設計を行う必要があることを忘れてはいけません。

おわりに

冒頭の「お金に関するシステムとは？」でも述べた通り、近年ではオンライン決済等、お金を扱うシステムが増えてきました。一方で、そのようなお金に関するソフトウェアが正しく動作しないと、経済的な損失、時間の浪費、信用の失墜など企業やユーザーにとって生活レベルで重篤な問題が発生する可能性があります。そのため、テスト設計者は仕様通りに動作することはもちろんのこと、仕様通りの動きが妥当か、ユーザーの様々な利用シーンを考慮できているかなど、開発視点とユーザー視点の両方からテストを考えることが品質保証にとって重要なポイントとなります。仕様やリスクを深く理解し、様々な状況を想定してテストを設計していきたいと改めて感じました。今回の記事が少しでも参考になれば幸いです。