Software Testing 101 in Fintech world

Software Testing and Software Quality Assurance is evolving from simply clicking to test new functionality to confirm it meets requirements into a more holistic approach that ensures maximum customer experience with the aim of improving the overall expectation of the product.

Software testing for financial services is delicate with various layers of complexity. These financial software solutions handle multiple transactions every second. A single solution integrating with many other applications requires secure transaction processing, reliable storage systems for auditing purposes, to mention a few. For these reasons, the Tester cannot afford to take things lightly.

Here are basic pointers for anyone new to software testing in the FinTech world:

1. Having a good rapport and working relationship with Software Developers is a great determinant of the success of your work. It is a known fact that there is usually tension between these roles. Allow the Developer know that you are not there to rubbish the work done but to improve it. There is no need to employ the “Blame Game” approach. Be respectful, understanding and professional. A well-appreciated developer can mean better reception to review or feedback on work done.

2. Beware of rigidity – don’t be too picky with checks and validations. because the scope and target audience of the product or application might expand in the nearest future. This is not to say you should ignore important pointers and necessary validations.

3. Make error messages very explanatory and ensure HTTP response codes are applicable to the errors. This would help those integrating to your APIs interpret and handle errors better. It would also be very helpful when debugging or trying to resolve issues much later.

4. Be skeptical – don’t bank on the developer’s word. Always confirm fixes yourself. It is not because you doubt the ability of the Software Developer but because you are to champion software quality by achieving comprehensive test coverage and issue resolution.

5. Take time to get a deep knowledge of the system architecture and know the reason for the approach used in developing the product. Endeavor to know the system such that you become a domain expert.

6. Don’t be satisfied with just testing the products on the “surface”. Go beyond testing apps on the user interface alone. You can also use the ‘Inspect Element’ on the browser (Chrome, Opera, Mozilla) to view and analyze the API requests that ‘power’ the front end. Go the extra mile to log into the database to confirm DB entries are populated the way they should. Checking system logs is also a great way to know what’s happening under the hood.

7. It’s very okay to ask many questions. During the sprint planning meetings, don’t be afraid to ask all your ‘silly’ questions. As thorough as the meetings are, don’t be shy to ask more questions afterwards if you need more clarity. You can consult senior QA colleagues, developers that are more experienced or other software architects to clarify your assumptions and thoughts. The art and science of asking questions is the source of all knowledge (Thomas Burger).

8. Are you an introverted techie that just likes to raise bugs behind your screen, update test plans and ensure the developer fixes the bug? Cool. However, you are actually required to do more than that. In order for your role to be visible and appreciated as a contribution to the success of the team, you should try stepping out of your “shell” by making intelligent contributions during meetings. Also, sharing test results with the team, acquainting team members with the current improvements in the tech world regarding the product and tools being used, etc are good ways to be involved. Ability and visibility are two different things.

9. Continuous testing vs automating tests: Automated tests are not to sit lying on the shelf only to be remembered when deploying to production after many releases have been done. Automated tests should be executed with every code build; hence should be integrated into the CI/CD pipeline. This would help provide instant feedback for every application release candidate, by flagging issues early enough. 

10. Bugs may show up on production, which could arise from infrastructure or network issues, oversight when scoping the solution, wrong configuration, poor test coverage or test strategy. This should not be a regular occurrence but there is no need to beat yourself up when it happens. What matters most is how quick the recovery or resolution is to avoid minimal impact on business. Bugs are also great learning opportunities and so brace up and prepare to deal with them and avoid their reoccurrence.  

Happy testing friends!