Who is responsible for the quality?

Hi, Habr!

We have a new important topic - high-quality development of IT products. We often speak HighLoad ++, how to make loaded services fast, and Frontend Conf - a cool user interface that does not slow down. We regularly have topics about testing, and DevOpsConf about combining different processes, including testing. And about what can be called quality in general, and how to work on it in a complex way - no.

Fix it on QualityConf - we will develop a culture to think about the quality of the final product for the user at each stage of development. The habit of not getting hung up on their area of ​​responsibility, and not only associate quality with testers.
')
Under the cut, we will talk with the head of the program committee, the head of testing at Tinkoff.Business, the creator of the Russian-speaking QA-community Anastasia Aseeva-Nguyen about the state of the QA industry and the mission of the new conference.



- Nastia hello. Please, tell about yourself.

Anastasia : I lead testing at a bank, I am responsible for a very large team - we are more than 90 people. We have an important business line, we are responsible for the ecosystem for legal entities.

I studied at the Mekhmat and initially wanted to become a programmer. But when I had an interesting offer, I decided to try myself as a tester. Oddly enough, this turned out to be my vocation. Now I see all my work in this industry.

I am an ardent adherent of Quality Assurance discipline. I do not care what products are created, how they relate to the quality in the company, in the team and, in principle, in the development process.

It is obvious to me that the community in this direction is not mature enough , at least in Russia. We do not always understand that quality assurance is not only the fact of testing an application for compliance. I would like to change this situation.

- You use the words Quality Assurance and testing. In the eyes of the philistine, these two terms very often overlap. How do they differ, if you dig deep?

Anastasia: Rather, they are not different. Testing is part of the Quality Assurance discipline; this is direct activity — the very fact that I am testing something. There are actually a lot of types of testing, and different people are responsible for different types of testing. But here in Russia, when a wave of outsourcers appeared that supply testers to the company, testing was reduced to a single type.

In most cases, they are limited only to functional testing: they check that the developers have complied with the specification and that's it.

- Tell me, please, what other disciplines of quality assurance? What else besides testing is included here?

Anastasia : Quality Assurance is, first of all, about creating a quality product. That is, we ask ourselves what attributes of quality our product should possess. Accordingly, if we understand this, then we can compare who influences these attributes of quality. It does not matter whether the developer, project manager or productologist is the person who influences the development of the product, its backlog, its strategy.

The tester is better aware of his role. He understands that his task is not only to test for compliance with the requirements, but also to test the requirements, to question the formulations that come from the product specialist, to reveal all the implicit requirements and expectations of the client. When we deliver new functionality to our customer, we must really meet their expectations and solve their pain. If we think about all the attributes of quality, the client will be satisfied and will understand that the company whose product he uses really cares about his interests, and does not work according to the principle “just to release a feature”.

- It seems that what you have just described is the task of the productologist. This, in principle, is not about testing and not about quality - it is generally about product management, no?

Anastasia : Including. Quality Assurance is not a discipline for which one particular person is responsible. Now there is a popular trend in testing, an approach called Agile Testing . In his definition, it sounds straightforward that this is a team approach to testing, which includes a certain set of practices. The whole team is responsible for the implementation of this approach, it is not even necessary for the team to have a tester. The whole team is focused on delivering value to the client, and ensuring that this value meets their expectations.

- It turns out that the quality intersects with almost all the surrounding disciplines, imposing a framework on everything around?

Anastasia : Right. When we think about what we want to create a quality product, we start thinking about the various attributes of quality. For example, how to check that we really made a feature that our client needs.

Here comes a type of testing such as UAT (user acceptance testing). Unfortunately, in Russia it is rarely practiced, but sometimes it is present in the SCRUM commands, as a demo for the final client. In foreign companies, this is a fairly common type of testing. Before opening the functionality for all customers, we first do UAT, that is, we invite the end user, who conducts testing and immediately gives feedback - whether the product really meets expectations and solves the pain. Only after this occurs scaling on all other clients.

That is, we focus on the business, on the end customer, but at the same time we do not forget about the technology . The quality of the product also depends strongly on technology. If we have a bad architecture, we will not be able to quickly release features and meet customer expectations. There may be a lot of bugs when we try to scale, or when we try to refactor, we can break something. This will all affect customer satisfaction.

