For some time now, in Yandex.Money, all products consist of a multitude of microservices, for which up to a dozen updates are released per day. In addition, we regularly have to check the strength of the entire payment service - as far as it can withstand the peak loads, is there a margin of safety.

That is why the software testing division is one of the most numerous. Among the testers most functional experts. In this article I will tell by examples what these guys are doing and what tools they use in their work.

In the department there are also specialists in performance, as well as mobile and integration testing, but about them another time.

Functional testing team checks the serviceability of services over which the entire product team works during the quarter. Mostly manual checks - autotests are written here for frequently repeated scenarios. In addition, "functionaries" perform technical support duties in complex and incomprehensible cases.

What is more important: know the development life cycle or how the Internet works

Looking through hundreds of vacancies on specialized sites, you might think that the tester needs to know by heart the development methodology, several programming languages ​​and have basic skills in managing the space shuttle. In our paradigm, it is customary to expect that the tester knows the IT alphabet and can compose meaningful “words” from it.

You can take this alphabet as the foundation of Maslow's pyramid, without which you can’t really understand how the Internet works.

It is not customary for us to assign a “test plan” from above and there is not even a dedicated test lead for task distribution. Each tester must himself understand what they need to do now, so the level of personal responsibility is quite high. Of course, a general understanding of the work of the key components of the company will greatly help here, but the first time you still have to clarify priorities in incomprehensible situations with project managers.

Therefore, a newcomer should accept the fact that for the first six months he will ask colleagues from testing, from his team, from the analytics department for every sneeze.

Remove this awkward feeling of helplessness can only be tightly "cooked" in a specific team. Due to this, you can save from a couple of hours to several days to check absolutely all error scenarios. A simple example: a user withdraws money from an ATM, but instead of cash, he receives "something went wrong."

If you propose to understand the problem to a beginner, he will start by checking all the payment scenarios that have come to mind, and all possible outcomes. If this person has already managed to know the Zen of the internal structure and interconnections of all the components involved, he will be able to focus his efforts on the specific process of withdrawing money and the three to five components involved.

In the first month, beginners will learn more about the application architecture, REST API, JSON. Get closer to Linux, get acquainted with the SQL query language and with flexible development methodologies, autotests. And also learn the basics of Java and Kotlin - the latter seemed to us convenient for autotests due to a more concise and compact final code.

By the way, we write autotests all - if programming looks like something from another planet to testers, then it will still be able to put methods in our framework in the right order. And over time, and knowledge of algorithms and languages ​​will tighten.

Dive into a frontend or backend

The testing approach is very popular among novice testers; it’s about clicking all the buttons on the site, you can quickly click the UI and always be in demand, but this does not always make it easier to find a job and further career path. For example, most Yandex.Money services consist of frontend and backend parts, and we do not have a division of testers into these categories.

Instead of grouping technology testers, we assign them to the product development team, where the focus can be shifted towards the front or back. But in any case, these components often overlap, and to be able to work with both is necessary.

For example, we have an internal tool for the contact center - a web service with information about all user calls. In the course of the next project, the tool received a new summary page, which makes it easier to track ticket status and SLA compliance.

For the new version it was necessary to do the following:

• Check that it supports everything that was in the old version.
• Monitor compliance developed for the User Story project.
  Example: A monitoring employee enters the monitoring page and looks at the color of the queues. If there are red marks, clicks “assign operators”, and from the general list of specialists the system automatically selects all suitable and free ones.

Any project begins with a technical solution, after which a tester is connected to the process.

Usually, it all starts with a technical solution that analysts, developers and project managers prepare. The decision necessarily indicates which components are involved, which ones should be processed and what entities need to be added or improved on the back end and front.

On the planning of the project, the solution is decomposed into the tasks of the developers, which allows them to be tested as they are released. At such times, the day the tester looks like this:

1. In the morning you form your task list for the day from the current sprint . This is done using kanban boards in Jira, where priority is given to urgent things like bugs. The remaining priorities are allocated by the project manager. Now the main thing is to move through the list and not just redraw it.
')
2. You check the components of the implemented tasks, usually starting from the backend, because it is launched into development earlier and the front still does not appear without a back-up.

3. To check something, you need to know how it all works in the idea. Therefore, each tested method must have a description (what is the input, what is the output, etc.). But usually the information is not enough (which is clear to the developer, it is not always clear to the others), in this case Swagger and responsive colleagues help a lot. The knowledge gained is useful to add to the technical solution, for the benefit of others and for history.

We have a widely used REST API in our infrastructure, so a frequent testing script is HTTP requests sent via Postman.

Speaking of tools - in daily work, our testers use the following set:

• Postman or cURL - to send http requests.
• SoapUI.
• The Linux command line for viewing logs and installing components, in particular, grep is the best friend in sifting information. By the way, at the beginning of a career quite basic skills are enough.
• Oracle DB and PostgreSQL clients - for viewing and managing data in databases.
• Kibana for viewing both “combat” and test logs.
• Finally, the universal IntelliJ IDEA tool, which is great for writing autotests and for manual testing: some colleagues prefer to test a prototype of a test instead of using a Postman to check the API.

The choice of a particular tool depends on the tester's personal preferences and the availability of the tool on the target host.

