we combine different testing techniques, using the example of checking payment systems

1. Equivalence classes.

2. Limit values.

3. Cause-and-effect analysis.

4. Predicting errors.

In paragraph 3 we are talking about drawing up so-called influence maps – visualization of which events affect which parts of the system under study. In my experience, it is especially useful to make such maps when testing changes on the backend, as well as when testing large systems when many changes occur at once in different places.

What I rarely use (and what I won’t go into detail in the article):

I. Paired testing.

The specifics of my tasks are such that quite rarely there is a need to regularly check a service with different input parameters – their variability in my cases is small, so usually equivalence classes are enough for me.

Now, if it were necessary to test a system where there may be many non-coinciding configurations of input conditions, then it would be impossible to do without a “match.”

II. State diagram.

Here again, it’s all about quantity: I don’t have many cases related to the state of the system (order statuses, payment); A cause-and-effect analysis is sufficient for verification.

III. Decision table.

I use it only when a large task appears that affects many old dependencies or creates a significant number of new ones.

Before testing: decomposition

So, let's test the payment system.

First of all, we decompose the system. It’s a matter of taste: some write the decomposition in text, others draw it, and others keep it in their heads. Whatever you want, the main thing is to answer the question “What exactly do we need to test?”

A spherical decomposition of a payment system in a vacuum might look like this:

Depending on the project, you can change details here – for example, visualize dependencies with arrows. Minute byte: what would you add, remove or change in this diagram – write in the comments?

In my case, the refined decomposition looks like this:

How to make a good decomposition: collect everything you know about the system under test, divide it into convenient ones you categories, describe the known ones you details. And then you make adjustments as you work.

I have never come across an ideal decomposition: it is extremely difficult to take everything into account, and even for a thoroughly described detailing, unaccounted nuances appear – the system develops. In my opinion, the key point for the success of decomposition is your personal convenience for working with information.

Test design for payment system

After decomposition, let's move on to test design. Let's go through the techniques in the order they were listed above.

(1) Equivalence classes

We will divide the testing into four checks according to payment types:

1. Card + bonus points (Petrovich’s loyalty program): product, gift product, paid/free service; full refund (when the amount for the entire order is returned).

2. SBP + promotional code: product, gift product, paid/free service; incomplete refund (when part of the funds for a product or service is returned).

3. Credit: full refund.

4. In parts: the return is incomplete.

Let's not touch scenarios with legal entities; this is a separate universe. We will combine points and promotional codes with other payment methods.

This division will allow us to cover a significant part of the system with tests. The set of input data is quite large and complex, this can cause errors.

With each iteration of the check, you can change the conditions a little to avoid the so-called “pesticide paradox” (if a constantly repeating set of tests is applied to any functionality, then these tests will soon be ineffective for finding new defects).

(2) Limit values

Let's see what limit values ​​there are in payments and what you should pay attention to. Depending on the service or product, you may have different types of payments: subscription, one-time payment, custom tariff.

It is important to consider several points here:

1. Standard payment limits: from minimum to maximum amount.

2. Discount: from minimum to maximum (similarly – cart).

3. Checking the rate of bonus points to real money.

In my case, I look at the “points – ruble” rate. Example: 1 point = 4 rubles.

4. Availability of installment and credit options.

Case: installments can be taken with a shopping cart with an order amount from 1000 to 5000 rubles, a loan – from 3000 to 70000.

5. Possibility of using points.

“Included for carts worth from 280 rubles.”

6. Amounts greater or less than established limits.

This check could formally be transferred to “Error Prediction”, but here in “Limit Values” it seems to me appropriate to consider this too.

7. Minimum and maximum cart amount for using points (bonuses).

All these checks can be divided into subclasses, combined or changed. For example, as part of our decomposition, you can do several checks: fill your cart with 5,000 rubles, apply a minimum discount, use points.

(3) Cause and effect analysis

Let's imagine a situation: there is a cart, there is a product in it, a person creates an order, pays, and receives a receipt for payment.

For most users, all this looks “so simple,” but we understand that hundreds, or even thousands of operations took place, with data moving back and forth, with many checks, with calls to third-party integration services and other manipulations .

Cause-and-effect analysis will help us have an idea of ​​where and at what stage our records are created and changed, and whether everything happens on time and in the correct order.

Let's take a closer look:

1. There is a cart, there is a product in it: the cart has a cache, it changes; can live in a database, elastic or logs.

2. User creates an order: As a result, records are made in certain database tables, in the CRM system and other places.

3. Man pays for the order: on our side, new records are changed and created, information is exchanged between payment systems, many checks take place, and in the end the order is either paid or not.

4. The client receives a receipt for payment: another integration operation with many records – on our side, on the bank side and in the payment system.

Here is one way to visualize this:

In my opinion, when checking payment systems, cause-and-effect analysis should always be used – there are so many operations and connections, it’s difficult to keep everything in your head. And with visualization, in the event of an error, we will be able to quickly guess where and what could have broken, we will immediately know what to turn to and what we should look at.

(4) Error prediction

Here the task is not so much to reproduce the error, but to obtain the correct reaction of the system and the necessary entry in the logs about the type and causes of the problem.

Situation: you have an order paid by the client, for some reason the payment has lost one of its properties. For example, if you worked with 1C-Enterprise, you might have encountered something like this when the payment “got through.”

Losing a property does not necessarily have serious consequences; especially if this happened after payment or receipt of a check. But what if the user wants to return the product? Losing the payment property in this case can complicate the entire process.

What's the best way to deal with error prediction? I haven’t come across a silver bullet or a magic pill for this – the systems being tested can vary greatly.

The key here is to know what mistakes happen; how they reproduce; how they are displayed in the system and recorded. Talk to the developers about these things.

What test design techniques will I use today?

For various test design techniques, “know” and “be able” are not the same thing. Too often in my past experience I used one, or at most two, of them for one or another test. Because of this, the aforementioned “pesticide effect” can occur: the same tests, methods and testing approaches create the illusion that everything is working well, but in fact it is not.

How to overcome this is to use more available test design techniques, apply the maximum of them. By using multiple approaches and rotating them, you will have a broader testing context and ultimately be able to achieve more than if you constantly use one or two options.

I hope that the conversation about using test design techniques to test payment systems will be useful to you – if not in practice, for solving relevant testing problems, then at least it will give you another reason to ask yourself the question “What test design techniques will I use today?” .