Доклады

Представьте, что вы сделали модель, которая решает вашу задачу с ошибкой меньше 1 процента. Радостный, вы относите её вашему заказчику, а он после своих тестов заявляет, что на его данных ошибка составила 25 процентов.

Вы начинаете выяснять, в чём дело. И оказывается, что у заказчика данные на другом языке, в сами тестовые сценарии вы не вчитывались и вообще система эксплуатировала длину тишины в аудиозаписях для обучения.

Как этого избежать? Как грамотно построить процессы тестирования и сравнения нейронных сетей, чтобы не тратить на тесты больше, чем на обучение? Ответы на эти вопросы, а также о том, как построить инфраструктуру для хранения таких моделей, — в этом докладе.

Я работаю в команде, помогающей использовать Platform V DataGrid максимально эффективно и надежно в сервисах экосистемы Сбера.

DataGrid — это распределенная open-source СУБД. В Сбере её используют полторы сотни сервисов, включая самые важные. Мы обеспечиваем гарантии качества продукта на протяжении всего его жизненного цикла, от разработки в open-source-комьюнити до развертывания на наших серверах, и даже после него! Подходы, применяемые нами при тестировании DataGrid, довольно сильно выходят за рамки типовых, некоторые даже могут выглядеть абсурдными, но только на первый взгляд.

Расскажу, как мы смогли для применяемого нами open-source-продукта обеспечить:
* быстрое исправление дефектов,
* быструю разработку нужной нам функциональности,
* перформанс в важных нам сценариях (throughput и latency),
* безопасность (отсутствие уязвимостей),
* простоту внедрения (уверенность в работоспособности на реальных высоконагруженных окружениях),
* надежную работу в эксплуатации (доступность и сохранность данных);
и какой в этом вклад
* разработки, тестирования, внедрения и сопровождения (кто из них больше тестирует),
* разных подходов к тестированию (включая системное),
* автоматизации тестирования и разработки (снятие с разработки рутинных задач).

* Обзор AI + ML и их влияние на QA-тестирование.
* Симбиоз скорости ИИ и креативности человека — как организовать процесс тестирования 2.0.
* Демонстрация возможностей нейросети для QA-специалиста в практическом применении.

Вы наверняка знаете про концепцию Everything as Code — подход к разработке продуктов, рассчитанный на масштабируемость, легкость управления и переиспользование элементов инфраструктуры и инструментов.

Этот подход нашел применение практически везде: Documentation as Code, Pipeline as code, Deployment as Code и т.д., — только в тестировании все не так радужно. Многие по-прежнему создают тест-кейсы вручную, чтобы потом их автоматизировать. Многие задачи решаются в парадигме ручной работы: переиспользуемые шаги и аттачменты, версионирование тестов, бранчевание.

Многие из этих проблем решаются, если перенести тест-кейсы в код. В своем докладе я покажу, как можно использовать такой подход и какие бонусы он вам даст.

Связку микросервисов функционально протестировать сложнее, чем монолит. Кто-то решает это единым стейджингом и чатиком синхронизации "займу auth на полчасика", кто-то уходит с головой в shift-left, кто-то тестирует в canary.

Несмотря на сотни сервисов, мы реализуем уютненькую возможность катнуть веточку сервиса и получить свой личный стейджинг. В этом докладе расскажу как.

k6 — активно набирающий популярность инструмент нагрузочного тестирования (НТ) с возможностью написания сценариев на почти полноценном JavaScript. Обычная версия распространяется под свободной лицензией AGPL, но есть и платная облачная. И хотя, бесспорно, самым популярным инструментом НТ является JMeter, он устраивает далеко не всех.

В своём мастер-классе, основанном на проведённых мной внутренних тренингах, я скажу пару слов о том, почему мы в компании Miro для НТ продукта с 30M+ пользователей выбрали именно k6, основное внимание уделю совместному с участниками написанию нескольких ключевых для НТ сценариев от простого к сложному, показав в ходе этого основные концепции инструмента, немного расскажу про облачную версию и завершу парой слов о нашем внутреннем решении на основе k6.

