支払いシステムのテストケースを管理する

この記事はPeter G Walenによるゲスト投稿です。

あなたの会社が開発し、おそらく利用しているソフトウェアは、他のどんなソフトウェアとも違います。会社の業務と運営に合わせたカスタムソリューションを構築したからです。あなたのソフトウェアは他のソフトウェアとは違います。ただ、残念なことに、テストの問題はあまり変わりばえがしません。

とくに、支払いシステムのテスト管理における問題は共通しています。支払いシステムのテスト管理とは、単にテストケースを定義してJiraやMS ADOやその他のツールに入力するだけではありません。他の分野とは多少異なる考え方が必要で、多くの組織が気にもかけないリスクやリスクへの暴露が重視されます。

あなたのソフトウェアがサードパーティのプロバイダーを利用して支払いを処理しているとしても、自社の問題としてアプローチする必要があります。顧客に影響を与えるような問題が起きたとき、問題がサードパーティの側にあったかどうかなど、顧客は斟酌してくれません。カードや取引の情報が漏洩した場合、ニュースになるのはあなたの会社です。

ビジネスニーズと要件
プロセスを管理する
セキュリティ
テスト
関連する製品
- Java対応静的解析・単体テストツール Jtest
  - 静的解析によるセキュリティ脆弱性などの致命的な問題の検出、単体テストの導入や運用の障壁の除去
- C＃ VB.NET対応静的解析・単体テストツール dotTEST
  - アプリケーション開発のテスト効率化、ソースコードの品質向上を実現

ビジネスニーズと要件

テスト管理は、解決するべきビジネスの問題と、それらのニーズを要件がどのように表現しているかを慎重にレビューすることから始まります。プロジェクトや変更の意図を理解する必要があります。ビジネスケースに存在するギャップを埋める必要があります。それが、期待と定義された要件の間のギャップを埋めるのに役立ちます。

ギャップは必ず存在します。誰もがニーズや現在のシステムの動作を理解しているはずだという思い込みが必ず存在します。しばしば、そういったギャップが開発の終盤になって判明します。ときには、運用が開始されてからギャップが見つかることもあります。

たいていは、パッチでギャップを埋めることができるでしょう。支払いシステムでは、セキュリティ侵害が起きて初めてギャップが判明することが多く、そのときではもう遅いのです。開発サイクルを通じてギャップとリスクを検出する必要があります。

支払いカード処理ソフトウェアの仕事をしていて、予定されたデリバリー期日の一週間前にテストのギャップが見つかったときのことを覚えています。これを契機として、テスト設計のやり方を根本的に刷新することになりました。何もかもが変わりました。

以降、ソフトウェア設計の前にテスト設計が行われるようになりました。デシジョンツリーやマインドマップを作成して要件をテストし、システムの穴を指摘しました。穴は、私たちの発見についての説明と、より明確にしてほしいというリクエストを添えて、ビジネスアナリストに送り返されました。

そのせいで、しばらくの間、セールスチームでのテストチームの評判はよくありませんでした。しかし、すぐにセールスチームも、その後のプロジェクトはより早くデリバリーの準備ができることに気付きました。「設計」が始まる前に、すでに設計の問題が対処されているからです。

プロセスを管理する

問題は、ものごとが当然うまくいくはずだという思い込みであることが往々にしてあります。優秀な開発チーム、あるいはテストチームなら、常に誤りも問題もないものだと信じるのは、人間の性なのでしょう。ニーズと要件の間のギャップは1つの側面にすぎません。

支払いシステムでは、探すべきギャップを知ることが課題になります。テストまわりの「プロセス」を管理することは、テストケースの設計と開発を管理することに通じます。お金が絡む以上、厳密にテストを行う必要があるのは明白です。口座の勘定が一致し、取引はすべて計上される必要があります。

検証対象の支払いシステムの形態からは、もっとあいまいな疑問が生じます。あなたが開発しているのはオンライン店舗向けのシステムでしょうか? オンラインと実店舗の混合の場合はどうでしょうか? 同じ支払い方法を処理できる必要があるでしょうか? どちらかだけで利用できる支払い方法はあるでしょうか? 限度額についてはどうでしょうか? カードや支払い方法に制限がある取引とない取引があるでしょうか?

