Software testers have developed their own language. Their use of specialized terms and jargon has become second nature and most testers don’t realize that to those outside of their trained circle, their conversations might as well be in Dutch.
Taking the analogy a step further, electronic payments testers have developed their own dialect, modifying the meaning of certain terms to the point that their dialogue may sound like an impenetrable accent to, say, logistics software testers. It reminds me of the old Steve Martin joke: “Those French – it’s like they have a different word for everything.”
In an effort to demystify this space, Paragon has prepared a white paper, “Electronic Payments Testing: A Testing Terminology Primer,” that outlines the sequential steps of the testing process. The tables provided in this white paper are worth laminating and carrying in your pocket, much as you would a phrasebook while strolling the streets of a foreign capital.
The paper details roles, responsibilities and testing scenarios. Here’s a brief overview of the primary types of testing described in the white paper. As you will see, by providing these general descriptions, Paragon provides a helpful “translation” of what is being accomplished with each type of testing.
Unit Testing is the most fundamental form of testing and is typically performed by the developers themselves (or in certain cases by Quality Assurance testers). The objective is to test the smallest piece (or unit) of isolated code before folding it into the broader application. Identifying bugs at this stage makes them significantly less costly to remedy. Unit testing is required each time there is a change to the code.
Integrated Testing follows unit testing and focuses on what’s created when units of code are strung together. Assuming all unit testing has already been successfully completed, the goal of this stage is to confirm that the various payments interfaces and interactions between code packets are performing properly. Integrated testing should be performed in multiple passes each time a new unit of code is incorporated and may be approached in a variety of sequences, e.g., top-down or bottom-up.
Functional Testing involves taking on the perspective of the end user, confirming that the software works in accordance with the design specs as well as industry standards. This step becomes particularly important whenever a new payments feature is added, but it is essential each time changes are made to the payments system. The group of potential testers expands in this stage as well – it may still involve developers, but more likely QA testers, system testers and acceptance testers.
As its name implies, Regression Testing looks back to the pre-existing code to confirm that these new additions have not introduced any bugs. This type of testing is primarily done by QA testers. The process is run twice – first using the existing code to set a baseline, then with the updated code to ensure consistent performance.
Once these hurdles have been cleared, System Testing verifies that all continues to go as planned under various hardware configurations. Components related to communication, networks, backup and disaster recovery must be considered. There are some potential “gotchas” embedded in this step, as payments system testing is often required even if the code hasn’t changed to validate changes in router configurations, database structures, etc. It’s easy to envision issues emerging because someone who is making a minor tweak to an existing piece of equipment may not consider the cascading effects it could have. Also, residing within this category is the all-important stress and performance testing, ensuring acceptable payments system response times under volume spike scenarios.
Acceptance Testing represents the point where a new payments product is set loose “into the wild.” As such, it typically involves clients as well as internal acceptance testers. Alpha and Beta field tests fall under this banner. The purpose of this type of testing is to confirm that the end user can successfully access and utilize the new features. In cases of custom development, this also doubles as the process by which the client signs off on receipt of the agreed deliverable.
From a payments perspective, system testing in particular demonstrates the headaches and risks of relying on manual testing processes. Consider the countless permutations of ATM hardware providers, plastic card (and handset) manufacturers and communications protocols over which a solution must run – at the bank, end user and processor sites – not to mention the endless parade of minor adjustments to databases and routers that could possible carry broader implications.
And with people’s money at stake, accuracy and system availability are hardly negotiable. That is why many organizations are implementing automated payment testing solutions that decrease the risks and inefficiencies created by manual processes.
To learn more about testing terminology as it applies to these types of testing, download our white paper, “Electronic Payments Testing: A Testing Terminology Primer.”