Black box testing of financial transactions tests system input and output without examining the internal code. While this may seem simple to some people in your organization, if the financial transaction testing only focuses on whether a product works “correctly” after a change is made, then it has failed to address one of the most important aspects of black box testing. That aspect is verifying that the change makes sense to your users. All too often, users become an organization’s de facto black box testers – and sadly, the new feature fails their tests.
Here are some ways to improve your approach to black box testing to avoid the pitfalls of what is too often business as usual. For a more comprehensive list of ways to test financial transactions, download our white paper, “10 Steps Toward Better Black Box Testing.”
Wear your “user hat”
Good testers assume a variety of roles and, in black box testing, their most important role is that of a “typical user.” This role is one case in which less is truly more – that is, less knowledge of the code may mean the tester can make a more objective evaluation. In fact, black box testing should include random input, unconventional system navigation and deliberate entry of unacceptable data to verify the system’s response.
Most features are added in response to a user need. Does this change really give users what they want? Good black box testing requires an in-depth knowledge of the user and an understanding of the user’s needs. Without that affinity for the user, the tester can only ensure that the code does what the developer expects it to do, rather than verify that it actually meets the user’s needs.
Strive for simplicity
For the typical user, easy-to-use features are easy-to-love features. How complex is the feature? Is it designed for power users only, or is it available to all users? The more accessible the feature is, and the more straightforward its operation, the more likely your users are to incorporate its use into their routine.
Looks aren’t everything, but they do matter. Is the screen design attractive? Does it seem overly busy? Is the new feature hidden, or easy to find? Are fonts too large or too small? Is the color palette suitable? Overly busy screens hide new fields and features, making them difficult for users to find.
Despite the sometimes adversarial relationship between developers and testers, they do share a common goal: produce the best product in the least amount of time. As a tester, you are charged with giving each new feature the final stamp of approval. In essence, by thoroughly evaluating the usability and performance of the feature, you guarantee that everyone involved successfully reaches their goals. Take pride in the important role you play in your institution’s success.