Бонусом будет репозиторий с множеством прокомментированных примеров сценариев на k6 для самостоятельного изучения.

Краудсорсинг отличается от аутсорсинга подходом "все врут".

У платформы Яндекс.Толока есть свои встроенные инструменты контроля качества выполненных заданий, но исполнители учатся обходить и их. Я расскажу про то, на какие из них не стоит полагаться абсолютно и какие еще способы контроля качества стоит добавить вне тех, что предлагает платформа, чтобы вы больше были уверены в качестве данных полученных через крауд.

Уже 2022 год, и существует достаточно много решений для тестирования API, каждое из них решает одну задачу: или проверяем вручную, или пишем автотест. Но настоящий путь — это решить обе проблемы разом.
В докладе я расскажу про опыт построения фреймворка для тестирования API.

Это рассказ про то, как мы пришли к этому, на какие "грабли" наступили в процессе проектирования и реализации. Конечно, я расскажу, почему взяли BDD, как кодили на Java, а также про проблемы и подводные камни написания и дальнейшего сопровождения такого продукта.

Любой продакт в компании хочет услышать: «Мы автоматизировали регресс». Ведь в этом случае не придется тратить много времени на долгий ручной прогон. Но на пути автоматизации неизбежно возникает ряд вопросов:
* Какой фреймворк выбрать?
* Как получать отчеты?

Поэтому сравним ряд фреймворков, расскажем, какой выбрали мы и почему. Также поделимся тем, как установить Cypress и Allure.

Доклад состоит из двух частей: теоретической и практической.

1. Теория
* Понимание continious-процессов. Для чего нам нужны тесты, и как мы хотим проводить тестирование и доставлять продукты.
* Модели ветвления: что в итоге окажется на целевых окружениях.
* Как и когда нам может помочь Kubernetes, а когда можно обойтись и без него.

2. Практика
* Если у нас есть Kubernetes в продакшне, как бы нам прикрутить его еще и для быстрого тестирования.
* То же самое, но если у нас нет Kubernetes в продакшне? Используем "легкие" версии k8s, сокращаем накладные расходы.
* Инструменты для CI/CD: GitLab, GitHub Actions, Jenkins.

Автоматическая генерация документации API на базе интеграционных тестов с помощью spring-restdocs (и аналогов).

Если генерить тесты по документации или спецификации (swagger), то получаем высокое покрытие, но люди такие тесты читать не будут — много лишнего и сломан порядок вызовов. Для того чтобы документация была полезна людям, она должна отражать конкретные частые примеры использования: аутентификация, проброс токенов, поиск, просмотр каталога, добавление товара в корзину, оформление покупки на партнерском сайте.

Как же такую документацию получить? Да и чтобы она сама обновлялась и была всегда актуальна?
Очень просто: взять интеграционные тесты API — и разметить их. Добавить туда порядок, примеры, описания полей. Приправить картинками / схемами по вкусу.

Запускаете сборку — получаете pdf, который не стыдно сразу отправить заказчику.

Крупные компании все чаще переходят на микросервисную архитектуру, и к автоматизации тестирования предъявляются все новые и новые требования. Пытаясь угнаться за ними, каждому QA-инженеру каждый раз приходится решать задачу интеграции с существующим CI/CD, собирая свой велосипед. В итоге в общем случае на проекте, где больше 20 микросервисов, мы получаем 20+ вариантов запуска тестов при релизе от 20 инженеров. При этом реализованные решения очень сильно зависят от квалификации QA и плохо поддаются мониторингу и управлению.

Обсудим:
* как снизить порог вхождения QA-инженера в процесс деплоя приложения;
* как обеспечить единообразие тестового инструментария для всех команд, входящих в домен;
* как перейти от зоопарка используемых технологий и кучи велосипедов к единому решению;
* как обеспечить в тестах и инструментарии оперативное выполнение новых требований.

