Good afternoon, Habr. In this article, I want to show the life cycle of testing a client portal developed initially for the largest German bank (Deutsche Bank) and further for the leading banks in German-speaking Europe (UBS – Switzerland, Raifeissen – Austria), as well as for other banks operating according to the European EBICS standard.
First, a little background.
My name is Alexander. In 2009 I graduated from MEPhI, Faculty of Theoretical and Experimental Physics. During my studies, like many techies, I worked actively in the IT field: first, manual testing (Microsoft Office and Windows Vista), and then 1C (Programmer-Consultant). All this quickly bored me and I decided to turn again to physics. Having previously learned English, having passed TOEFL and GRE exams, he began to enter the USA for graduate school for PhD. I managed to send only the documents to 1 (medium-sized) university, from where a positive response came fairly quickly. At the same time, my friend, who had already found a PhD position in France, recommended me to write an ad on a European job site for young scientists – and I unexpectedly received 2 invitations from Germany. As a result, my choice fell in favor of Deutschland. I will list the main factors that determined my choice: the proximity of the country to Russia (2-hour flight Berlin-Moscow), a long vacation compared to the USA, a PhD lasts an average of 3-4 years instead of 5-6, plus I liked the German language, thanks to Rammstein.
PhD flew by quite quickly (just over 3 years). Despite some results achieved and 4 published articles, I did not see myself further in science due to: the unpopularity of my topic (solid state physics), very high competition in the scientific environment (30 postdocs on average per 1 professorship), and also the constant need to move around the world in search of positions. Having lived in Germany and learned more or less German (the labor costs for studying, according to my estimates, are 2 times higher than English), I decided to turn to the local labor market (the doctoral degree was defended as obtaining a German education, that is, I could live in Germany and look for work more within 1 year). However, it was not easy to find a job: in many cases I was “retrained”, I also did not have certificates and local work experience. I did not apply for purely developer positions, since I only knew how to program a little in Python, and 1C is still a bad start, especially in Germany. As a result, the choice was quite narrowed: Data Analysis or, mindful of my experience, testing as the first step to jump into the IT field. Despite more than a hundred resumes sent out, the job search continued for more than six months, perhaps also because few new employees are recruited here in the summer and autumn.
As a result, in the winter of 2015, I got a position in a medium-sized IT company in Hamburg (about 500 employees throughout Germany, 200 in Hamburg). Then I issued a Blue Card (there was a recent post about this so-called Blue / Blue Card: by the way, Germany issued 87% of all such cards from the entire European Union, which indicates the relative accessibility of the labor market for foreigners and the very fact that there is work), which will allow you to get a residence permit at the beginning of next year. Registration is very simple, just bring a copy of the contract and a German certificate (level B1).
From the very beginning, I was thrown into a new project: a client portal, then KundenPortal, working according to SEPA standards.
It is important to mention that KundenPortal is paired with another product of our company: BankRechner, aka bank clearing center: a program that accumulates all payments, including those from client portals of other companies, and performs subsequent calculations for analysis and tax reporting. The heaviness of the software stems from the fact that the largest banks work with many thousands of clients, each of which can enter a huge array of documents into the system. Naturally, all this works on very powerful servers (Unix), with terabyte databases (Oracle). As a result, load testing in this case is critical.
The project initially presented to the client (almost 2 years ago) had only basic functionality. Further, active interaction began between the managers of our company and client banks. Clients make out their wishes in the form of so-called CRs (Change Requests), which describe the required functionality. Naturally, these are not just wishes, but everything is coordinated by people competent in the field of Zahlungsverkehr (Payment transport / transactions) on both sides based on the EBICS standard and with the development of the legal side and security concepts. These aspects are not in my area of expertise, so I will leave them out of the question.
Further, these CRs (from different clients) are accumulated into a single list. The execution of this list determines the iteration (aka product version). In our case, a typical release cycle lies between 3 and 6 months.
Based on this list, the technical project manager creates a Concept, where he describes how it should be implemented and divides everything into topics that programmers choose at the so-called “Theme Fair” (usually 2 programmers fall on 1 topic for safety net and exchange of experience, according to at the end of the theme, they are again mixed up and again combined into pairs). Programmers based on the Concept and consistent GUI templates (Mockups) implement everything in code. When the code is ready for some acceptable percentage, the topics are distributed among the testers. Since there are fewer testers, we get several themes, also by choice. The idea is similar, as in the case of developers: we must know the maximum functionality and insure each other. On the one hand, this method is complicated in terms of the fact that you need to know everything about the program and be able to switch quickly, but on the other hand, we do not get bored, you constantly learn something new (even about finance and national banking systems), and you can also look at testing problems from different angles, which increases efficiency and even intuition when searching for bugs. In the current iteration, I already have about 10 topics.