Hey Habr!
We have a new important topic - high-quality development of IT products. At HighLoad++ we often talk about how to make busy services fast, and at Frontend Conf we talk about a cool user interface that doesn’t slow down. We regularly have topics about testing, and DevOpsConf about combining different processes, including testing. But about what can be called quality in general, and how to work on it comprehensively - no.
Let's fix this by — we will develop a culture of thinking about the quality of the final product for the user at every stage of development. The habit of not focusing on your area of responsibility, and associating quality not only with testers.
Under the cut, we'll 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 us about yourself.
Anastasia: I am in charge of testing in 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 Mechanics and Mathematics and initially wanted to become a programmer. But when I got an interesting offer, I decided to try myself as a tester. Oddly enough, this turned out to be my calling. Now I see all my work in this industry.
I am an ardent adherent of the Quality Assurance discipline. I am not indifferent to what products are created, how quality is treated in the company, in the team and, in principle, in the development process.
It's obvious to me that community in this direction is not mature enough, at least in Russia. What we don't always realize is that quality assurance is more than just 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 average person, these two terms very often overlap. How do they differ if you dig deep?
Anastasia: Rather, they are no different. Testing is part of the Quality Assurance discipline; it is a direct activity - the very fact that I am testing something. There are actually a lot of types of testing, and a variety of people are responsible for different types of testing. But here in Russia, when a wave of outsourcers appeared who supply testers to companies, testing was reduced to a single type.
In most cases, they are limited only to functional testing: they check that what the developers have coded corresponds to the specification, and that's it.
— Please tell us what other quality assurance disciplines are there? 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 quality attributes our product should have. Accordingly, if we understand this, then we can compare who influences these quality attributes. Doesn't matter, developer, project manager or product manager is a person who influences the development of a product, its backlog, and its strategy.
The tester becomes more 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 wording that comes from the product manager, to reveal all the implicit requirements and expectations of the client. When we deliver new functionality to our client, 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 on the principle of "just to release a feature."
- It seems that what you just described is the task of a product manager. This, in principle, is not about testing and not about quality - this is generally about product management, no?
Anastasia: Including. Quality Assurance is not a discipline for which one specific person is responsible. Now there is a popular direction in testing, an approach called Agile Testing. His definition clearly states that this is a team approach to testing, which includes a certain set of practices. The entire team is responsible for implementing this approach; it is not even necessary that there be a tester on the team. The entire team is focused on delivering value to the customer and ensuring that value meets customer 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 wanting to create a quality product, we start thinking about the various attributes of quality. For example, how to check that we have really made a feature that our client needs.
This is where this type of testing comes in: UAT (user acceptance testing). Unfortunately, in Russia it is rarely practiced, but sometimes it is present in SCRUM teams, as a demo for the end client. In foreign companies, this is a fairly common type of testing. Before opening the functionality for all customers, we first do a 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 that, scaling to all other clients occurs.
That is, we focus on business, on the end client, but at the same time don't forget technology. The quality of the product also depends 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 trying to scale, or when trying to refactor, we might break something. All this will affect customer satisfaction.
From this point of view, the architecture should be such that we can write clean code that will allow us to quickly make changes and not be afraid that we will break everything. So that iterations of refinement do not stretch out over several months simply because we have so many legacy, and we need to do long stages of testing.
— In total, developers, architects, product scientists, product managers, and testers themselves are already involved. Who else is involved in the quality assurance process?
Anastasia: Now let’s imagine that we have already delivered the feature to the client. Obviously, the quality of the product needs to be monitored even when it is already in production. At this stage, situations with non-obvious scenarios, so-called bugs, may appear.
The first question is how do we deal with these bugs after we have already released the product? How do we, for example, react to stress? The client will not be very happy if the page takes more than 30 seconds to load.
This is where exploitation comes into play or, as they call it now, 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 subspecies of testing - testing on production, when we allow ourselves not to test something before rolling out and test it immediately on production. This is a series of measures from the point of view of infrastructure organization that allow you to quickly respond to an incident, influence it, and fix it.
Infrastructure is also important. There are often situations when, during a test, it is impossible to make sure that we really have everything that we would like to give to the client. We roll it out into production and begin to catch non-obvious situations. And all because the infrastructure in the test does not correspond to the infrastructure in production. This leads to 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 infrastructure as code.
I believe that 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 us from your own experience how the infrastructure and the code affect the quality. Infrastructure as code makes it easier to test all settings and test things that would otherwise be impossible. Therefore, exploitation is also involved in the process of developing a quality product.
What about analytics and documentation?
Anastasia: This applies more to enterprise systems. When we talk about enterprise, people such as analysts and systems analysts immediately come to mind. They are sometimes called technical writers. They receive a task to write a specification and complete it, for example, for a month.
It has been repeatedly proven that writing such documentation leads to very long development iterations and long refinement iterations, because during the testing process bugs are identified, returns begin. As a result, there are 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 end result is a not entirely high-quality product, because patches have already appeared in the architecture, the code in some places is not sufficiently covered by tests, because deadlines are running out, all the bugs need to be closed quickly. And all because the original specification did not take into account all the points that need to be implemented.
Developers are not pests and do not write code with errors on purpose.
If we had initially thought over the specification, in which all the necessary points would have been covered, then everything would have been implemented exactly as it should be. But this is a utopia.
It's probably impossible to write a perfect 100-page specification. That's why need to think about alternative ways of writing documentation, specifications, setting tasks that would bring us closer to ensuring 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 on the team. Most often, designers are used as a service - either by a design department or by an outsourced designer. There are often situations where it seems that the designer listened to the product specialist and did what he understood. But when we start the iteration, it turns out that what was actually done was not what was expected: the designer forgot something, did not fully think through the behavior, because he is not on the team and not in the context, or the front-end developer did not fully understand it layout. It may take several iterations just because there is a problem with the front-end developer understanding the design.
Plus there is one more problem. Design systems are now gaining popularity. They are on hype, but the benefits from them are not entirely obvious.
I come across the opinion that design systems, on the one hand, simplify development, but on the other hand, they impose a lot of restrictions on the interface.
As a result, we do not make the feature that the client wants, but the one that is convenient for us, because we already have certain cubes from which we can make it.
I think this is a topic worth taking a look at and wondering if in trying to make design easier we are actually solving a client pain point.
- It turns out a surprisingly large number of topics related to Quality Assurance. Is there a conference in Russia where all of them can be discussed?
Anastasia: There is the oldest testing conference, which will be held for the 25th time this year and is called the SQA Days Quality Assurance Conference. It mainly discusses tools and specific testing approaches for functional testers. As a rule, the reports at SQA Days deeply examine specific areas in the area of responsibility of the testers themselves, but not complex activities.
It helps a lot to understand 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 run a big department, I do a lot of interviews that really give me an idea of 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 (security testing), because they really help the team to ensure the quality of the product.
I would like the guys in Russia to also start to think that the industry doesn’t end with functional testing.
— For this purpose, we are organizing a new conference, QualityConf, which is dedicated to quality as an integral discipline. Tell us about the idea in more detail, what is the main goal 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 reports and leave 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 start communicating with the teams, you see that the problem is not with the testers themselves, but with the way the process is built. For example, when developers believe that they are only responsible for writing code, their responsibility ends exactly at the moment they submit the task for testing.
Not everyone thinks that poorly written low-quality code with poor architecture threatens with big problems for the project. They don’t think about the cost of errors, about the fact that bugs that get into production can result in high costs for the company and the team. There is 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 the 14 tenets of quality, wrote about the cost of an error back in the last century. Quality Assurance as a discipline is based on this book, but, unfortunately, modern development forgets about it.
- And do you plan to touch on topics directly about testing and tools?
Anastasia: I admit that there will be reports about tools. There are quite universal tools with which companies and teams can influence the product.
All reports globally will be 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 life of the client.
We will definitely not have reports about a tool for the sake of a 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 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. Similarly, it will be interesting for testers and, it seems to me, especially for managers. By managers, I mean people who make decisions and can influence the fate and development of the product, system, and team as well.
These are people who are wondering how to improve the quality of the product, the system. At our conference, they will learn about various sets of events 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 want to influence it. Probably, from the first time we will not be able to reach out to people who believe that it will do anyway.
— Do you think the industry as a whole is ripe to talk not just about testing, but about a culture of quality?
Anastasia: I think I have matured. 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 enterprise companies are refocusing on improving quality.
Judging by the number of requests that come up in the community, I think it's about time. Of course, I’m not sure that this will be a large-scale revolution, but I would like this revolution in consciousness to happen.
- Agreed! We will instill culture and change consciousness.
Conference on high-quality development of IT products takes place in Moscow on June 7. You know what stages make up a high-quality product, we have cases of successfully combating bugs in production, we have tested popular methods in our practice - we need your experience. their applications before May 1, and the Program Committee will help focus the theme for the overall integrity of the conference.
Connect to , in which we discuss quality issues and the conference, subscribe to to stay up to date with program news.
Source: habr.com