Все, кто погружается в мир автотестов UI, сталкивались с паттерном Paje Object. Но что будет, если мы погрузимся глубже и попробуем применить этот паттерн к API? Или к модели БД? Если Page Object описывает "модель" тестируемой страницы, справится ли он с подобной задачей для других слоев нашего приложения? Можем ли мы применить паттерн для тестирования требований?

В докладе мы рассмотрим ответы на эти вопросы, а также поговорим о следующем:
1. Развитие идеи — моделирование тестируемой сущности при помощи Test Definition Object (TDO).
2. Тестирование требований при помощи TDO.
3. TDO и автогенерация.

И, конечно же, рассмотрим примеры применения в наших автотестах.

Как в Яндексе придумали решить все боли разом:
* тестирование перестало быть "узким горлышком";
* появились комитменты сроков тестирования и даже прогноз в будущем;
* тестировщиков избавили от рутины, утомительного регресса. Дали больше времени на сложные задачи и выстраивание правильных процессов;
* масштабируемость — научились обменивать деньги тестирования на скорость тестирования, покрытие конфигураций, увеличение вероятности качества.

Когда необходимо организовать процесс автоматизации тестирования в большом количестве команд, неизбежно встает вопрос: как избежать разработки собственных "велосипедов" командами, сделать их код единообразным и совместимым и при этом сделать это удобным образом.

В своём докладе я сравню подходы с использованием Maven-зависимостей и Git submodules, обозначу потенциальные проблемы при использовании подмодулей и покажу вариант решения таких проблем.

Зачастую перед QA-инженером стоит задача покрытия функциональности автотестами, при этом без избыточных проверок, по правильной пирамиде. Но, прежде чем начать покрывать бизнес-логику, стоит понять, а что, вообще, можно покрыть на unit-тестах. На этом моменте мы сталкиваемся с разными уровнями абстрактности в мышлении разработчика и тестировщика. Мы узнаем, какие простые шаги стоит сделать для единого понимания, и рассмотрим пользу от этих шагов на конкретных примерах.

В докладе приводится рецепт реализации нагрузочного тестирования на Python.
Помимо демонстрации процесса работы и общего описания, особое внимание будет уделено примерам реализации скриптов и технических задач.

Общее описание подхода:
* для чего и где используется;
* производительность;
* особенности.

Демонстрация скрипта для нагрузочного тестирования:
* подход к написанию скриптов НТ;
* основные классы и методы, необходимые для работы;
* взаимодействие с Python-библиотеками;
* отправка запросов на сервер;
* кастомизация статистики по тесту;
* конфигурирование интенсивности нагрузки;
* pacing.

Запуск тестов, интерфейс:
* процесс и режимы запуска тестов;
* GUI;
* отчеты;
* графики.

За свою карьеру я столкнулся (а некоторые даже попробовал) с рядом антипаттернов тестирования при использовании Spring Data JPA. Они не только не помогают, но усложняют поддержку кода и вызывают раздражение.

В рамках доклада я расскажу вам о таких антипаттернах, как “мокирование” репозиториев, избыточный coupling на декларацию сущностей, лишние зависимости и транзакционные тесты. А также покажу вам паттерны, на которые следует их заменить, чтобы упростить жизнь при написании тестов.

Бизнес-модели клиентов создают разные сценарии использования продукта и разные профили нагрузки. Подготовить под каждого индивидуальную тестовую среду невозможно и не имеет смысла. Достаточно создать усредненный вариант и покрыть там самые популярные кейсы использования платформы.

