Programme

For decades, automation has made digital products more reliable by removing routine work, reducing mechanical errors, and making processes predictable. AI accelerates this shift by taking on not only execution, but also task interpretation.

As people and AI increasingly create outcomes together, errors no longer have a single clear source. A system may execute a command correctly yet misunderstand intent, lose context, or suggest a convincing but shallow solution. This raises a new question: not only who made the mistake, but whether it was a mistake at all.

This talk explores the evolution of error through design and customer experience—from familiar defects to failures of interpretation, context, trust, and shared decision-making. We will consider which errors automation removes, which it creates, and how digital-product quality should be defined today.

We'll discuss not only the results but also the challenges we encountered: VM templates, state storage, idempotency, configuration management, access rights, the cost of errors, and the resistance to manual habits. This talk will be useful for QA, DevOps, SREs, developers, and team leaders who want to achieve predictable test environments and reduce manual operations.

The use of AI has dramatically accelerated development: working with AI agents, a senior can complete an annual team project in a couple of months. Code creation is no longer a bottleneck - the constraint has shifted to task assignment, which means a change in processes and the role of IT. You need to new manage now, when testing a hypothesis takes a couple of days instead of three months. But engineers are try to adopt old concepts like requirements or CASE tools, creating SDD and Disrupt-PDCL.

Real practice follows a different path. Specifications are stalled due to the volume and complexity of verification. Instead of ideas or requirements, businesses bring prototypes created by vibecoding without specifications. But, business is ready to formulate acceptance criteria and QA can become a key role.

 We will discuss how IT processes are being transformed and how, using agentic engineering, we will create hybrid teams of people and AI agents to quickly and reliably solve problems.

How do you test an IoT integration from scratch when there are no test cases, you have to assemble and configure the hardware yourself, and some of the bugs literally turn into a hellish noise?

In this talk, I’ll share my experience testing an intercom integration with a smart home app, including answering intercom calls through an Alice-enabled smart speaker. I’ll take you behind the scenes: from visiting real-world locations and building our own test setup to configuring hardware, investigating unexpected audio echo, and designing E2E scenarios from scratch. I’ll also talk about what my role as a QA engineer looked like when testing went far beyond simply following predefined test cases.

This is a story about navigating uncertainty: turning chaos into a clear testing strategy one step at a time, stepping outside the usual QA routine, and learning to enjoy the kind of tasks where, at first, you have absolutely no idea what you’re doing.

As a project grows, the number of automated tests only increases: new scenarios are added, and old ones are almost never removed. Regression run times increase and sooner or later become a bottleneck in the entire development process.
At some point, parallelization and new runners stop helping—systematic optimization is needed. But to optimize, you first need to measure.
I'll share how we solved this problem on a large project: we collected automated test execution metrics in Prometheus.

In this talk, we'll explore how, using metrics, we can:

- find the most time-consuming tests, individual steps, and data preparation;
- detect redundant and duplicate checks;
- reduce regression run times without losing coverage.

The IT recruitment market is experiencing one of its most severe crises: fewer vacancies, higher competition, and job searches stretching over months. But that's not all—your resume is now being evaluated not only by humans, but also by AI agents. 

This talk explores how modern recruitment works, how selection algorithms are configured, and how candidates can adapt: properly package their experience, pass automated filters, and become visible on the market again.

A practical 90-minute workshop for testers: how to design test cases for a legacy system for which documentation is missing or unreliable.

Participants master reverse engineering methodology (passive analysis of DDL, VCS, logs, and migrations; active analysis through SQL experiments, tracing, and API tools) and then work in groups to analyze four different legacy scenarios (e-commerce, airport, bank, warehouse) with intentionally introduced anomalies—hidden statuses, desynchronized calculated fields, and "blind" triggers.

The outcome of the workshop is not an essay or a set of hypotheses, but a ready-made set of tools and methods that can be immediately used.

Our team had a constant conflict: developers forgot to set the data-testID, testers couldn't write stable tests (and we weren't allowed to write testIDs ourselves), and time was wasted searching for “where is this ID?” Developers considered this a chore. We created GenTestID, a CLI tool that automatically sets the data-testID in all Vue/React components with a single command. A few seconds—and it's done. No disputes, no routine, no forgotten IDs.

I’ll share a story how we conducted comparative testing to help the client make a choice in favor of one of the vendors as part of import substitution. We sequentially tested two systems and had to choose the better one. When there are many stakeholders in a project and each has different goals, tension will inevitably arise. Our case was no exception. The current vendor kept running into problems, and the client kept changing their position. It felt like we were in Game of Thrones… The team’s motivation was dropping, emotions were running high, and something needed to change. But how do you support your team when you yourself are on the verge of collapse and need to try to maintain neutrality?

