EXPERT RESPONSE
You need to approach your testing of the payment gateway much like you would any other feature -- by documenting (and getting buy-in on) a concise test strategy. A search of Google for "Test plan" or "Test spec" will produce several templates that can drive your strategy, but here are some key points to consider:
- Functionality: This is the act of testing base functionality. Does the gateway do what it is supposed to do? Does it handle order objects correctly? Does it perform additional calculations correctly? (For instance, if the gateway will be run in a country with a VAT added at payment time, is that calculated correctly?)
- Integration: Next, you need to test integration with your credit-card service. This could arguably be clubbed with the functionality testing, but to me it's sufficiently important that it deserves its own category. Don't just focus on "positive cases" here. It's important to the company that it bill (and be reimbursed) for the right amount, but it's also critical that every possible billing error be handled appropriately by the gateway. You need to do this testing with a clear definition of the card payment system in-hand.
- Security: Next, you have to perform a deep security pass. Of course you want to look for things like buffer overruns. But today's hacker is generally more sophisticated than that, and you need to test accordingly. Searching for "security testing" or "security hacks" will yield much. Some blogs to consider: Google Online Security Blog, Michael Howard's Web Log, Microsoft's Security Development Center. SearchSoftwareQuality.com also has several articles and expert advice on application security testing.
- Performance: You need to work with your internal customers to identify performance metrics, such as the highest possible number of people who might be coming through the gateway on a given day, and translate that down to highest possible number of concurrent users. Microsoft just released a fantastic guide on testing performance, Performance Testing Guidance for Web Applications.
|
|
 |
That's just a start. A good test plan is the foundation to your project. Once you have completed your plan and achieved buy-in, you need to author test cases. Finally, the rubber hits the road on execution. But the test plan is the start -- it should guide your entire project. Focus on authoring a good test plan specific to your project and needs, and the rest will fall in place.
|