Расскажу, как был написан PoC Tester — фреймворк для описания логики работы клиентских узлов, которые симулируют реальную нагрузку на тестовый кластер — и какие задачи пришлось решить в процессе:
* как оптимально сконфигурировать тестовый стенд по количеству узлов;
* как добавить в один тестовый сценарий наибольшее количество пользовательских кейсов;
* какие внешние воздействия можно внедрить в сценарий для проверки надежности и устойчивости кластера при возникновении нештатных ситуаций;
* как после прогона настолько сложного сценария понять, что он успешен.

Хранилищем результатов тестов производительности для популярных инструментов является InfluxDB. Это хранилище используется для JMeter, Gatling, Performance Center... И если выполнять тесты производительности регулярно, по несколько раз в день, то вскоре фильтровать результаты тестов производительности становится сложно. Запросы к InfluxDB становятся медленными.

Если команда нагрузки сталкивается с такой проблемой, то возникает необходимость хранения данных так, чтобы они сразу соответствовали фильтрам, а также чтобы приходилось реже выполнять сложные агрегатные функции и получать результаты быстрее.

Это выступление о том, как:
* организовать систему мониторинга ключевых бизнес-процессов;
* поднять свой кластер с сервисами и танками;
* регулярно получать актуальные данные с прода о производительности бизнес-сценариев в автоматическом режиме;
* предоставить сотрудникам компании удобный инструмент для проведения и контроля стрельб на проде.

В процессе тестирования СХД крайне важно эмулировать реальную работу пользователя. При этом надо убедиться не только в отказоустойчивости системы при высоких нагрузках, но и в корректности обработки данных и работы СХД в целом. Для многих СХД активно используются популярные инструменты нагрузки и генерации данных. Однако существуют такие СХД, сложность которых требует собственной автоматизации генераторов данных, например, СХД Dell EMC PowerMax. Такой процесс автоматизации построен на общих подходах к тестированию данных на СХД, учитывая при этом уникальные сценарии тестирования конкретной системы.

Чаще всего пользователи используют СХД Dell EMC PowerMax в качестве файловой системы или для работы с БД. В связи с этим мы определили две соответствующие группы разрабатываемых генераторов данных.

В первую группу генераторов данных мы отнесли те, что симулируют клиентское IO высокой нагрузки. Данные генераторы обладают широким спектром параметров и позволяют настраивать интенсивность IO-процессов, работать с памятью в различных режимах, а также осуществлять псевдорандомизацию процессов записи и чтения данных. Такие симуляторы IO могут существенно «загрузить» СХД, одновременно генерируя данные, что позволяет проводить качественное нагрузочное тестирование системы и проверять корректную обработку данных в критических условиях.

Во вторую группу генераторов данных мы отнесли генераторы с проверкой консистентности данных, так как консистентность на уровне дисковых устройств — это одно из важнейших качеств данных, которое мы стремимся контролировать в рамках СХД Dell EMC PowerMax.

Мы рассматриваем сценарии работы с данными на примере тестирования СХД PowerMax для мейнфреймов, но верим, что наши идеи подойдут для работы с любыми СХД. Мы неоднократно использовали разработанные генераторы в ситуациях, когда требовалось воспроизвести проблему пользователя в лабораторных условиях. Кроме того, грамотное использование генераторов нагрузки позволило нам неоднократно обнаружить ошибки и недоработки ПО СХД на этапе тестирования.

Когда тестов тысячи, очень непросто становится писать хорошие проверки, которые понятны всем в команде и легко поддерживаются. В докладе расскажу, как мы используем FluentAssetions. Посмотрим, насколько удачно она подходит в различных ситуациях, разберем нестандартные подходы проверок и узнаем много нового.

Тезисы:
* Проблемы.
* Немного о самой библиотеке FluentAssertions.
* Базовые примеры использования.
* Дополнительные проблемы и их решения с помощью FluentAssertions.
* Roadmap внедрения FluentAssertions в проект.
* Примеры ассертов для TDD-подхода.

Когда речь заходит об эффективности проекта, то в первую очередь мы говорим о цифрах. Дизайн, разработка, контекст, SEO, SMM и прочее — если ты не анализируешь и не отслеживаешь результаты своих телодвижений, значит, ты полагаешься на случай! Бизнесу важно принимать решения на основе достоверной информации.

