Manual integration testing in the banking sector. What’s inside?
Introduction
Not always, when coming to a large new or old project, a new tester knows from which side to approach the beginning of the testing process. Sometimes there is no curator, sometimes the communication process is not set up. And you can spit on the company at least a hundred times and go looking for a new one, since the market is now in short supply. But it will be much more interesting to gain invaluable experience of becoming you as an independent and understanding team member. This article will be devoted to the theory of testing implementations of the anti-fraud system in one of the largest banks in the Russian Federation. What are we going to talk about in this article? On the features of the enterprise architecture. About the basic tools and advice for those who want to come into the field of backend integration testing in a large company.
Examples will be taken from work on the integration of anti-fraud systems.
Testing toolkit
At interviews for this position, in addition to the basic required knowledge of the theory of testing and working with the basic tools of the tester, a set of knowledge is also required to understand the operation of the protocols by which this interaction takes place. And also a set of tools. What is included in this set:
SOAP (xml message composition);
REST (some of the interactions go through OpenAPI), JSON;
SoapUI and Postman (if desired, which tool is convenient, they used it). From practice, if the queue works with XML, we use SoapUI. If REST is based on Postman. It was noticed that SoapUI does not always correctly handle RestAPI errors.
ssl encryption principles. Buses love to communicate safely, so knowledge of key generation is required;
putty + bash + linux. On some complex integrations, you cannot send messages directly from the source system (we are talking about way4 and processing transactions). Therefore, friendship with linux was welcomed at the level of “I know how to connect via ssh and run a module with parameters”. To generate ssl, by the way, you will also need to know this;
SQL at the level of simple queries before join. Relational DB theory is desirable. Ability to work with any RDBMS – MS SQL Developer, PL SQL Developer. The second even supports Test Runner for simple checks;
Basic understanding of client-server architecture and OSI.
Practice is not required, but you always want the candidate to be involved. Any Pet-project is suitable to tell about the practice of working with all of the above. VirtualBox + http server + Postman project. Or dubbing services with an open API.
Architecture
There is a different approach to project documentation. Some require documentation of their work, some work with agile methodologies and do not prioritize documentation. In general, there may or may not be documentation. And if you have not clarified about the presence thereof at the interview, then do not be surprised. Find an employee (PM, Team Lead, Tech Lead) who can outline the technology stack and try to sketch the architecture diagram for yourself. Then, by showing the picture, it is easier to understand the movement of data streams and talk with the rest of the team in the same language.
An example of the composition of the test circuit:
Data bus. Very often in the corporate sector, some kind of queuing service is used – tibco, kafka, RabbitMQ.
The core of the anti-fraud system (+ web interface to it for configuring policies).
Database with data of transactions, clients and others, for correct calculations of the anti-fraud system and the application of scoring policies.
Other related systems required for testing
Adjacent systems communicate with the bus through connectors. For each connector on the bus, a separate service is written that converts data from a format that the source system understands to a format that the bus understands. Most often this is xml.
After that, the document is placed in a queue, from which the bus sends data to the receiving system. In our particular case, it was an anti-fraud system.
To receive and correctly process data from each source system, a separate microservice is written on the anti-fraud server side. Microservices perform the atomic functions of delivering data to the kernel and transferring scoring points from the kernel with an anti-fraud verdict back to the bus. I can also validate incoming and outgoing data in accordance with the TOR. In this case, the results are optionally, in agreement with the customer, logged into the database for subsequent analysis.
Testing Processes
Testing processes are divided into two types – separately testing a new microservice and end-2-end testing… Each of these types includes several stages on the part of the testing team.
Testing a new microservice includes the following steps:
Analysis of technical specifications for a microservice (developed by the customer together with the analyst);
Decomposition of requirements and compilation of a requirements compliance matrix;
Writing test plan for agreement with the customer. You can find a template on the Internet, if one is not available;
Writing test cases according to the matrix. Any test management system is used. In the corporate sector, TFS is now widespread (Azure DevOps Server)
Actually, passing test cases and introducing defects;
Test results reporting – protocols, artifacts, etc. (optional upon agreement with the customer)
In the corporate sector, the role of the customer often belongs to the internal business unit and the business leader is the decision-maker. He also sets a business task for the development of integration interaction. For example, the head of the department of SME (small and medium business). In this case, test data can be provided by employees of the customer department.
Business tasks for the anti-fraud system can sound like this:
“It is required that all payments from legal entities are verified in the system and sent for manual verification / blocked if the score is more than 60”.
“It is required to block all requests from individual entrepreneurs with a delay of more than 1 month”
End-2-end testing differs in that the stage of agreeing the test plan not only with the customer, but also with the testing team of the source service is added to the usual process. And also in the process of passing test cases, all test data (requests) are generated by roles in the source systems. Each information banking system has its own team (internal or external integrator) that develops new functions, and also has its own developers and testers. E2E is being held in conjunction with them.
For example: The Diasoft tester from the “Operator” role sends a payment on the world card from one legal entity to another.
Interaction team
System testers interact with the following key personnel:
Project manager
Technological infrastructure manager (possibly DevOps)
Development analyst
Customer side analyst (optional)
Developer from the source service side
Antifraud side developer
Bus side developer
Autotester, Architect, Support, Scrum Master and other unseen beasts – optional, but rather not.
The set of roles corresponds to the standard set of roles in the software life cycle for any methodology.
Basic test scenario
After the customer has sent the requirements and a set of anti-fraud policies, analysts or support service configure them on a test loop in the web interface.
The testing team is responsible for preparing test data according to requirements and policies, and creating a SoapUI project to send this data to the appropriate microservice. After writing each new microservice, the wsdl file is uploaded again, which is then loaded into SoapUI.
By test data, I mean xml files, the set of fields in which met the requirements, in which the policies worked correctly or gave the appropriate response code, according to the documentation.
Example: When making a payment from individual entrepreneur Vasechkin to individual entrepreneur Petechkin, the payment must be no more than 1 million rubles. If more, then the anti-fraud returns a DECLINE response and the transaction is blocked.
The response code can change, as well as the composition of the policies.
A more complex example: When sending 1 million rubles from individual entrepreneur Vasechkin, it is required to request the presence of overdue loans from this individual entrepreneur through an adjacent system. If there is a delay, increase Vasechkin’s scoring score by 50 units for each delay. If the scoring score is exceeded 100 units, send the payment for verification to the manager in manual mode. In this case, the anti-fraud must send the ALLOW WAIT code and a scoring point in the response body.
Positive scripts.
For all positive scenarios, xml is compiled with the necessary data for the client (id, name, inn) and the required amount in the request body. The request is sent to the microservice and asserts are created in SoapUI to check the correctness of the response.
Typical composition
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ns="http://www.endeca.com/endeca-server/control/1/0">
<soapenv:Header/>
<soapenv:Body>
<ns:createDataStore>
<ns:dataStoreConfig>
<ns:name>books</ns:name>
<ns:dataFiles>c:endecaappsbooks</ns:dataFiles>
<ns:wsPort>8000</ns:wsPort>
<ns:bulkLoadPort>8001</ns:bulkLoadPort>
<ns:startupTimeoutSeconds>90</ns:startupTimeoutSeconds>
<ns:shutdownTimeoutSeconds>120</ns:shutdownTimeoutSeconds>
<ns:arg>--threads</ns:arg>
<ns:arg>6</ns:arg>
</ns:dataStoreConfig>
</ns:createDataStore>
</soapenv:Body>
</soapenv:Envelope>I gave him as an example. The tester wants to know the key elements of the XML schema
Negative scenarios.
For all negative scenarios, the datasets are changed in the key fields. Various test design techniques are used to check the correctness of the response of the anti-fraud system. If there are requirements for the types and length of data, it is necessary to check both the response of the front and the response of the databases to overstepping the value boundaries. It is advisable to handle errors on the application server, not letting erroneous data into the database.
After sending a request to the microservice, and checking the correctness of the response using asserts, you also need to check the correctness of logging in the anti-fraud database and sending the response to the bus.
Logging work each service always occurs in a separate anti-fraud database table, unless the customer has specified otherwise. Verification is performed by manually composing a request to the database or by adding data validation from the database using SoapUI – JDBC request.
Checking data bus logs is also included in the microservice testing process. The microservice must accept a response from the kernel, generate a response for the bus in the required format and send it to the bus using the appropriate protocol. The bus logs incoming messages from services and writes to the corresponding log. At this stage, the composition of the response fields is checked, compliance with the customer’s specifications.
Comment. In end-2-end testing, special attention is paid to checking the composition of incoming and outgoing messages to the data bus. Composition, names and structure of json and xml fields, correspondence of data types, etc. If the data types or field names do not match, then we get a 100% chance of a defect when writing to the database or when processing a document by the appropriate connector or microservice, both in the receiving system and in the source system.
Conclusion
The anti-fraud system in banks is now one of the most important modules in the infrastructure and the incorrect operation of this system can greatly affect the reliability and security of service. Testing of this system is also a high priority for the financial monitoring department. The specificity of working on such a project is the deep immersion of the testing team in the subject area of banking operations. Interaction with many employees of various source systems requires high analytical skills, because the time of immersion in the task and subject area is dictated by the release framework.