Periodically, you have to dig deeper and switch to debug mode in the configuration of the application under test. The main thing is not to forget to remove the flag of this mode, as soon as all the necessary information is collected in order not to accidentally stop the application due to the overrun of disk space.

Usually, testing the backend part consists of sending a request with the necessary input data, receiving a response and verifying that the result conforms to the documentation. This simple chain often stumbles, for example, about the need to check the record of the results of a POST query in the database. The easiest way to do this is to manually log into the database through the DBMS agent and verify the data is correct.

Therefore, you need to locally log in to the server with the database (for example, PostgreSQL) or via pgadmin and execute a query to retrieve the data of interest. The SQL language is not necessary to know, since everything can be done in the pgadmin GUI. However, it is still desirable to know the very basic SQL query constructs (SELECT *, WHERE, ORDER BY).

For example, there may be 10,000 entries in the database, and it may take too long to search for data through the GUI. In general, it would be good for a tester to be able to quickly write a request of the form in the console:

select * from {table_name} where {table_name.column_name}='condition' order by {column_name} desc; 

Everything else is a nice bonus.

About balance of testing and interdepartmental communication

Independence testers need not only to select tasks, but also to conduct a series of tests - you should always look for a balance between “check everything you can” and time for that. It makes no sense to check all possible values ​​and scenarios in the component if it already receives data from a special form with a check of values.

For example, there is a method that accepts only string variables as input, and you need to check what happens when you send scripts (a word about security) or Integer variables. Even compiling a list of such data for a very long time, you do not have time to complete other tasks. In the selection of a reasonable list of tests will help ready user stories . In essence, the frontend already restricts the input of some parameters, which sharply narrows the list of checks.

Some tasks require verification in conditions close to combat situations — for example, on a test environment, it is difficult to completely verify a card payment passing through all acquirers and payment systems. Therefore, the test takes place on our preproduction - several frontend hosts disconnected from the balancer and accessible only from our network at a direct URL.

Compared to the test environment, it is not so convenient to check scenarios in “combat” conditions due to the lack of some access, and you don’t want to spend real money. Therefore, in the preprod environment, we check only a limited acceptance test set.

The situation is interesting with projects where not only our company is involved, but also partners. A good example is the support of the partner’s bonus program, for which Yandex.Kassa acts as a payment solution. The cashier needs to be able to transfer information about bonuses to him and to carry out, for example, redemption of a part of the purchase, depending on the wishes of the buyer and the possibilities of the bonus program.

The whole point of such projects is in “interdepartmental cooperation”, when certain actions from that side are necessary for success.

If you remember the last article about selecting a tester , then communication skills were important - the ability to negotiate with everyone. And here it is useful as nowhere else. In a joint project with any partner with whom we exchange specific information, it is necessary to obtain a working test environment and the data itself. The latter may be a pool of partner cards, among which there are blocked, conditionally unsupported bonus program, etc.

In addition to the test environment and data, you also need a communication channel (usually a Telegram, which partners like and for which many bots are written for their own needs) for operational communication of technical specialists. When the preparatory work has been completed, it remains to wait for the tested method to be ready on the partner’s side.

For example, consider in more detail the verification of the standard payment method, which consists of the following chain of actions:

1. Installing the assembly on a test environment. Now you can do this with Jenkins, which we will write about soon, but for now you can read the next Jenkins article in the CI & CD process .
2. Since all requests are executed with a card token, you need to get a unique token for each payment chain. The stages of the chain: getting a token, requesting the number of points to be written off within the basket (the store sends to Yandex.Money a basket with the amounts of goods), making a payment with account of partner bonuses.
3. This is followed by the specifics of a particular partner, which usually includes the exchange of information about bonuses with some subsequent actions.
4. In the course of inquiries from the preceding paragraph, the partner should receive an answer in which it is important to check its compliance with the documentation. Usually we expect a successful status code (HTTP 200), the response body with the status of the operation’s success, the payment ID, the order status, the payment status on the client side. It checks both the list of fields, and the range of acceptable values ​​and the coincidence of the answers with the actions taken.
5. If the partner's bonus program involves sending him additional information on the basis of the transaction, then we also check the success of the delivery of this data. Usually we just look at the logs on our side, check that an order has been formed in our system, a payment has been made, etc.

After checking the positive scenario, negative ones are checked. For example, we bind a card that does not participate in the bonus program and try to make a request. You can also simulate the network timeout and check whether we will wait for a response to the request, as well as what error codes there will be if the request fails.

Such a chain of actions is further automated to speed up repeat tests. Autotests themselves are written in Java or Kotlin.

Once at an interview after asking what the primary key is, they asked me in reply: “Why are you asking this? You open Habr, there every second article about the blockchain, neuro-science and artificial intelligence, and here you are about the primary keys. ” This article is an attempt to explain that the knowledge of a tester is a kind of Maslow pyramid and you cannot jump to the next levels without knowing basic things.

Databases, HTTP response codes and the Linux console are a kind of alphabet that allows you to speak intelligently in the language of the IT industry. Without them, you will be sitting in a Chinese room , not knowing that you are being asked, but knowing what kind of response is expected of you.

Thus, we expect from a new person not just knowledge of the alphabet, but the ability to add sentences and the ability to understand what it really means.