これらはシステムの「要件」であると同時に、テストでも個別に検討を必要とします。通常、わずかに異なるよく似た手順を繰り返すのは無駄である、すくなくとも不要であるとみなされます。しかし、支払い方法やカードを検証する場合、この繰り返しはまさに必要なものかもしれません。

もう1つ考慮すべき点があります。これはどんな支払いプロセスでも課題となる点です。たいていの金融取引では、お金が正しい口座に振り込まれるよう、即座に取引が勘定されることが期待されますが、支払い取引では、取引自体がどのように処理されるかを精査して将来の問題を防ぐことのほうがより重要かもしれません。

支払い口座情報を含む取引データの格納と追跡から、その情報がどのように転送されるかの監視に至るまで、支払いシステムのテストの中心に存在するべきものが1つあります。それは、あなたの会社がまったく望まないニュースの見出しになる確率を減らすもの、つまりセキュリティです。

セキュリティ

システムのガイドラインとしてOWASPを利用できます。これはスタートとしてとてもすぐれています。すべてのソフトウェア開発グループは、OWASPの指針を意識し、適用するべきです。支払い取引であれば、PCI コンプライアンスは大きな課題です。

OWASPもPCIも、「できれば」や「次のリリースで」で済ませられるものではありません。OWASPについては、多くの人が知っているでしょう。相当数の組織はPCIを気にかけず、ベンダー任せにしています。ただし、支払い処理で問題が発生したとき、顧客が解決と賠償を求めに来るのはあなたのところです。

PCIの要件が意味するものを意識する必要があります。そして、要件をテストする方法を考えます。そして、支払いに関連する領域へのあらゆる変更がPCIに準拠しているかを確実にテストするようにします。

そして、テストを行います。繰り返し、繰り返しテストします。リリースごとにテストが必要です。ビルドごと、というのもよいアイデアですが、「同じ」スクリプトをテストしながら少しずつ異なるシナリオを処理できるしっかりとした自動化フレームワークがなければ、これは膨大な作業になるでしょう。それでも、テストする必要があります。

テスト

このようなテストに反対する人たちが挙げる理由として、リソースを大量に消費する無駄遣いだというものがあります。もちろん大量のリソースを消費するでしょう。それでも、支払いシステムの脆弱性を探すのは無駄遣いでしょうか？そうかもしれません。

私は、システムの侵害がテストよりはるかに高いコストを負わせることにならなかった例を1つも知りません。テストの自動化、特に一般的な脅威のテストを自動化することの意義は、ソフトウェアをより深く探索し、それまで検討されていなかったことを見つける余裕を作る点にあります。発見をテストし、計画に組み込んだら、それも自動化して、他の脆弱性を見つける作業に向かうことができます。

テストしないことによる節約が、テストしないことによるコストを上回った例は1つも思い出せません。弁護費用から、信用の失墜とまではいかなくとも低下の影響まで、コストは法外なものです。

私の経験では、OWASPガイドラインやPCIコンプライアンスの検証を恒常的にテストに組み込むことは、テストチームおよび開発チームのセキュリティ意識を保つのに役立ちます。警戒を怠らないことが、組織全体の目標になります。

その見返りは、ただ、あなたの会社がクレジットカード情報の侵害でニュースになっていないことです。

今のところは。

Peter G. Walenは、ソフトウェア開発、テスト、アジャイルプラクティスで25年以上の経験を持っています。ソフトウェアがどのように動作し、他のソフトウェアと連携するか、またソフトウェアを利用するユーザーをチームが理解できるよう支援に尽くしています。Agile Alliance、Scrum Alliance、American Society for Quality (ASQ)のメンバーであり、ソフトウェアミートアップに熱心に参加し、カンファレンスでもたびたび講演しています。

（この記事は、開発元Gurock社の Blog 「Managing Test Cases for Payment Systems」2021年10月14日の翻訳記事です。）