Доклады

Cutting-edge-технологии (2)

Как далеко нужно зайти при тестировании распределенной базы данных?

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

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

Доклад принят в программу конференции

А что, вы нейронные сети тоже тестируете?

Представьте, что вы сделали модель, которая решает вашу задачу с ошибкой меньше 1 процента. Радостный, вы относите её вашему заказчику, а он после своих тестов заявляет что на его данных ошибка составила 25 процентов.
Вы начинаете выяснять, в чём дело. И оказывается, что у заказчика данные на другом языке, в сами тестовые сценарии вы не вчитывались и вообще система эксплуатировала длину тишины в аудиозаписях для обучения.
Как этого избежать? Как грамотно построить процессы тестирования и сравнения нейронных сетей, чтобы не тратить на тесты больше чем на обучение? Ответы на эти вопросы, а также о том, как построить инфраструктуру для хранения таких моделей в этом докладе.

Доклад принят в программу конференции

Cookbook - готовые рецепты (15)

Тест-кейсы умерли. Да здравствуют тест-кейсы!

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

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

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

Доклад принят в программу конференции

k-ветки. Как не отказаться от тестирования фича-веток при переходе на микросервисы

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

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

Доклад принят в программу конференции

Маршрут на высоту k6

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

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

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

Доклад принят в программу конференции

Контроль качества в крауде: внутри и снаружи

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

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

Доклад принят в программу конференции

Как Юла запустила BDD-фреймворк для автоматизации API без кода

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

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

Доклад принят в программу конференции

Применение автотестов в ежедневных релизах

Виталий Акулов

Утконос Онлайн

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

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

Доклад принят в программу конференции

Стабильность в нестабильном мире: тестируем при помощи Kubernetes

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

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

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

Доклад принят в программу конференции

CI/CD для тестирования на больших проектах

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

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

Доклад принят в программу конференции

Фаззинг-тестирование с учетом структуры данных, библиотека libblobstamper

Николай Шаплов

Postgres Professional

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

Для преодоления этого препятствия предполагается использовать фаззинг-тестирование с учетом структуры данных (Structure Aware Fuzzing). При SAF-тестировании генерируются формально валидные (синтаксически верные или структурно корректные), но фактически случайные данные, что позволяет подвергнуть тестированию уровни системы, лежащие за синтаксическим анализатором.

Библиотека LibBlobStamper, созданная в недрах компании Posrgres Professional, позволяет решать задачи построения SAF-тестов как для случая строковых (синтаксических) так и для бинарных (структурных) входных данных.

В данном докладе рассказывается о проблематике Structure Aware Fuzzing'а, приводится краткий обзор имеющихся инструментов и проводится наглядная демонстрация того, как задачи SAF-фаззинга могут быть решены с использованием библиотеки LibBolbStamper.

Доклад принят в программу конференции

По следам Мартина Фаулера. Расширяем область применения Page Object

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

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

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

Доклад принят в программу конференции

Ускорение тестирования за счёт Crowd

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

Доклад принят в программу конференции

Git submodules в автоматизации тестирования

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

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

Доклад принят в программу конференции

Достижение Единогo Понимания Unit-тестов

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

Доклад принят в программу конференции

Нагрузочное тестирование с помощью Python и Locust

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

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

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

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

Доклад принят в программу конференции

Spring Data JPA. Антипаттерны тестирования и рецепты тестов с БД

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

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

Доклад принят в программу конференции

Нагрузочное тестирование (4)

Production-like-нагрузочное тестирование распределенной системы

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

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

Доклад принят в программу конференции

Как ускорить запросы к InfluxDB с помощью InfluxQL Continuous Queries и разделения данных

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

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

Доклад принят в программу конференции

Автономная система стрельб по проду на базе кластера сервисов

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

Доклад принят в программу конференции

Нагрузочное тестирование СХД и особенности генерации тестовых данных из опыта компании Dell

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

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

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

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

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

Доклад принят в программу конференции

Автоматизация рутины (5)

Fluent Assertions - для интеграционного автоматизированного тестирования

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

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

Доклад принят в программу конференции

Мастер-класс по тестированию Web-аналитики

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

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

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

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

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

Доклад принят в программу конференции

Make .Net Automation Great Again

Андрей Ганин

Альфа Банк

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

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

Доклад принят в программу конференции

Контейнеризация и SDLC в тестировании

Евгений Харченко

Райффайзен Банк

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

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

Доклад принят в программу конференции

Автоматизируя автоматизацию тестирования

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

Доклад принят в программу конференции

Оптимизация тестов и аналитики (7)

Автоматизация хаоса. Как усмирить энтропию в автотестах

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

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

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

