Hello, Habr!
We have a new important topic — high-quality IT product development. We often discuss at HighLoad++ how to make overloaded services fast, and at Frontend Conf — how to create an excellent user interface that doesn't lag. Regularly, we have topics about testing, and at DevOpsConf, we focus on integrating different processes, including testing. However, we haven't addressed what can be termed quality as a whole and how to work on it comprehensively.
Let's fix this to — we will cultivate a culture of thinking about the quality of the final product for the user at every stage of development. The habit of not getting bogged down in individual responsibilities, and associating quality not only with testers.
Below, we'll talk with the head of the program committee, the head of testing at Tinkoff.Business, and 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.
— Nastya, hi. Please tell us about yourself.
Anastasia: I lead testing at the bank and oversee a very large team — we have more than 90 people. We have an important business line; we are responsible for the ecosystem for legal entities.
I studied at the math and mechanics department and initially wanted to become a programmer. But when an interesting offer came along, I decided to try my hand at testing. Strangely enough, it turned out to be my calling. Now I see all my work in this industry.
I am a staunch advocate of Quality Assurance discipline. I care about what products are being created, how quality is perceived in the company, in the team, and, in general, in the development process.
For me, it is obvious that the community in this area is not sufficiently mature, at least in Russia. We don't always understand that ensuring quality is not just about testing the application for compliance with requirements. I would like to change this situation.
— You use the terms Quality Assurance and testing. In the eyes of the layperson, these two terms often overlap. How do they differ if we dig deeper?
Anastasia: Rather, they are not different. Testing is part of the Quality Assurance discipline; it is a direct activity — the mere fact that I am testing something. There are actually many types of testing, and different individuals are responsible for different types of testing. However, in Russia, when the wave of outsourcers providing testers to companies emerged, testing was reduced to a single type.
In most cases, it is limited to functional testing: verifying that what the developers have coded matches the specifications and that's it.
— Please tell me, what other disciplines are there in quality assurance? What else, besides testing, is included?
Anastasia: Quality Assurance is primarily about creating a quality product. That is, we ask ourselves what quality attributes our product must have. Accordingly, if we understand this, we can identify who influences these quality attributes. It doesn't matter, whether it's a developer, project manager, or product manager. — this is a person who influences the development of the product, its backlog, and its strategy.
The tester begins to better understand their role. They realize that their task is not just to test for compliance with requirements but to test the requirements, challenge the wording that comes from the product manager, uncover all implicit requirements and customer expectations. When we deliver new functionality to our customer, we must truly meet their expectations and address their pain points. If we think about all the quality attributes, the customer will be satisfied and will understand that the company whose product they use genuinely cares about their interests rather than operating on the principle of 'just releasing a feature.'
— It seems that what you just described is the product manager’s task. This is not really about testing or quality — it's really about product management, isn't it?
Anastasia: Including that. Quality Assurance is not a discipline for which one specific person is responsible. There is currently a popular trend in testing, an approach known as Agile TestingIts definition clearly states that it is a team approach to testing, which involves a certain set of practices. The entire team is responsible for implementing this approach, and it's not necessary for there to be a tester in the team. The whole team is focused on delivering value to the client, ensuring that this value meets their expectations.
— So, quality intersects almost all surrounding disciplines, placing constraints on everything around?
Anastasia: Correct. When we think about creating a quality product, we begin to consider various attributes of quality. For example, how to verify that we have indeed created a feature that our client needs.
This brings up a type of testing known as UAT (user acceptance testing). Unfortunately, it is rarely practiced in Russia, but it sometimes appears in SCRUM teams as a demo for the end client. In foreign companies, this is a fairly common type of testing. Before we open functionality for all clients, we first conduct UAT, inviting the end user to test and provide immediate feedback on whether the product meets expectations and solves their pain points. Only after this does scaling happen for all other clients.
So we focus on the business, on the end client, while also not forgetting about the technology. The quality of the product heavily depends on technology as well. If we have poor architecture, we won't be able to quickly release features and meet client expectations. There could be many bugs when trying to scale, or during refactoring, we might break something. All of this affects client satisfaction.
From this perspective, the architecture should be such that we can write clean code that allows for quick changes without fearing that we will break everything. Iterations of improvements shouldn’t stretch over several months just because we have so much legacy, requiring lengthy testing phases.
— So far, developers, architects, product specialists, product managers, and testers are already involved. Who else is part of the quality assurance process?
AnastasiaNow, let's assume that we have already delivered the feature to the client. Obviously, we need to monitor the quality of the product, even when it is already in production. At this stage, situations with non-obvious scenarios, known as bugs, may arise.
The first question is how we handle these bugs after we have released the product? How do we, for example, respond to load? The client will not be very pleased if the page takes more than 30 seconds to load.
This is where operations come into play or, as it is now called, DevOps. In fact, these are the people responsible for the operation of the product when it is already in production. This includes various types of monitoring. There is even a subtype of testing called production testing, where we allow ourselves to skip some tests before rollout and test it directly in production. This is a series of activities from the perspective of infrastructure organization that enable a quick response to an incident, influence it, and fix it.
Infrastructure is also important. There are often situations when during testing, it is impossible to ensure that we really have everything we wanted to provide to the client. We roll out to production and start encountering non-obvious situations. This happens because the testing infrastructure does not match the production infrastructure. This leads to a new type of testing — infrastructure testing. This involves different configurations, settings, database migrations, etc.
This raises the question — is it possible that the team needs to use infrastructure as code?
I believe that infrastructure directly impacts product quality.
I hope there will be a presentation at the conference with a real case. Write to us if you are ready to share from your own experience how infrastructure as code affects quality. Infrastructure as code allows for easier verification of all settings and testing of what would otherwise be impossible. Therefore, operations are involved in the process of developing a quality product.
— What about analytics and documentation?
Anastasia: This is more related to enterprise systems. When we talk about enterprise, such people as analysts and systems analysts immediately come to mind. Sometimes they are called technical writers. They receive a task to write a specification and carry it out, for example, over a month.
It has been repeatedly proven that writing such documentation leads to very long development iterations and prolonged revisions, as bugs are discovered during testing, leading to returns. As a result, there are many cycles that increase the cost of development. Additionally, this can introduce vulnerabilities. We seem to have written exemplary code, but then made changes that break the well-thought-out architecture.
The end result is not quite a quality product because patches have already appeared in the architecture, code is insufficiently covered by tests in some places due to tight deadlines, and there is pressure to quickly fix all bugs. This is all because the initial specification did not account for all the details that needed to be implemented.
Developers are not malicious and do not intentionally write code with mistakes.
If we had initially planned a specification that covered all necessary points, everything would have been implemented exactly as needed. But this is utopia.
Perhaps it is impossible to write a perfect specification of 100 pages. Therefore, we need to consider alternative methods of writing documentation,specifying tasks that bring us closer to ensuring that developers do 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 a design department or a designer on outsourcing. There are often situations when it seems that the designer listened to the product manager and did what he understood. But when we begin the iteration, it turns out that what was actually done is not what was expected: the designer forgot something, did not fully think through the behavior because he is not in the team and not in the context, or the frontend developer did not fully understand his layout. It may require several iterations just because there is a problem with the frontend developer's understanding of the design.
There is also another issue. Design systems are becoming increasingly popular. They are currently trendy, but the benefits of using them are not entirely clear.
I encounter the opinion that design systems, on one hand, simplify development, but on the other hand, they impose a lot of restrictions on the interface.
As a result, we end up creating not the feature that the client wants to receive, but one that is convenient for us, because we already have certain components available to build it.
It seems to me that this topic deserves attention, and we should consider whether in our attempt to simplify the design process we are truly addressing the client's pain points.
— It turns out there are surprisingly many topics related to Quality Assurance. Is there a conference in Russia where all of these can be discussed?
Anastasia: There is an old conference on testing, 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. Usually, the presentations at SQA Days delve deeply into specific areas of responsibility of the testers themselves, but not into comprehensive events.
This really helps to understand various tools and approaches, such as how to test databases, APIs, etc. However, on the one hand, it does not motivate involving more than just testing in creating a higher quality product. On the other hand, testers do not become more engaged in the process to think about the global goals of the product and its business aspects.
I lead a large department and conduct many interviews, which actually provide a representation of the state of the industry as a whole. Typically, our guys work in enterprise-level projects, and they have clearly defined areas of responsibility. Colleagues working on foreign projects use various types of testing: they can conduct load testing, performance testing, and sometimes even security testing, because they genuinely help the team ensure product quality.
I would like our guys in Russia to start considering that the industry does not end with functional testing.
— This is why we are organizing a new conference, QualityConf, dedicated to quality as a holistic discipline. Can you tell us more about the concept and the main goal of the conference?
Anastasia: We want to create a community of people interested in making quality products. We want to provide a platform where they can come, listen to presentations, and leave the conference with a concrete understanding of what they need to change to improve quality.
I often hear requests from consulting about what to do when there are problems with testing and quality. When you start talking to teams, you see that the issue isn’t with the testers themselves, but rather how the process is structured. For example, when developers believe they are only responsible for writing code, their responsibility ends the moment they hand off the task for testing.
Not everyone thinks about the fact that poorly written, low-quality code with bad architecture poses significant risks to the project. They don't consider the cost of mistakes, the fact that bugs that reach production can result in substantial expenses for the company and the team. There is no culture of thinking about this. I want us to start spreading this culture at the conference.
I understand that this is not an innovation. Edward Deming, the author of the 14 Points of Quality, wrote about the cost of mistakes back in the last century. Quality Assurance, as a discipline, is based on this work, but unfortunately, modern development tends to forget about it.
— Will you address topics directly related to testing and tools?
Anastasia: I expect there will be presentations about tools. There are quite universal tools that companies and teams can use to impact the product.
All presentations will be unified by one common mission: to convey to the audience that through this approach, tool, method, process, or type of testing, we have influenced product quality and improved the customer's life.
We certainly will not have presentations about tools for the sake of tools. All presentations included in the program will share the same goal.
— Who do you think will be interested in what you are discussing, and who do you envision as the guests of the conference?
Anastasia: We will have reports for developers who care about the fate of their project, product, and system. This will also be interesting for testers and, I believe, especially for managers. By managers, I mean those who make decisions and can influence the fate and development of the product, system, and team.
These are people who ask themselves how to improve the quality of the product and system. At our conference, they will learn about various sets of activities and will understand what is currently wrong and what needs to change.
I think the main criterion is to understand that there is an issue with quality and to want to influence it. We probably won't be able to reach those who think that everything is fine right away.
— What do you think, is the industry ready, in general, to talk not just about testing, but about a culture of quality?
Anastasia: I believe it is. Many companies are now moving away from the traditional Waterfall approach towards Agile. There is a focus on the customer, and people in teams are genuinely starting to think about how to create a quality product. Even in enterprise companies, there is a reorientation towards improving quality.
Judging by the number of requests coming from the community, I think it's time. I'm not sure it will be a massive revolution, but I would like this shift in consciousness to happen.
— Agreed! We will promote the culture and shift the mindset.
Conference on quality development of IT products there will be in Moscow on June 7. You know what stages make up a quality product, we have case studies of successful bug battles in production, we've tested popular methodologies in practice— we need your experience. your applications by May 1, and the Program Committee will help focus the topic for the overall integrity of the conference.
Join the , where we discuss quality issues and the conference, subscribe to , to stay updated on program news.
Source: habr.com