Для нашей команды QA-тестирование аналитики было новым испытанием: подобного опыта не было, а тестировать ее руками, еще и в каждом релизе — то еще удовольствие! Но с этим испытанием мы справились один раз и наверняка. В решении этой задачи нам помог наш опыт автоматизации и уже существующие автотесты, которые следовало лишь слегка доработать.

Во время мастер-класса мы с нуля проверим отправку запросов в сервис по сбору аналитики — Snowplow.

Мы сэмулируем реальную бизнес-ситуацию, проведем ревью существующих на рынке средств автоматизации: Puppeteer, Playwright и получим полную картину того, насколько они подходят для решения данной задачи.

По итогу мы напишем автотест, проверяющий успешность отправки аналитики в каждом из 2-х инструментов. Кроме того, мы подключим валидатор Joi и проверим структуру данных, которая будет отправляться. И все это в режиме Live!

На протяжении последних лет в темных уголках кабинетов QA вершили историю и создавали единую библиотеку тестирования на .Net Core. Необходимо было создать общий стек тестирования для WebUI, API и БД.

Как сильно мы ошибались, неоднократно переписывали, строили комьюнити внутри компании, выводили в opensource и о том, к чему все привело, — и будет посвящен доклад. На реальных примерах мы рассмотрим весь путь от этапа идеи до формирования библиотеки автоматизации, которой пользуются десятки компаний по всему миру.

В докладе предлагается пересмотреть взгляд на статус-кво, при котором тестирование занимает лишь 1 этап в SDLC, в то время как существующие практики и подходы говорят об обратном. Также посмотрим, как при всём этом нам помогает контейнеризация и как наша команда должна подстроится, чтобы контейнеризация в автоматизации тестирования нас ускоряла.

Тезисы:
* Постановка проблемы.
* SDLC и где живет тестирование.
* Внедрение QA в контейнеризированной среде.
* Как контейнеры ускоряют тестирование.
* Roadmap внедрения контейнеризации в тестирование.
* Немного о технологиях контейнеризации, обертки, все пути ведут в runc.
* Немного о testcontainers.
* Использование тестирования в gitlabci.
* Преимущества использования контейнеризации.
* Какие минусы и сложности.

На начальном этапе создания автоматических тестов обычно обсуждается вопрос: "Какой инструмент выбрать для работы с тестовыми сценариями". Он должен обладать рядом возможностей, позволяющих построить эффективное взаимодействие между командами. В частности, необходимо, чтобы связь между тестовыми сценариями и бизнес-требованиями легко прослеживалась. Также не должно быть проблем с поддержанием самих сценариев в актуальном состоянии при внесении изменений в продукт.

Внедрение фреймворка Cucumber может стать одним из решений этой задачи.

В докладе я поделюсь своим опытом разработки и сопровождения автоматических тестов на основе тестовых сценариев Cucumber. Расскажу о плюсах и неочевидных выгодах этого подхода для коммуникации и оптимизации рабочих процессов. Особое внимание уделю проблемам и трудностям, с которыми столкнулся, предложу варианты их решения.

Сделаю краткий обзор особенностей инструментов, которыми пользовался при решении этой задачи и их альтернатив. В завершение несколько слов про алгоритм перевода существующей тестовой сьюты на Cucumber.

* Стандартизация техподходов в автоматизации тестирования.
* Познакомимся с генератором проектов с автотестами. Создадим проект с нуля из ручного теста — код, ci (jenkins), отчетность, контейнеризация браузеров, нотификация.
* Изучим готовый фреймворк на java / selenide / rest-assured / allure со скриншотами и видео.
* Обогащение api-запросами ui-автотестов для атомизации, параллелизации и ускорения прохождения.
* Разберем красивые уведомления о результатах автотестов в telegram / slack / email / icq.
* Crowdtesting внутри своей компании — как выстроить.

