Although software quality assurance should be faced as one singular challenge for each software development process, there are some common situations that tend to happen among several testing processes.

In this blog we will talk about 5 of the most common errors during software quality assurance processes in the financial industry.

If we take into account the following situations beforehand, we will probably be able plan more accurately and optimize both timing and team coordination.

1. Accounting parametrization. In the best scenario, the testing environment should behave exactly as the production environment. However, there are not many companies that actually reach the stability needed for both environments to perfectly match, so when errors are found during testing, a full investigation must be put in motion to check how the accounting is being worked out in production, since the bugs could be caused by differences between both environments. Such review would probably delay the development release and block other requirements. Additionally, besides being a tedious process, the staff in charge of the software usually has no expertise in accounting matters, which makes the review even more difficult.
2. Lack of updated customer information. When several apps house customer information, the integrity of the data might be compromised due to different inputs for the same variable of a single client. For example, a user may report changes in his address or salary in one system but forget to update the info in another. This situation will increase the difficulty of testing and development for major processes, since bank’s business core activities require many information queries. If an app validates a customer’s variable stored in several systems but with different information in each one, there will be major issues due to incongruity within the information sources. Therefore, many reprocesses involving different departments will be generated and the release will be delayed.
3. Software that nobody knows how to modify. Complex and highly specialized core systems generate traumatic change or update processes. When developing or unifying new components, systems or updating to new technologies, large and highly specialized teams are needed since most traditional banking systems are quite old and not many suppliers are available to deliver on the client’s needs, which increases the cost. This also means there will be a need to integrate several teams involved in operating such large systems and with diverse knowledge and practices, which will probably end up in communication issues and difficulties to carry a smooth process and meet deadlines.
4. Dependence on knowledge gathered by suppliers. Companies that outsource services like development and testing, usually don’t absorb as much knowledge as they should. Due to high complexity of the technologies used, IT departments are focused on managing communications between the outsourcing teams and their systems, so they don’t learn much from the processes being carried out. This becomes a problem when support requests start to rise, the IT doesn’t have all the information and contracts with suppliers are over.
5. Fear to obsolescence. Many times, people that manage processes that are being automated, fear to lose their jobs to machines, so they intentionally provide wrong or incomplete information to those getting the process automated, with the clear intention of making the automation fail during production and have the company believe human input is still necessary. Although this issue could be easily fixed from the specification of the requirements, this behavior not only costs large amounts time of money to the company, but it also stops it from evolving and moving forward with market trends and new technologies.

To solve these issues for the most part, knowledge must be shared across all departments: IT, operations and providers. Getting to this point could be very challenging and even though some companies have a good knowledge base (being this the first step for the solution), there is nothing like practice. It is almost essential that knowledge is not only present in written documentation, but to have users that actually understand technical concepts of how the system works, so they are able to roughly predict the impact in different modules upon implementation of changes. It is also needed to have the IT department and suppliers clearly understand the needs of the company and it’s business rules.

At Finding we understand the great impact of the situations described above and the need to implement preventive and corrective actions to optimize processes. Our project management tool allows us to build, manage and share a wide base of knowledge, so all learnings from each project will not stay in our company but will be transferred to our clients. In the same way, our TestMet^TM methodology guarantees an on-going communication and constant validation of the information between us and all the departments involved in each project, which is managed through Toolcase and allows everyone to see the bigger picture. It also allows us to learn and manage knowledge about our client’s business rules.

Although this article provides verified information, it is always necessary to bring experts on these subjects. Many years of Finding’s experience and it’s testing methodology specialized in preventing, finding and solving all issues found through the entire testing process, makes it an indispensable ally for companies that are about or currently specifying requirements, developing or releasing software products or updates.

To know more how we can help you flawlessly plan, build or release software products, contact us in https://findingtc.co.uk/contact.