Written by Spencer Hulse
In 2026, many corporate IT products are undergoing a reassessment of their engineering processes. Solutions that only a few years ago were built quickly and under constant deadline pressure are now expected to operate reliably, scale without disruption, and withstand frequent change. Against this background, processes aimed at preventing defects and ensuring high software quality throughout all stages of development—Quality Assurance, or QA—are no longer limited to finding bugs before release. Increasingly, the challenge lies in creating an infrastructure that helps a team understand risks, make release decisions, and preserve the predictability of development.
Daniil Khudenko works at the intersection of engineering quality management, corporate software development, and release stability in complex IT products. His expertise is connected with building QA infrastructure from the ground up: from the product testing model and regression coverage to release-readiness criteria, team onboarding, and defect analysis as a source of data about weak points in the process. His experience includes enterprise projects in banking, infrastructure, and industry-specific software development, where quality is defined not by the number of bugs found, but by the team’s ability to release changes predictably, understand risks, and avoid losing control over the product as it grows.
In this interview, Daniil discusses how mature QA infrastructure emerges in corporate development: where systematic testing begins, why automation cannot replace process, and how a team learns to make decisions about quality not on the basis of impressions, but on data.
Daniil, when a company says that it needs to “build QA from scratch,” that phrase can mean a lot of different things. How do you assess a project during the first weeks, and what, for you, is the key sign that QA infrastructure is absent?
In the first weeks, the focus is not on whether there are testers on the project, but on whether the team has a manageable quality process. Sometimes checks formally exist: someone goes through the main scenarios, someone creates bug reports, something is quickly reviewed before release. Yet if there are no common rules—how defects are described, what data is attached, where test cases are stored, how priority scenarios are selected, and who makes the decision about release readiness—then QA, as infrastructure, is not yet present. There are separate actions, but no system.
The weak points in the process usually become visible quite quickly. For example, bugs may be logged, but poorly localized: without proper steps, logs, environment details, screenshots, or links to a specific scenario. In that case, the defect has technically entered the tracker, but development still spends time clarifying basic information. The same applies to releases: if a discovered bug is not connected with the cycle of fixing, retesting, and making a release decision, the team is not managing risk. It is simply hoping that something critical will not reach production.
Another marker is the testing model. If test cases are stored randomly, never updated, not linked to requirements or defects, and regression is rebuilt manually “from memory” every time, then the team does not understand its own coverage. Therefore, a TMS, reporting on test cycles, prioritization of scenarios, and selection of candidates for automation are not bureaucracy. They are the minimum basis of manageable QA. When a particular scenario keeps failing, this should be visible in the data, and not established only after another incident.
At this point , it is easy to start implementing everything at once: regulations, test cases, a TMS, reporting, automation. Where do you start so that the team feels QA is helping them, not just adding extra paperwork?
Regulations themselves are not harmful. On the contrary, it is impossible to build a stable QA process without them. The point is different: if several rigid rules are brought into the project at once—rules for bugs, test cases, release acceptance, reporting, automation—the team will almost inevitably feel additional pressure at the beginning. People have to change their usual way of working, describe defects in greater detail, update the testing model, and record the results of test cycles. In the short term this may look like a slowdown.
In the medium term, however, these practices reduce the amount of time spent on testing before release. When test cases are up to date, regression runs on priority scenarios instead of “from memory” , bugs are well localized, and readiness criteria are known in advance – the team spends less time dealing with chaos at the end of the sprint. There is no need to clarify from scratch what must be checked, who is responsible for retesting, which defects block the release, and which risks are acceptable. The process becomes predictable.
The advantage is that the team begins to see quality not through impressions, but through facts. Well-described defects move into development faster; an up-to-date testing model shows problematic areas of the product; and reporting gives management a clear picture of coverage, check status, and release risks. Only on this basis does it make sense to introduce automation thoughtfully: not to automate everything indiscriminately, but to select scenarios that are repeated, critical for the product, and truly save time.
So the point is not to introduce regulations for the sake of regulations, but to gradually build quality discipline. At the start, this does require effort. Yet when the process is built correctly, it begins to return time to the team fairly quickly: less manual rush before release, fewer unclear defects, fewer unexpected failures in critical scenarios, and greater confidence that the product can be released.
In corporate projects, quality depends on many participants, while decisions are often made across several layers at once: the contractor, the customer, development, analytics, and management. How can a testing specialist influence the process in such an environment if the role does not always include direct administrative authority?
In such an environment, QA influence is built through evidence not your formal position. If you do not have direct authority to change the process, you need to show exactly where quality degrades: in requirements, development, integration, acceptance, or immediately before release. When a problem is described as a real product risk instead of “testing is inconvenient,” the conversation becomes much easier.
The usual starting point is transparency: critical scenarios are recorded, repeated defects are shown, areas where bugs are poorly localized are highlighted, and places where the team loses time on clarifications, retesting, or disputed release decisions are made visible. This moves the discussion from a subjective level to a practical one: not “QA wants more rules,” but “here is a section of the process where time is regularly lost, defects are missed, or risk is accepted blindly.”
After that, it is important to propose specific rules that help all participants: a unified defect format, clear acceptance criteria, mandatory scenarios before release, a retesting procedure, and reporting on the test cycle. When it becomes easier for development to reproduce bugs, for management to see the release status, and for the customer to understand residual risks, QA begins to influence the process naturally. Not because “QA said so,” but because the process actually becomes more manageable.
In corporate products, the demand for automation often appears very quickly. How do you determine what genuinely needs to be automated and what, at an early stage, is better left for manual or exploratory testing?
Automation is useful only when it is clear what problem it solves. If chaos is automated, the result is simply faster chaos. For that reason, the starting point is not the choice of a framework. First, it is necessary to understand which scenarios are stable, repeated from release to release, and carry a high cost of failure. These are the first options for automation.
In projects where we introduced automated checks, including Behave and CI/CD integration, the number of tests mattered less than where they fit into the process.. An automated test that runs regularly and gives the team a clear signal is more useful than a large set of tests that no one maintains and trusts. For this reason, maintainability receives considerable attention: anyone on the team should be able to understand a test, not only its original author. There are areas where manual testing remains necessary. These include new functions, complex user scenarios, behavior at the intersection of several modules, and cases where it is important to understand how logical the user path is. Automation should free up time for the checks, rather than create the illusion that product quality can be fully measured by running tests.
When the QA function is just being formed, much initially depends on the person building it. How can the team become independent quickly: understand the product, take responsibility for its areas, or avoid dependence on your personal participation in every feature?
When the QA function is only being formed, a great deal initially does depend on the person building it. But if all decisions constantly pass through one leader, this is not a team; it is a bottleneck. The task, therefore, is to transfer to engineers as quickly as possible both a list of tasks and a way of thinking: how to look at the product, how to identify risks, how to understand one’s area of responsibility, and how to make decisions without constant approval.
Thus, onboarding should not be formal; it should be product-oriented. A new QA engineer needs context: what modules exist in the system, which scenarios are critical, where defects most often arise, how the release cycle is organized, and what rules exist for bugs, test cases, regression, and retesting. Documentation is important here: the testing model, checklists, defect-formatting rules, areas of responsibility, and typical risks. Then a person receives access rights and understands how quality works inside the product.
The next step is the gradual transfer of ownership over specific areas. An engineer should be able to update the testing model independently, see weak points, propose scenarios for regression or automation, and understand when the lead should be involved and when a decision can be made within the engineer’s own area. In a strong QA team, the leader should not be a manual router for every feature. The leader’s task is to build a system in which engineers grow, product knowledge is not lost, and quality does not depend on one person being present in every discussion.
You have worked with different types of digital products, from document management and industry platforms to ticketing, banking, and commercial services. How strongly does the domain change the approach to QA? Is it possible to build a universal testing system, or does every industry require a new definition of what counts as a critical risk?
A universal testing system does not exist in the full sense. There are universal QA principles: a clear testing model, defect management, regression, automation, release-readiness criteria, and reporting. But what counts as a critical risk is always defined by the domain. In one product, an error in a status may be a cosmetic issue; in another, it may stop a process, distort data, or lead the user to make an incorrect decision.
In document management and industry platforms, for example, it is important to test both the screen and the entire path of the object: who created the document, who approved it, what status it has, where the data was transferred, and what happened after integration with an external system.
In ticketing services, the critical chains are those connected with route selection, payment, ticket issuance, refund, and correct display of the operation status.
In banking products, the focus shifts to data accuracy, transaction security, access rights, audit trails, and integration stability.
In e-commerce, the core areas are product search, the cart, payment, discount codes, stock balances, delivery, and failure scenarios.
Therefore, the task of QA is more than just taking a ready-made set of test cases and transferring it from one product to another. It is necessary to quickly understand where the cost of error arises in a particular industry: money, documents, deadlines, access rights, user trust, or process continuity. Everything else is then built on that basis: scenario prioritization, regression, automation, test data, and release criteria. A good QA process always relies on the domain. Otherwise, it checks the interface but does not protect the product.
Daniil, speaking of an ideal testing model in a corporate product, what should it look like? At what point can it be said that QA works not as a set of separate checks, but as a built system?
The first sign of a mature model is predictability. Before release, the team should understand which critical scenarios have been checked, where risks remain, which defects block the release, and which can be consciously postponed. If the picture has to be assembled manually from chats, people’s memory, and scattered lists before every release, QA infrastructure has not yet been built. If the status is visible through a TMS, test cycles, defect history, and clear readiness criteria, the process is beginning to work as a system.
The second sign is an up-to-date testing model. Test cases should not be an archive created for reporting purposes. They must change together with the product, reflect real scenarios, priorities, and risk zones. In this type of model, it is clear what is included in regression, what needs to be checked manually, what makes sense to automate, which scenarios fail repeatedly, and where coverage should be strengthened. Testing then stops being a mechanical passage through a list and becomes a tool for quality management.
The third sign is a flexible team. A good QA model should not depend on one person or narrow specialists who only know one module. Expertise must be shared: engineers can move between product areas, pick up adjacent modules, work in both manual testing and automation, and understand common rules for regression, defects, and release acceptance. This does not mean that all engineers are identical. Rather, the team becomes more resilient: people do not stagnate, knowledge is not locked in one head, and quality does not decline if someone goes on vacation, switches tasks, or joins a new feature.
After the conversation with Daniil Khudenko, one thing becomes clear: QA infrastructure in corporate development is more than just a set of test cases and a formal layer before release. It is a system that helps a company stop losing money on repeated defects, prolonged testing, unclear release risks, and dependence on individual specialists. When the testing model is up to date, defects are well localized, regression is managed, and automation is introduced thoughtfully, the team understands the state of the product faster and spends less time dealing with chaos before release.
The value of Khudenko’s approach lies precisely in the fact that he builds this type of system across different types of enterprise products: banking systems, construction document management, ticketing and transport services, commercial platforms, and products with a large number of integrations. In each case, the domain changes, but the logic remains the same: identify critical risks, formalize quality rules, create a resilient team, and make the process capable of continuing without constant manual control by one person.
It produces a direct economic effect for business: the time spent on regression and defect analysis is reduced, the number of recurring errors decreases, release decisions move faster, and specialists become more versatile. They can move between modules, share expertise, and work in both manual testing and automation. This is the substance of Daniil Khudenko’s contribution: he creates an environment in which quality becomes reproducible, manageable, and financially justified.
