Testers: How to Negotiate the Intricacies of a Financial Institution

One of the advantages of working for a consultancy is variety. Not only do you get to work with different clients on different projects across a range of sectors, but each is managed in its own particular way within the realm of Agile guidelines.

As a tester, I need access to a multitude of resources in terms of people, environments and data. This can vary wildly depending on whether the project is within the public, private of financial spheres. If we take financial sector projects as an example, edge cases are common and they all need to be tested, and so access to a lot of data is important. However, working within finance isn’t like working in other sectors where you can simply make up your own test data and go. For security purposes, you have to request any test data that you may need. The process can be timeconsuming as you have to specify what you want, then send a request at which point you will be supplied with a small sample of data that you can then use in testing.

The testing we undergo can vary from automated front-end, API contract or exploratory tests, to accessibility testing. The automated and contract tests happen early on in deployments whilst exploratory and accessibility are done further down the line in dedicated environments. When working for a financial institution, we leave performance and security to the internal members of staff as we do not have access to the internal systems that are kept private for security purposes.

Once the code has been tested, it is then reviewed independently, to ensure no “special features” have been added. It is then deployed by a third team who are blocked from adding any modifications. It is paramount that the people deploying the software are not the same ones that also built the software.

Other security protocols that must be adhered to:

  • The source code and its dependencies must be versioned and safely stored
  • Source code management has to implement standard access and control policies
  • All IT security controls must be documented, and all code has to have supporting documentation linked to it as well
  • The application has to undergo functional and security testing and these tests have to be traceable back to the requirement for which the code has been developed
  • All artefacts have to be stored for a minimum of 7 years and they have to be re-deployable at will
  • A rollback/contingency plan is required to be in place before the deployment starts, in case something goes wrong, however no records can be changed or exposed whilst the rollback happens

If you want to change something then the process can be arduous due to the potential danger of exposing a crack somewhere that someone might exploit. Nevertheless, change is possible in financial institutions, despite the red tape, and here at Amido we are committed to helping financial institutions manage their customers more securely.

Leave a Reply

Your email address will not be published. Required fields are marked *