In my presentation, I’ll share my own life hacks and talk about specific steps for working with the team and interacting with the client and vendors. The combination of these techniques is useful in any project involving clients from various industries, helping to achieve results effectively.

Load testing still requires expertise: writing a script, performing correlation, compiling a scenario, and then analysing the results. Because of this, load testing remains a narrow concept, accessible to few. We will explain how artificial intelligence can manage the entire process—from a natural language test case to final test conclusions. Using the NTBot platform as an example, we'll explore what has already been automated and how the process stays manageable and transparent for the project team.

I’ll show how the “Machine Spirit” AI methodology expert helps newcomers navigate a project without up-to-date documentation: it finds relevant code examples, follows team conventions, and guides them through their first automated test.

I’ll explain how expert knowledge becomes living project memory, training materials, and a bot in messenger.

As a result, automation has grown from a two-person responsibility into a team-wide practice—while validation and final responsibility remain with human experts.

Just a couple of years ago, the testing process seemed well‑established and straightforward, but everything changed with the advent of artificial intelligence in our lives. AI agents have significantly sped up our routine tasks, but they have also introduced many mysteries and uncertainty in key questions: “Who made the changes?”, “Why do we need three duplicate cases?”, and, finally, “Why was the bug missed?”.

And it’s not about the quality of the models. With a good context, AI is quite capable of performing good checks. The problem is that we cannot check and verify exactly what it did.

During our report, we will discuss:
• How we streamlined the testing process by breaking it down into several stages.
• How storing cases in Git and the “Tests-as-Code” approach helped us with this.
• Why the TMS continues to play a key role in ensuring quality.

We will also define the areas of responsibility: what can be entrusted to AI, and what still needs to be handled by a person.

I am a practicing conflict resolution specialist with experience resolving international business conflicts and internal corporate conflicts at the top management level at major Russian IT companies. 

My master class will be useful for anyone who wants to learn: 

• how to argue with colleagues so that your relationships don't deteriorate; 

• how to disagree with management so that your value in their eyes only increases; 

• how to handle conflicts with subordinates so as not to lose credibility with your team.

They were virtual machines, pods, and containers! Pods, containers, and virtual machines! They took over the whole planet! Judgment Day was coming! But the wise people remembered that everything has its pros and cons, and convenience comes at a price. So in the talk, we’ll discuss how we ended up needing to build our own bare-metal test stand, what we gained, what we lost, and how we justified the resources spent to management.

AI can already generate code, migrate automated tests between languages, build prototypes, identify root causes of problems, and turn test cases into automated test templates. In practice, it changes the QA automation process itself and the engineer's role.

In this talk, I'll share my experience using AI in test automation: migrating end-to-end tests from Java to .NET, rapid prototyping libraries, generating scenario-based tests, identifying root causes, and developing an internal repository of AI practices for testing and requirements.

I'll show you where AI is useful: in routine conversion, sandbox experiments, documentation, and hypothesis generation. And where it's dangerous: in core architecture, complex logic, final review, and decisions made by humans.

The main focus is how to integrate AI into the engineering process to speed up routine tasks without losing control over quality: through diff metrics, benchmarks, areas of responsibility, a platform-based approach within the team.

Burnout among QA engineers is a systemic issue. While many attribute it to crunch periods before releases, the problem is often driven not just by workload, but by a culture of silence within teams — where speaking openly about problems and risks is simply not the norm.

For QA, this is a critical issue, as raising early warnings and helping prevent incidents is one of a QA engineer’s core responsibilities. This culture of silence is shaped by the leader — through their response to uncomfortable questions, bad news, and disagreements.

In this session, we will explore why control in QA creates an illusion of manageability, while in reality reducing personal accountability and increasing hidden risks. We will discuss why a blameless postmortem will not help if people were afraid to speak the truth before an incident happened. Most importantly, we will look at how to recognize when a culture of silence has already taken hold in your team and discuss 7 concrete steps that can help change it.

The most important words before the peak season: "Our service is a rock. It's independent of other services, and we can easily survive their degradation." Sounds like honey. Until you try it. 

In this talk, I'll tell you how, one day, I doubted something and opened Pandora's box—and how it all ended. We'll discuss the history of implementing a new approach, reassessing dependencies, and how to prevent your service from following the Titanic's fate by colliding with an iceberg.