From this point of view, the architecture should be such that we can write clean code that allows you to quickly make changes and not be afraid that we will break everything. So that the iterations of the revision do not stretch for several months simply because we have so much legacy and we need to do long testing steps.

- Total already involved developers, architects, productologists, product managers, testers themselves. Who else is involved in the quality assurance process?

Anastasia : Now imagine that we have already delivered a feature to the client. Obviously, the quality of the product must be monitored, and when it is already in production. At this stage, situations with unobvious scenarios, so-called bugs, may appear.

The first question is - how do we work with these bugs after we have already released a product? How do we, for example, respond to the load? The client will not be very satisfied if the page loads for more than 30 seconds.

This is where exploitation comes into play, or, as they are called, DevOps . In fact, these are the people who are responsible for the operation of the product when it is already on sale. This includes various types of monitoring. There is even a subtype of testing - testing on the prod, when we allow ourselves not to test something before rolling out and test it immediately on the prod. This is a series of measures from the point of view of the organization of infrastructure that allow you to quickly respond to the incident, influence it, correct it.

Infrastructure is also important. There are often situations when, during the test, it is impossible to make sure that we really have everything that we would like to give to the client. We roll out on the prod - and we begin to catch unobvious situations. And all because the infrastructure in the test does not match the infrastructure for the sale. This results in a new type of testing - infrastructure testing . These are various configurations, settings, database migration, etc.

This raises the question - perhaps the team needs to use the infrastructure as a code.

I believe that the infrastructure directly affects the quality of the product.

I hope there will be a report with a real case at the conference. Write to us if you are ready to tell you in your own experience how the infrastructure affects the quality of the code. Infrastructure like code makes it easier to check all settings and test things that are otherwise impossible. Therefore, in the process of developing a quality product is involved and operation.

- What about analytics and documentation?

Anastasia : This applies more to enterprise systems. When we talk about enterprise, people like analysts and system analysts immediately come to mind. Sometimes they are called technical writers. They get the task of writing a specification and perform it, for example, a month.

It has been repeatedly proved that writing such documentation results in very lengthy development iterations and lengthy iterations of refinement, because in the process of testing bugs are detected, returns begin. The result is a lot of loops that increase the cost of development. In addition, it may introduce vulnerabilities. We seem to have written the reference code, but then we made changes that break the perfectly thought-out architecture.

The result is not a completely high-quality product, because there are already patches in the architecture, the code in some places is not sufficiently covered with tests, because the deadlines are tight, you need to quickly close all the bugs. And all because the initial specification did not take into account all the points that need to be implemented.

Developers are not pests and do not specifically write code with errors.

If we initially thought out the specification in which all the necessary moments would be covered, then everything would be implemented exactly as it should be. But this is utopia.

It is probably impossible to write the perfect specification for 100 pages. Therefore, you need to think about alternative ways of writing documentation , specifying, setting tasks that would bring us closer to the fact that the developer does exactly what is needed.

Here approaches from Agile come to mind - user stories with acceptance criteria. This is more applicable for teams that develop in small iterations.

- What about usability testing, product usability, design?

Anastasia : This is a very important point, because there are designers in the team. Most often, designers are used as a service — either by the design department or by an outsource designer. Often there are situations that the designer seems to have listened to the product specialist and did what he understood. But when we start the iteration, it turns out that what was expected was not what was expected: the designer forgot something, didn’t think over the behavior, because he’s not in the team and not in context, or the front-end developer didn’t fully understand him layout. It may take several iterations just because there is a problem with understanding the design by the front-end developer.

Plus there is another problem. Now the design systems are gaining popularity. They are on the hype, but the benefits from them are not entirely obvious.

I am faced with the opinion that design systems, on the one hand, simplify development, on the other hand, they impose a lot of restrictions on the interface.

As a result, we do not have such a feature that the client wants to receive, but one that is convenient for us, because we already have certain cubes from which we can make it.

It seems to me that it is worth paying attention to this topic and to think about whether we really solve client pain in an attempt to simplify the work on design.