Есть набор проблем, с которыми сталкивается каждый автоматизатор:
* долго автоматизировали тест, а такие проверки уже есть, и тест стал не нужен;
* тесты постоянно ломаются, т.к. в продукт внесли изменения;
* постоянно тратим время на поддержку тестов, анализ и прочее, а не на создание новых тестов.

Многие причины связаны с менеджментом и неудачными решениями при организации кодовой базы, подходов и архитектуры.

Надо лечить болезни, а не симптомы. В докладе мы рассмотрим чек-лист, позволяющий избежать зарождения и усугубления этих проблем, например:
- как избежать проблем коммуникаций;
- как разбить и хранить тесты по слоям;
- как ускорить анализ;
- как повысить стабильность автотестов.

Мы рассмотрим основные антипаттерны в юнит-тестировании и научимся определять их с первого взгляда, подумаем, как можно улучшить код тестов и как говорить об этом с разработчиками.
Примеры будут на языке Java.

Расскажу про наш OSS iOS-раннер тестов Emcee — github.com/avito-tech/Emcee

* Нативные инструменты iOS-тестирования vs. TTM.
* Как мы запускаем солянку из 100000 тестов каждый день через Emcee.
* Управляемся с упряжкой из 80 Mac mini.
* Почему написать свой раннер — это сложно.
* Мастер-класс: поднимаем Emcee ванлайнером на баше.

От года к году число пользователей и заказов на Ozon растет, и наши IT-системы должны поддерживать этот рост: сервисам нужно отдавать контент как можно быстрее. И чтобы это делать, нужно знать, как измерять скорость сайта в браузере.

* Достаточно ли проводить тестирование только на тестовых средах? Нет!
* Стоит ли останавливать QA-деятельность после релиза? Нет!
* Будет ли продукт качественным, если сайт открывается долго? Нет!

Достоверно понять, как сайт работает, можно только по метрикам и тестам на продакшне.

В докладе я расскажу:
* как мы понимаем, что наш сайт быстрый;
* какие есть инструменты для измерения скорости сайта;
* как мы проводим анализ метрик;
* о метриках TTFB, TTLB, LCP, CLS, SpeedIndex — какие из них больше относятся к фронтенду, а какие — к бэкенду;
* на какие показатели рекомендует ориентироваться Google, и как далеко мы от этих показателей.

А также:
* сравним 2 подхода по сбору метрик: RUM vs SiteSpeed;
* рассмотрим примеры реальных кейсов: какие выводы можно делать по наблюдаемым измерениям.

Заводить руками тест-кейсы в тестохранилках достаточно долго и уныло. А ещё есть много юнит-тестов, которые пишут разработчики, и не всегда понятно, что они покрывают и как пересекаются с е2е-тестами.

Вот эти две проблемы мы решили комплексно, сделав систему, которая ищет и выгружает все-все-все тесты из кода наших приложений и агрегирует в понятное покрытие нашей тестируемой системы. Расскажу также, как этот подход не только сократил трудозатраты и дублирование работы, но помог сделать некоторые культурные сдвиги.

Практически в любом приложении есть функционал, который зависит от времени, всего от нескольких секунд — что-то появилось и автоматически исчезло, что-то запустилось в фоновом режиме и тому подобное. И когда мы начинаем писать на это автотесты — возникают проблемы. Система чуть притормозила и не успела завершить фоновую работу до того, как мы ожидали, браузер отработал чуть быстрее, и уже скрыл то, что мы хотели увидеть... Всё это ведёт к тому, что автотесты на такой функционал иногда падают без веской причины — система работает, а тест красный. Это ведёт к утрате доверия к билдам.

Классические решения — мониторить и перезапускать такие тесты, поставить ожидания побольше — решают не проблему, а симптомы. Мы решили бороться с самой болезнью.  И я расскажу, как мы победили:
* тесты с автоматически появляющимися и исчезающими окошками;
* тесты, завязанные на асинхронные операции бэкенда.