Доклад принят в программу конференции

Проверяем юнит-тесты. Основные признаки неудачных решений

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

Доклад принят в программу конференции

Как подружить QA и разработку через применение практики хранения тестов в коде

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

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

Доклад принят в программу конференции

Три простых инструмента, которые экономят время тест-лиду в покрытии, анализе и планировании на проекте

Вас когда-нибудь спрашивали: “А сколько там ваши автотесты покрывают?”, “Зачем вам ЕЩЕ тестировщики?”, “Блин, опять баги нашли в авторизации. Как объяснить ПМ-у, что её давно пора рефакторить?”. Чтобы ответить на такие вопросы с доказательной базой, цифрами и графиками, я написал несколько инструментов, а затем и выложил их в OpenSource.

Именно о них и пойдет речь в докладе:
* DataInu: говорит, где у нас больше всего багов, что даёт повод для рефакторинга и фокус для написания автотестов. Вопрос: “Как объяснить ПМ-у, что авторизацию давно пора рефакторить?” больше не стоит, он и сам это понимает.
* Workflow Simulation Service (WSS). Позволяет мне безопасно для проекта, команды и бюджета определять вероятность успешности изменений, на основе чего уже я могу принимать решение об их внедрении или отмене на живом проекте. Этот инструмент вместо меня отвечает на вопрос: “Зачем вам ЕЩЕ тестировщики?”.
* Подход, который даёт понимание, какие части приложения мы еще не покрыли, какие покрывать не надо, а какие, вообще, мёртвые. Это понимание позволило нам правильно расставлять акценты при планировании скоупа автотестов на спринт. Способ применим только для Java-приложений, но мы также сравним его с современными аналогами, такими как Drill4J.

Теперь мы знаем, сколько и что именно покрывают наши автотесты, а сколько — ручные.

Доклад принят в программу конференции

Писать нативные автотесты для iOS сложно? Это пока вы их запускать не начнете!

Расскажу про наш OSS iOS-раннер тестов Emcee — https://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;
- посмотрим примеры реальных кейсов: какие выводы можно делать по наблюдаемым измерениям.

Доклад принят в программу конференции

Главное — не моргай! Как мы избавлялись от flaky-тестов

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

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

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

Доклад принят в программу конференции

QA и наука (2)

Оценка качества научных исследований и полученных данных

Александра Берлин Хенис

Лаборатория когнитивных и лингвистических исследований

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

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

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

Доклад принят в программу конференции

Как протестировать культурный код, или UX-тестирование детского голосового помощника

Анна Дегтева

Независимая исследовательница

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

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

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

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

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

Доклад принят в программу конференции

QA и саппорт (3)

Как свить гнездо для бага: воспроизводим проблемы с базой данных (MySQL/Postgres/Mongo)

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

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

Доклад принят в программу конференции

How do we do it? Testing and Verifying bugs for released software

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.

Доклад принят в программу конференции

Выстраиваем отношения с техподдержкой

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

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

Доклад принят в программу конференции

Другое (1)

Круглый стол "Как учиться и чему учить в тестировании?"

Мы собираем круглый стол для обсуждения обучения в тестировании в широком формате:
* Чему учиться, чтобы стать тестировщиком?
* Почему с неохотой берут джунов без опыта?
* Куда двигаться, если уже успешно работаешь?
* Как начать заниматься автотестами и не сойти с ума?
* Насколько важны soft skills и какие?
* Как и в какую сторону изменяется IT?

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

Доклад принят в программу конференции

TechTalk (5)

Магазин виртуалок и магазин тестовых данных

Ольга Тимашева

Газпромбанк

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

Доклад принят в программу конференции

Автоматизированное тестирование внутри команды или как внешний сервис

Кирилл Гилевич

Газпромбанк

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

Доклад принят в программу конференции

Авто-тестирование десктопного приложения: критерии выбора между автоматизацией через GUI и 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 как новое сердечко фреймворков автоматизации. Сбылись ли грезы?

## короткий обзор вкусных фичей selenium 4
[ ] переход на W3C protocol
[ ] поддержка Chrome DevTools protocol
[ ] кратко - прочие фичи
[ ] Deprecate-ы и что осталось за бортом релиза

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

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

Доклад принят в программу конференции

Подготовка данных для интеграционного е2е тестирования сложных систем

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

Доклад принят в программу конференции

Резерв (2)

MySQL Test Framework для поддержки клиентов и верификации багов

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

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

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

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

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

Доклад принят в программу конференции

Как небольшой командой начать и не провалить автоматизацию на Gherkin

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

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

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

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

Доклад принят в программу конференции