Product analytics is the data that drives business decisions: launching A/B tests, evaluating conversion rates, and allocating budgets. But if events are sent incorrectly, all of these decisions become misleading.

In this talk, the X5 QA team will share how we built a risk-based process for validating product analytics as part of testing. We prioritized events and parameters, automated the generation of expected data and deterministic comparison against AppMetrica reports, and designed a target architecture for fast event retrieval from ADB and the iOS system console. We will also discuss the safe role of AI: generating draft contracts and automated tests, identifying coverage gaps, and diagnosing test failures.

AI has learned to turn requirements, meeting notes, and documentation into a ready-to-use backlog complete with epics, acceptance criteria, and estimates. Task creation has sped up dramatically, making tasks look uniform and seemingly more complete. The catch is that "seemingly complete" and "correct" are not the same thing. Using a real-world project as an example, I will show where AI-generated tasks actually help QA and where they slip in made-up requirements, miss business constraints, and mask ambiguities behind confident phrasing.

In this talk: A checklist for verifying AI-generated tasks. A ready-to-use prompt that QAs can use to double-check task descriptions with that same AI. A breakdown of why QA now has to test three levels instead of one: the task against the source material, the acceptance criteria against business risks, and only then the actual implementation against the task.

In this workshop, we'll build a simple QA agent: connect a model, a processing cycle, a skill, and an MCP to a test TMS. We'll run it, see what it does, and work together to identify any errors. We'll try to fix them by editing the skill. Finally, we'll discuss how to test the agent before launching it into production.

Just a few years ago, QA's primary responsibilities were finding defects, writing test cases, and automating checks. Today, this is no longer sufficient. The role of QA is rapidly changing: quality assurance specialists are increasingly expected to be responsible for product quality, participate in decision-making, utilize artificial intelligence in their daily work, and influence development processes.

Based on the results of the Russia Quality Report 2025–2026 study, the report examines three key changes that are already transforming the QA profession: the transition from testing to quality management, the practical application of artificial intelligence in engineering, and a shift in focus from the quantity of automated tests to the maturity of engineering processes. 

The report will be useful for testers, QA leads, and managers who want to understand how the profession is changing and which skills are already in demand.

In this talk, I will explain how the Smart Camera mobile team used an AI Skill to identify test cases affected by code changes before a task was handed over to QA. We faced a recurring issue: tasks often reached testing with defects in basic user scenarios because finding the relevant test cases in Allure TestOps was time-consuming and required additional communication with QA. Our AI Skill analyses the merge request diff, identifies potentially affected functionality, and provides developers with a list of related test cases, direct links, required test artifacts, and automation status. This enables developers to verify non-automated scenarios themselves and fix any defects within the same merge request, helping us reduce the number of acceptance bugs and task returns while making pre-QA verification a systematic part of the development process.

We completely rethought our release process. By redesigning workflows, introducing QA gates, expanding automation, and integrating AI agents, we reduced our release cycle from 2–3 weeks to 2 hours while decreasing the number of people involved from five to one.

This talk is based on real experience transforming the release process in a product team. I'll share practical solutions, their limitations, and the lessons learned.

In this talk, I'll cover:

• how to identify the real bottlenecks in a release process;

• which QA gates accelerate releases and which add bureaucracy;

• how to embed quality control directly into CI/CD;

• where AI agents genuinely improve the release process and which tasks can already be delegated to them;

• which metrics enable confident release decisions without endless meetings and approvals.

The result was a release process that went from 2–3 weeks to 2 hours, where a single engineer can perform work that previously required coordination across an entire team.

This approach helps align integration testing expectations across development, maintenance, and business teams, making it more understandable, measurable, and manageable. In addition to providing transparency into current coverage, the model helps improve the quality of change analysis: quickly identifying affected contracts, scenarios, risks, and checks, and, as a result, more accurately calculating the scope of required testing.

Blockchain products are not just about enjoying a new technology; they are full-fledged systems with the most unusual and outlandish challenges: event consistency, asynchrony, race conditions, and irreversible operations. In this talk, we'll explore why traditional QA approaches no longer work in blockchain systems, how strategies for smart contract and infrastructure testing are evolving, and what practices help make such products more testable and maintainable.

Communication in QA teams is more than just exchanging information. It’s a space where the same interaction patterns play out every day—often with surprisingly dramatic results. Psychologist Eric Berne called these patterns “games.” Not games in the fun sense, but recurring behaviors that lead to predictable—and usually negative—outcomes.

Dismissed bug reports, defensive reactions to feedback, endless requirement clarifications, constant conflicts on calls.

Sound familiar?