Также расскажу, как мы продолжаем непримиримую борьбу с флаки-тестами.

Планирование эксперимента и анализ полученных данных являются важнейшей частями любой работы, связанной с исследованиями. Несмотря на накопленный большой опыт научного сообщества в этих задачах, каждый исследователь практически неизбежно сталкивается с ошибками. Как правило, это некорректные дизайны экспериментов, которые сильно влияют на качество данных. Однако, иногда, несмотря на ошибки, допущенные в ходе сбора данных, все равно получаются статистически достоверные результаты, и тогда уже приходит сомнение о надежности статистических методов.

Предполагаем, что есть глубокая связь между проведением научных исследований и тестированием качества продукта.

В данном докладе будет обсуждаться опыт, который был получен спикером из ошибок, допущенных как в планировании эксперимента, так и в процессе обработки данных. Автор очень надеется, что этот опыт будет крайне полезен для всех интересующихся качественными исследованиями и тестированием.

Роботы и печенье: детское устройство от этнографии до UX-тестирования.

В своем докладе я поделюсь опытом разработки и тестирования голосового интерфейса для детского робота “Емеля”, сочетающего в себе функции умной колонки и компаньона.

На момент начала разработки в 2016 году в русскоязычном сегменте аналогичных устройств не существовало, голосовой интерфейс использовался реже, чем сейчас, и основные пользователи — дети чаще всего не имели опыта и наработанной манеры взаимодействия с ним (а разработчики — с детьми). Проектировать взаимодействие с устройством и проверять свои гипотезы команде приходилось практически “с нуля”.

В процесс разработки вошли предварительные интервью с родителями и детьми, тестирование диалогового агента взрослыми и UX-тестирование с участием детей — как в “лабораторных”, так и в домашних условиях. При этом мы увидели несколько важных разрывов:
* между тем, что говорят о поведении и интересах детей родители и сами дети,
* между тем, что люди о себе говорят, и тем, что они делают,
* между тем, как работает диалог “в вакууме” и в условиях физической реальности,
* между тем, что исследователи хотят знать, и тем, что им стоило бы знать.

Результатом работы стало усовершенствование не только устройства, но и методов тестирования и UXR для голосовых устройств.

Чем отличается жизнь QA-инженера и Support на примере баз данных MySQL, MariaDB, Percona Server, Postgresql, Mongo? QA ищет проблемы, а Support старается ответить на вопросы.

Сокращаем время ответа с помощью быстрого старта пустых баз. Ищем золотую середину между воспроизводимостью бага и честностью микробенчмарка. Открываем дверцу в исходный код через perf и gdb.
Воспроизводим конфигурацию репликации и кластеров, чтобы найти ошибки в конфигурационных опциях.
Всё это на живых примерах Docker- и LXD-контейнеров.

In this talk, I'm going to share my experience for bugs testing and verification, User expectation and issue analysis.
* Verification approach to get it in the right direction.
* Tool we use to test these products bugs with some examples.
* Verification documentation, Why it has great significance in the process?
* Challenges of testing and verifying community bug reports.
* How the QA team can reduce bug inflow for software after release.

У пользователей того или иного сервиса возникают вопросы, сомнения или проблемы с использованием сервиса. Куда же направить таких пользователей? Какие каналы связи им предоставить? И как работать с огромным количеством технических обращений, если саппорт — не технические специалисты, а советовать «переустановить приложение» — это самый первый шаг к потере клиента?

В своем докладе дам ответы на эти и другие вопросы эффективного взаимодействия саппорта и тестирования, поделюсь различными лайфхаками. А также расскажу, как не работать в дни дежурства.

BDD — крайне холиварная тема.
У многих специалистов в QA Automation есть отторжение даже от вакансий, в которых она упоминается.