- It turns out surprisingly many topics related to Quality Assurance. Is there a conference in Russia where you can discuss them all?

Anastasia : There is the oldest testing conference, which will be held for the 25th time this year and is called SQA Days Quality Assurance Conference. Basically, it discusses the tools and specific testing approaches for functional testers. As a rule, reports on SQA Days deeply consider specific areas in the area of ​​responsibility of the testers themselves, but not complex measures.

It helps a lot to understand the various tools and approaches, how to test databases, APIs, etc. But at the same time, on the one hand, it does not motivate to involve not only testing in the creation of a better product. On the other hand, testers do not become more involved in the process in order to think about the global goal of the product and its business component.

I lead a large department, I spend a lot of interviews, which actually allow us to imagine the state of the industry as a whole. As a rule, our guys work in an enterprise, and they have a clear area of ​​responsibility. Colleagues who work in foreign projects use different types of testing: they themselves can do load testing, performance testing, and even sometimes security testing, because they really help the team to provide product quality.

I would like the guys in Russia to start thinking about the fact that the industry does not end with functional testing.

- For this we are organizing a new QualityConf conference, which is dedicated to quality as a holistic discipline. Tell me more about the idea, what is the main purpose of the conference?

Anastasia : We want to create a community of people interested in making quality products. Offer a platform where they can come, listen to the reports and go out after the conference with a specific understanding of what needs to be changed in order to improve quality.

Often now I hear a request from consulting what to do when there are problems with testing, with quality. When you begin to communicate with the teams, you see that the problem is not the testers themselves, but how the process is built. For example, when developers consider that they are responsible only for writing the code, their responsibility ends at the exact moment when they transferred the task to testing.

Not everyone thinks that poorly written poor-quality code with poor architecture poses major problems for the project. Do not think about the cost of errors, that the bugs that fall into the production, can result in great costs for the company and the team. No culture to think about it. I want us to start distributing it at the conference.

I understand that this is not an innovation. Edward Deming, the author of 14 quality postulates, wrote about the cost of a mistake in the last century. This book is based on Quality Assurance, as a discipline, but, unfortunately, modern development, forgets about it.

- Do you plan to touch upon topics directly about testing and tools?

Anastasia : I admit that there will be reports about the tools. There are fairly versatile tools by which companies and teams can influence a product.

All reports will be globally united by one common mission: to convey to the audience that with the help of this approach, tool, method, process, type of testing, we have influenced the quality of the product and improved the customer's life.

We definitely will not have reports about the tool for the sake of the tool. All reports that fall into the program will be united by a common goal.

- Who will be interested in what you are talking about, who do you see as guests of the conference?

Anastasia : We will have reports for developers who are not indifferent to the fate of their project, product, system. It will be similarly interesting for testers and, I think, especially for managers. By managers, I mean people who make decisions and can influence the fate and development of the product, system, team, including.

These are people who are wondering how to improve the quality of a product or system. At our conference, they will learn about the various sets of activities and will be able to understand what is wrong with them now, what needs to be changed.

I think the main criterion is to understand that something is wrong with the quality, and to want to influence it. Probably, from the first time to reach people who believe that it will do so, we will not succeed.

- Do you think the industry as a whole is ripe to talk not only about testing, but about quality culture?

Anastasia : I think that is ripe. Now many companies are moving away from the traditional Waterfall approach towards Agile. There is a customer focus, people in teams are really starting to think about how to create a quality product. Even in enterprise companies there is a shift towards quality improvement.

Judging by the number of requests that arise in the community, I believe that it is time. I'm not sure, of course, that this will be a large-scale revolution, but I would like this revolution in consciousness to take place.

- Agreed! We will inculcate culture and turn over consciousness.

A conference on the quality development of QualityConf IT products will be held in Moscow on June 7 . You know what stages a quality product is made of, there are cases of successful struggle with sales bugs in stock, we have tested popular techniques in our practice - we need your experience. Send your submissions by May 1 , and the Program Committee will help focus the topic for the overall integrity of the conference.

Connect to the chat , where we discuss quality issues and the conference, subscribe to the Telegram channel to be informed about the news of the program.