Vitali Skadorva: “If a dashboard cannot tell you what failed, why, and whether the failure matters, GenAI will only make the dashboard busier.”

43% are still experimenting. Only 15% have scaled. These figures come from the World Quality Report 2025–26 and describe the current use of GenAI in quality engineering. The distance between the two numbers is the real story. Many companies are trying to bring AI into testing before their test architecture is ready for it. Faster releases, more complex products, AI-assisted workflows, and reliable engineering decisions all depend on the same foundation: test systems that are fast, stable, and built to scale. 

To understand what that foundation looks like in practice, we spoke with Vitali Skadorva, a quality engineering architect, SDET, Cypress ambassador, author, and test automation specialist with more than 15 years of experience across insurance, e-commerce, enterprise software, digital security, media, and AI platforms. He is the author of a technical book on Cypress-based web automation testing that reached #1 bestseller status in its category on Amazon, a major global online book platform. Vitali developed the Layered Test Decomposition Methodology and applied it across insurance, e-commerce, enterprise AI, digital security, and media platforms, reducing regression runtimes by 85–95%. At Canada’s largest property and casualty insurer, he cut a regression cycle and brought flakiness close to zero. Vitaly presented the methodology at professional conferences in 2025, won the Cases & Faces 2026 International Business Award in Achievement in Engineering, and was appointed a Council Member of the Association of Information Technology Experts. 

Vitali, many organizations are experimenting with GenAI in quality engineering, but far fewer have scaled it. In your experience, what has to be fixed in the testing process before AI can actually make quality engineering faster?

I have seen situations where leadership wanted to bring AI into testing because releases were taking too long. That request made sense. But the real problem was that the existing suite did not clearly show release risk. If a dashboard cannot tell you what failed, why it failed, and whether the failure matters, GenAI will only make the dashboard busier. So the testing process first needs predictable environments, reliable test data, clear ownership of each layer, strict pass/fail criteria, and reports that point engineers to the source of the failure. Once that foundation exists, AI can actually help with test authoring, code review, failure grouping, and orchestration.

In one of Canada’s leading insurance companies, you redesigned framework architecture across multiple products and reduced regression runtime from about five hours to 30–45 minutes. What did that transformation change for engineering teams beyond the test execution time itself? 

The biggest change was the feedback cycle. When regression takes five hours, it is no longer part of development. It becomes something the team waits for, usually late in the process, when fixing defects is already more expensive. Once the suite became faster and more stable, testing moved much closer to the actual engineering work.

That altered how teams used automation. Developers could get meaningful feedback sooner. QA engineers could spend less time investigating false failures and more time improving coverage. Product owners had more confidence that a release was being validated consistently. The value was that the results became usable again. We also improved maintainability. Standardizing framework structure, configuration, fixtures, custom commands, CI pipelines, and reporting meant that teams did not have to solve the same problems separately. A good automation framework should not depend on one person remembering how everything works. It should give the whole team a clear way to build, run, debug, and extend tests.

Unlike a general testing pyramid, your Layered Test Decomposition Methodology gives teams a repeatable way to decide where each check belongs, whether at the UI, component, API, integration, or end-to-end level. Why does this kind of architectural decision-making matter for modern quality engineering?

In modern quality engineering, the main question is not how many tests a team has. It is whether those tests give the right signal at the right time. Many automation suites grow by accumulation. A new feature is released, another end-to-end test is added, and after a few years, the team has a large regression suite that is slow, fragile, and hard to read. It may look like coverage, but in reality, it often creates delay and noise.

The architectural decision is about placing each check where it can be validated with the least complexity and the highest diagnostic value. If a simple business rule can be tested through an API or component test, there is no reason to run the full browser flow just to confirm it. The end-to-end layer should be reserved for scenarios where the complete user journey is the actual risk.

This also reduces duplication. When the same rule is checked through many user paths, the suite becomes heavier without becoming more useful. A layered approach maintains broad coverage while removing unnecessary repetition and making failures easier to understand.

That matters because teams now release too frequently for automation to behave like a slow final checkpoint. Tests need to run continuously, fail for clear reasons, and help engineers see where the product risk is. When checks are placed at the right level, regression becomes faster, maintenance becomes lower, and release confidence becomes based on evidence rather than the size of the test suite.

You presented this methodology at ConFoo in Montreal and QA or the Highway in Columbus in 2025. What kinds of questions from other engineers showed you where the industry still struggles most with modern test automation?

Engineers already know there are many tools: Cypress, Playwright, Selenium, REST Assured, Postman, and others. People asked how to move from a large existing E2E suite to a more balanced architecture without stopping delivery. That is where many teams struggle.

Some questions dealt with ownership. If a check moves from E2E to component testing, who owns it — QA, developers, or both? If API tests become part of the regression strategy, who maintains the contracts and test data?

I also heard a lot of concern about convincing management. A slow suite is visible, but the architecture problem behind it is not always visible to non-technical stakeholders. That is why I try to explain automation in operational terms: release time, stability, maintenance cost, and confidence. When people understand that poor test architecture slows the whole delivery system, the conversation changes.

In April 2026, your methodology won the Cases & Faces 2026 International Business Award, making you the best in Achievement in Engineering in the category “Consumer Services." From your perspective, what separates a useful testing methodology from a good internal engineering practice that works only inside one company?

A useful one has to survive outside the environment where it was first created. Many internal practices work because one team has a specific product, specific people, and specific habits. That can be valuable, but it is not yet a methodology.

For an approach to be useful more broadly, it needs clear principles, a repeatable sequence, and measurable outcomes. It also has to be independent of a single framework. I work with Cypress and Playwright a lot, but the methodology is not “use Cypress, and everything will improve.” The real question is how to decide what belongs at each test level, how to structure the pipeline, how to reduce false failures, and how to make results useful for engineers.

When you were appointed a Council Member of the Association of Information Technology Experts, your role expanded into several forms of expert evaluation, including judging, code reviews, and an invitation to review a technical book. What responsibility comes with evaluating other professionals’ work while continuing to develop your own engineering approach?

The responsibility is to apply evidence-based judgment consistently. In engineering, reputation should come from work that can be examined: systems built, problems solved, results measured, teams improved, and knowledge shared. In the AITEX Council Member role, this means reviewing expert submissions, assessing professional achievements and technical evidence, and contributing to discussions about professional standards.

When I evaluate another professional’s work, I cannot rely on titles or polished descriptions. I need to understand what was actually built, what problem it solved, how it was implemented, and whether it created measurable technical or business value. The same principle applies to code reviews, judging roles, and technical book reviews.

This connects directly to quality engineering. A good test architecture produces clear signals, and professional evaluation should do the same. The criteria must be clear, the evidence specific, and the conclusion defensible. For me, this role is about professional accountability. if I evaluate others by evidence and impact, I have to hold my own work to the same standard.

What should the next generation of quality engineering frameworks be able to detect or prevent that today’s automation systems still miss?

The next generation of quality engineering frameworks should detect more than functional failure. They need to catch unstable test data, weak assertions, permission risks, accessibility regressions, insecure user flows, and AI-generated code that passes a test but violates expected product behavior. AI will be useful where it reduces repetitive work: drafting tests, reviewing code, grouping failures, and suggesting coverage gaps. The critical part still belongs to engineers, defining risk, setting acceptance criteria, and designing a framework that produces signals the team can trust.