Everyone plays a role, but the outcome is often predictable: people get frustrated, communication suffers, and so does product quality.

But what if, instead of fighting these patterns, we flipped the approach and used games consciously?

In this talk, we’ll explore several game-based exercises that work as soft-skills training. We’ll look at where meaning gets lost, how to ask better questions, and how to explain complex things in simple terms.

Why does one bug with the same severity get fixed in an hour, while another hangs around for two weeks? We often attribute this to team dynamics, human error, or unfortunate circumstances. But behind many of these stories lies the architecture of the process itself.

During the practical workshop, you'll take your real-life QA process—defect flow, triage, regression, release readiness, or incident escalation—and literally dissect it: break it down by operation type, identify decision points, and examine how responsibilities are distributed.

Then we'll crash-test the process using AI: we'll see which operations can be safely automated, and where automation would merely mask the problem or exacerbate an existing risk. By the end, everyone will have a map of their own process, tools for diagnosing it, and a formulation of one of its problems.

Rolled out AI in your QA processes, but something's off?

• The agent runs slow.
• Results are inconsistent, depending on the model's "mood."
• Burns through tokens — with little to show for it.
• Prompts longer than "War and Peace."

Sound familiar? Let's fix it.

I'll share my hands-on experience building an efficient context-retrieval system for QA, using one of the most challenging domains — information security — as a case study.

We'll break down each context source and how to work with it individually, then assemble them into a single system — fast, consistently high-quality, and token-efficient — robust enough to support QA agents at every stage of their work.

Managing test data is one of the most painful problems in test automation, especially in large fintech projects with dozens of microservices. In this talk, we'll walk through the full lifecycle of test data: from generation via factories to wiping and rollback. We'll show how to organise parallel runs without collisions, and why external mock services with auto-cleanup and lifecycle management are needed. Why the application architecture directly determines your test data strategy in cases where mocks alone are no longer enough.

The world is changing rapidly: the familiar is ALREADY not working as effectively as we'd like, and the new is YET not working as well as we'd like. It seems that the old identity has ended (or almost ended), and a new one hasn't yet been found.

What will we cover in this presentation?
- We'll learn a new word: "liminality."
- We'll receive specific tips on how to act in this state: we'll explore how liminality differs from ordinary uncertainty.
- We'll discuss how we try to compensate for this state and why it doesn't always work.
- We'll receive practical guidelines: what to do here and now to maintain resilience in a world where adaptation fails to keep up with change

This report chronicles the life of a tester at a single company, from the moment he interviewed for the position to being widely recognized as an expert. Together, we'll experience his successes and failures, joys and doubts. We'll see how people at the company helped him, supported him, and were there for him during difficult times. We'll learn about the processes that motivated him to grow within this company alone. 

Managers will learn about ways to motivate and retain testers, while testers will learn about development opportunities within a single company. 

The characters and events are genuine, and any similarities are intentional.

AI-powered test case generation has long ceased to be an experiment and has become a distinct marketplace of tools. However, beautiful demos often conceal issues of quality, trust in the results, and actual effectiveness. In this talk, I'll share practical experience in implementing AI in testing processes: what has been accelerated, what approaches haven't worked, and why the number of tests generated isn't an indicator of success.

Using the development of TestWriter as an example, we'll explore key performance metrics, the "AI tests AI" approach, typical implementation mistakes, and the limitations of modern solutions. This talk will be useful for those who want to use AI in testing consciously, rather than following the latest hype.

Automated tests of complex business logic often produce false positives and missed defects due to improperly prepared test data. In this talk, I'll demonstrate a practical approach to preparing data for automated tests using discount logic as an example: how to translate business rules into a compact dataset using test design techniques and how to organize data creation using a test framework. We'll also cover typical causes of instability: conditions falling within the wrong range, hidden parameter dependencies, “dirty” data between runs, and parallel runs. I'll also demonstrate how to implement data isolation and clean up to ensure repeatability and unambiguous error diagnostics.

When an AI agent takes on tests, it appears confident and almost always makes big mistakes. Run it through your code, and it writes a neat “test” that doesn't check anything. It marks red as green, passes off a bug as a feature, and even accepts an incorrect result as correct.

We experienced this ourselves: we transformed a set of disparate scripts into a system of agents with a clear division of roles. Along the way, we had to answer nine awkward questions—exactly the same ones that are the topics of this talk. What is considered a bug, and what is a feature? How do we deal with old services without documentation? What happens when a model is changed?

This talk is a map of our experience, not a textbook: an analysis of real problems and specific solutions.

