QA Process and Testing for a White-Label Oracle-Based Banking Solution
Industry
Country
Type of Service
Cooperation Type
Project Type
Test Coverage
Overview
The client* is a software development company working on an Oracle-based white-label solution for the banking system. They developed the web and mobile versions of the specialized application with a large potential for integrations and scaling to support banking operations. This solution was designed to allow the staff to manage banking operations more effectively.
* We recognize the importance of protecting our clients’ privacy and follow the policies to maintain their confidentiality and security. That is why the company name will not be disclosed.
Challenge
The client was looking for a QA partner who has specialists experienced in Oracle Flexcube and OBDX & OBP Applications on board. Moreover, due to the banking specific of the project, domain knowledge and secure working procedures were critical for the client team. So, the partner had to have ISO and ISTQB certifications.
The application had a complex logic and architecture, and the client planned to scale it further. Besides dealing with sensitive data and complex operations, the software featured numerous roles for different types of customers and accesses and strict operation management rules.
Despite the complexity, the product wasn’t tested extensively from the start. There were no QA engineers on the technical team, and the application didn’t meet the quality needs the team set for comfortable work and future scaling.
Solution
After passing the interview, the QA engineer started onboarding with the education on the client’s side. The software used Oracle’s solutions, but it was tailored to the banking standards and logic of the bank’s location country. Therefore, it was critical to understand not just the overall specifics of QA for banking but also the regional particularities of the industry.
After learning the essentials and receiving the necessary access to the test environment, the QA engineer proceeded to set up the testing process. It included the following steps:
- Reviewing the existing project documentation and test cases.
- Running exploratory testing, detecting bugs, and getting insights for test strategy.
- Determining the necessary types of testing for the product.
- Updating the test suit to extend the coverage by writing detailed test cases.
- Running tests based on the written cases and detailed reporting.
- Running retests after fixing and maintaining the testing documentation.
The QA engineer interacted with the product team to understand the software requirements better. For the most part, it was independent work followed by reporting and recommendations.
Results
- The QA engineer set up the QA process from scratch. This allowed the team to extend the test coverage and prepare the documentation to organize the process.
- The application was tested on various physical devices and browser versions, including Windows laptops and iOS and Android smartphones.
- The defects were described in detailed reports with severity assigned and recommendations for fixing priority shared. It allowed for refining the basic functionality that initially featured numerous defects and crashes.
- The QA engineer shared recommendations on usability which helped improve the complex features that weren’t obvious or intuitive.
- The specialist also shared recommendations on arranging the project documentation, in particular, app logic and main flows, to simplify the work for the technical team.
- The client admitted improvements in the development process and product quality in a few weeks after the QA expert joined the team.
Let’s Start a New Project Together
QA Madness helps tech companies strengthen their in-house teams by staffing dedicated manual and automated testing experts.
Anastasiia Letychivska
Head of Growth
Relevant Case Studies
Ready to speed up the testing process?