Business-driven testing
My name is Ratkin Kirill, I am from Kontur. I joined the company in 2011 as a tester, since 2014 I gradually began to lead QA, and since 2019 I have been leading a cluster of teams.
My article is about how we all want to be useful. For one, it is important because of the financial component, for another, it is important to feel part of a team. Someone is strongly motivated by positive feedback and praise. The higher our usefulness, the more interesting it is for us to work, the more involved we are in the team's affairs and the more involved we are in the results.
You will be most useful when you learn how to solve problems and achieve business goals. To do this, you need to understand the motivation of the world outside you. First of all, the managers and the higher-level department.
Being business-oriented is a key soft skill that will allow you to be in demand, and companies will stick with you. But how can a tester influence a business? I will share with you some tips that can help you understand where to start and what direction to think.
1. Know the expectations of the business
Go and ask your manager directly
Your manager may find it difficult to answer the question of how exactly your contribution will improve the success of a specific product. They will probably name the first thing that comes to mind. Turn on your tester's meticulousness and ask leading questions using the “five whys” technique.
Depending on the organizational structure of your particular organization, this may be one person or several. First, approach your development manager – this is the person who is responsible for users and for interaction with other teams. Approach your tech lead – this is the one who sets up the internal pipeline. Approach your head of the testing department in the company.
Find out about working with the client base
This work is relevant for most products on the market. Here I highlight two aspects: maintaining the current customer base and attracting new customers.
Maintaining the current customer base
Ask yourself: “What are the reasons for exiting in general?” To compile a list of these reasons, you need to find the person responsible for exit polls, user surveys, NPS, etc. Then look to see if there are any reasons related to functional quality on this list?
If there are, then look at these reasons as tasks. These are the same tasks that are directly related to you, as testing, and to how you retain users. You can even calculate the output from solving these tasks in rubles. And business really likes such conversations.
If the reasons for leaving have nothing to do with functional quality, then this is a clear marker that at this point in time, investing in quality improvement is most likely unprofitable. This is a trigger that you most likely need to spend your time now on increasing the efficiency of the testing process and, for example, raising old technical debts.
Attraction of new clients
Here the answer depends on both the specific product and the market. For example, at the moment the situation for our product and our market is such that we can fight for new users effectively by differentiating ourselves from competitors. These are the so-called killer features, special functionality that sets us apart from the crowd. Such functionality is usually released in small quantities. And it is important for you, as a tester, to be able to concentrate your efforts on such releases.
First, you need to at least learn about them. For example, you can participate in your team's annual planning or at least get acquainted with the results of this planning. The second thing you can do is look for some options for strengthening. For example, create a work schedule during the year so that during the periods of testing killer features you do not have other types of tasks at all.
You can also think about different practices that reduce time to market. For example, practices like Shift Left Testing, when a tester is involved in the early stages of development. This is a controversial practice, but this is where it seems quite profitable.
2. Inherit from higher goals
This is a story about end-to-end goal setting. For example, do you know the goals of your department? Surely they have been voiced more than once, and maybe even recorded somewhere in writing: in a wiki or any other company knowledge base.
The advice is simple, but it is no secret that few testers and developers in general follow it. Find out your company's goals for the next year or quarter, the team's goals, the manager's goals. If your managers' goals are public, you just take them and get stuck. If they are not public, then cling to others: managers' reports at internal conferences, OKRs, etc.
By the way, OKR is a set of principles for organizing work, which, among other things, also promotes the continuity of the goal. So this is exactly what you need to correctly inherit your goals.
3. Think about automated tests and their coverage from a business perspective
This is a very big topic with many controversial issues: who to write to, what to write, how to write, etc. But the main thing I want to say is: when you think about anything, including automated tests, think about it from a business perspective.
How to evaluate the quality of a product from a business perspective? Let's understand what options we have.
The first approximation that can be used. For example, how you yourself feel, how your team feels, how loudly the technical support swears at you. But this is all the tip of the iceberg, in fact, it does not say anything about how the testing actually worked. Therefore, it is not very suitable for us.
This is also not suitable, because the same section of code can be covered with a different set of parameters. And these are completely different test cases. And you also need to take into account that different sections of code are important in different ways
It would be more logical to cover the requirements for your product. But this practice is very expensive to support. And as the product grows, the cost of this support grows exponentially. For example, for our product, which is written by hundreds of engineers and is released every day a double-digit number of times, this support is simply cosmic. It turns out that for each change in each release, you need to turn on your brain and understand whether any of the numerous requirements have changed, whether a new requirement has been added. This is very expensive.
I'll say right away that no, this is a bad KPI. If you evaluate the quality of a product and development by bugs, then the team will very quickly discretize this metric and simply stop creating bugs. They will quietly exchange messages somewhere in messengers. But you will not get new bugs.
In the end, we thought about it as a business and decided to base it on the functionality of the main user scenarios. And we identified two categories of scenarios: frequent and critical.
We even learned to count frequencies automatically. We have a tool that produces a privatized list. A tester can find something useful in it. For example, that users click the PFR button twice as often as the Rosstat button.
But what about the critical ones? We didn't invent anything here. After all, this is already the responsibility of other roles: product analysts, development managers and the same technical support. We simply took this list from them.
So we got our coordinate system. Critical ones should be covered 100%, and frequency ones – some agreed top.
And when it comes to test design, here you should actually use the principles of User-Driven Development. The user should always be your focus.
4. Go on targeted internships with other teams
It is impossible to design a development team perfectly. It is unrealistic to have 2.73 testers in a team and guarantee a constant workload for this team. There will always be either an excess of human resources or a shortage of them in any team at different times. And there will always be tasks that are a priority for the business, sometimes for one team, sometimes for another. But such a system can be balanced a little with targeted internships. This is a tool of your manager, which is used to increase the efficiency of development.
If you have the opportunity to go on an internship and it is targeted, always agree. This way you help the business achieve its goals better. Here is what you can expect:
Firefighting
Another team has a backlog that needs to be helped cleared out.
Help with autotests
Most teams are moving from manual testing to automated testing. And during this transition, a lot of effort needs to be expended. Many teams, especially small ones, usually lack this resource. The transition stretches out over many months and even years. And I know many examples when teams were demotivated by such a long process and did not finish it.
Assistance to the company's most important projects
I'm sure most companies have a list like this, public or private. Teams on this list always need help. Even if they're doing well, come in and make it even better. The whole company will benefit.
Internal audit
This is a situation when there is a problem inside the team, and it does not understand what to do with this problem. We do not understand it from the outside either, because our context is not the same. And then we take a strong specialist and place him in this team, and together they find some solution.
You see that these examples are not like some kind of easy walk. In each case, I will expect a specific result from you. But it is precisely these results that make us useful and important. So torment us. The main thing is to try to prepare the team for your internship in advance, agree with all the managers and agree with the host team. And go ahead.
5. Follow trends: in the company, in the world
This is already a topic that is not entirely testing-related. But you need to look at it more broadly. For example, your company or your specific product simply goes and moves from a monolith to microservices. You need to understand how your work in testing should change. Or, for example, how to test a service, SOA, event-driven, SPA, and so on. There is always a testing strategy.
But recently, large companies have been trying to build multi-product systems. Usually, this happens either on a platform principle or on an ecosystem principle. Or both. Let's look at what an ecosystem is, using the example of an ecosystem.
A product ecosystem is a set of similar services that are designed to provide a single workspace for the user. This means that different products included in the system must have a single style, a single logic. Seamlessness in the transfer of user data and so on is also important. All this must be able to be tested, because the ecosystem has recently become a big competitive advantage that large companies are fighting for. And you need to be able to test at this level so that this competitive advantage is not lost.
6. Read not only about testing
And my last little piece of advice concerns professional literature. Add to the list of books you read books on the following topics:
Development organization processes in different teams
Construction of complex systems and connections in them
Design of development teams
If you don't look at all these topics that don't concern testing, but concern the world around you, then you won't understand how to actually help your departments, close their goals. Or how to help your managers close their goals.