The presentation highlights the importance of data masking on non-productive environments for development and testing. What approaches are there to implement depersonalization and what may be the pitfalls of different approaches? Why exactly is testing the most important competence in creating consistent impersonal data in test environments and how it can be "sold" to customers and stakeholders.

Traditional security focuses on code, services, and protocols. However, most successful attacks are based on social engineering, which hacks not software but the human mind.

This masterclass shifts the focus from purely technical security to psychology: you'll learn how manipulators bypass the critical thinking of even the most experienced professionals.

The program includes:

⦁ The Psychology of Deception: a detailed analysis of the cognitive biases, emotional triggers, and time pressure used by telephone and online scammers.

⦁ The Anatomy of Errors: Why high intelligence, status, and IT experience don't provide immunity to manipulation and how to take this into account when designing security.

This masterclass will help you view a product through the eyes of social engineering, identify unusual vulnerabilities at the intersection of UX and security, and improve your personal psychological preparedness.

The developers have written tests, everything is green.

What should QA do now – repeat the same checks? I propose a different approach: look not at the number of tests, but at what important system properties they actually test and what remains outside the tests.

We'll explore how to turn a simple requirement into several testable assertions, how to analyze developers' tests and find missed states, errors at the interfaces of systems, crashes, and other blind spots. We'll also look at how to recognize after a release that an important system property has been violated.

Finally, we'll put together a simple algorithm that can be used during a regular review of a task or code changes.

LLM agents are “blind” to the actual browser, while raw DOM data overwhelms the context and is unstable. The solution lies in an architectural shift toward the Accessibility Tree (achieving a 10x reduction in size) and standardised control via MCP Playwright.

The talk covers:

MCP tool categories (navigation, interaction, data, sessions), integration with SberBrowser, and escaping issues in GigaIDE. We will present live use cases: creating a temporary email address on fex.plus and a “test-fixer” agent that repairs locators based on error messages. We will discuss MCP pain points—specifically token consumption and LLM non-determinism in CI/CD pipelines—and a hybrid MCP + CLI approach as a way forward. Finally, we will demonstrate multi-agent networks featuring an orchestrator and self-healing capabilities driven by multiple

QA engineers constantly look for defects, challenge assumptions, and explore how systems can fail. Yet leadership decisions — often the most expensive and far-reaching decisions in an organization — rarely go through a similar process.

What if we applied familiar SQA practices to management decisions: peer review, edge cases and other? This talk explores why leaders struggle to get an honest second perspective, how that affects decision quality, and how organizations can introduce Management Review — not to approve decisions, but to challenge the thinking behind them before they reach “production.”

All tests are green, the coverage percentage is high, and the agent responds to the user something like, "I don't have such a tool." The tool does exist. It's covered by tests. The bug isn't located in any line of code. 

This is the biggest surprise MCP servers offer QA: their primary user isn't a human or another service, but an AI agent. The model doesn't "connect to the API"—it reads. All it sees about your server is text: the tool name, description, and parameter schema. This means the contract now consists not only of the schema but also of text, and changing one word in the description changes the system's behavior in production.

In this report, we'll look at how an agent selects a tool and where the scenario breaks down: the agent didn't select your tool, called it with the wrong arguments, or misunderstood the response.

Test-Rex is a prototype system for generating automated tests based on LLMs, utilising RAG search across the project's codebase and existing tests. The system accepts a textual description of a user scenario, extracts relevant context from the repository, creates prompts using templates, and generates executable test code. The talk will cover the solution’s architecture, indexer implementation, and quality criteria for generated tests. Limitations and future development directions will also be discussed.

AI can already write code, generate tests, find defects, and analyze results. More and more of a tester's technical work is becoming automated.

However, a paradox arises: the more AI can do for a tester, the more valuable are skills that can't be reduced to generating yet another test case.

In this talk, we'll discuss which QA engineer skills are becoming most important in the era of AI agents. For example, critical thinking and the ability to ask the right questions and set the right tasks have been relevant for many years. And even as the tools we work with change, they remain equally or even more in demand.

We have never had so many tools for ensuring software quality: static analysis, thousands of tests, quality gates for every change, AI, and automation of routine tasks. It would seem that the quality of software products should only be improving.

Yet some people are noticing the opposite. We increasingly expect familiar services to let us down, while new releases seem to bring more disappointment than value.

Is this really the case, or have we simply become more demanding?

In this roundtable, we will discuss how software quality is changing under the influence of economics, competition, product strategies, and AI. We will look at the issue through the eyes of both engineers and users, compare the experiences of different generations of professionals, and try to understand what a “quality product” means today — and where we are heading next.