Однако, если ее правильно приготовить и подать, это отличный способ передать работу по написанию и поддержке тестов в команду функционального тестирования, а самим заниматься развитием фреймворка, релизить, багфиксить и т.д.

Я расскажу:
* как поднять BDD на стеке Python/Behave, и что Behave не умеет из коробки;
* как преодолеть неприязнь к Gherkin-диалекту;
* какими фичами мы расширили стандартный gherkin codestyle (кастомные переменные, DSL для доступа к любому UI и т.д.);
* как «подарить» это всё ручным QA.

API-тесты в BDD пишутся достаточно легко, а для UI очень легко написать мешанину из хрупких конструкций. На конференции я покажу архитектуру в картинках, из каких слоев должен состоять фреймворк, и примеры плохих/хороших тестов.

* Проблемы в магазине виртуалок.
* Меры решения.
* Управление тестовыми средами.
* Терминология.
* Как работает полигон.
* Ноу-хау в Газпромбанке.
* Проблемы и решения тестовых данных.

* Плюсы и минусы обоих подходов, где золотая середина.
* Автоматизация UI или API, что выбрать.
* Как мерить объем автоматизации и надо ли.
* Централизованные инструменты автоматизации, отчетности и инфраструктура выполнения автотестов.
* Эксплуатация автотестов командой, планирование тестирования и анализ результатов. Как развивалось и что используем.

1. Особенности десктопного приложения с толстым клиентом.
2. Варианты автоматизации регрессионного тестирования десктопного приложения: GUI-автоматизация с помощью Windows Application driver и серверной части системы через API.
3. Критерии выбора способа автоматизации:
3.1. Критерии по объекту тестирования (back/front).
3.2. Критерии по трудоëмкости:
3.2.1. Сложность распознавания элементов UI.
3.2.2. Число и сложность запросов.
3.3. Критерии по удобству анализа отчëта.
3.4 Критерии по сложности поиска/получения тестовых данных.
4. Выводы.

## Короткий обзор вкусных фич Selenium 4:
[ ] переход на W3C protocol;
[ ] поддержка Chrome DevTools protocol;
[ ] кратко — прочие фичи;
[ ] Deprecate'ы и что осталось за бортом релиза.

## Варианты подходов к автоматизации (Selenium vs Selenide):
[ ] построение автоматизации на Selenium / Selenide — плюсы и минусы подходов.

## Наш опыт с Selenium 4.x (и Selenide 6.x), и какую пользу мы смогли извлечь из этого апгрейда:
[ ] как мажорный релиз селениума повлиял на селенид — Selenide changelog кратко;
[ ] эмуляция геолокации для тестирования фронтовых решений;
[ ] относительные локаторы в тестах — добро или зло;
[ ] прочие истории из практики;
[ ] наши дальнейшие планы по внедрению нового функционала из Selenium-стека.

* Проблематика тестирования сложных e-commerce-систем.
* Механизм подготовки согласованных данных для автотестов.
* Удобный формат ведения тестовых данных.

MySQL Test Framework (MTR) — это фреймворк для регрессионных тестов MySQL. Тесты для него пишут разработчики MySQL и запускаются во время подготовки к новым релизам.

MTR можно использовать и по-другому. Я его использую, чтобы тестировать проблемы, о которых сообщают клиенты, и подтверждать сообщения об ошибках (bug reports) одновременно на нескольких версиях MySQL.

При помощи MTR можно:
* программировать сложные развёртывания;
* тестировать проблему на нескольких версиях MySQL/Percona/MariaDB-серверов при помощи одной команды;
* тестировать несколько одновременных соединений;
* проверять ошибки и возвращаемые значения;
* работать с результатами запросов, хранимыми процедурами и внешними командами.

Тест может быть запущен на любой машине с MySQL-, Percona- или MariaDB-сервером.

Я покажу, как я работаю с MySQL Test Framework, и надеюсь, что вы тоже полюбите этот инструмент.