Конференция завершена. Ждем вас на других конференциях Онтико

Доклады

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

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

Machine Learning

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

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

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

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

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

Распределенные системы
Функциональное тестирование
Нагрузочное тестирование
Тестирование безопасности
Автоматизация тестирования
Интеграционное тестирование
Приёмочные и функциональные тесты

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

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

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

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

Кибертестирование, или Сейчас в будущее

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

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

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

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

Функциональное тестирование
Автоматизация тестирования
QA / другое

Вы наверняка знаете про концепцию 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.

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

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

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

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

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

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

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

Приёмочные и функциональные тесты
Типовые ошибки
Инструменты
Виктор Мясников

Юла, проект VK

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

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

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

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

Нагрузочное тестирование
Автоматизация тестирования
QA / другое
Виталий Акулов

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

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

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

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

Spring REST Docs: документация из тестов, а не наоборот

API
Методы и техника разработки ПО
Разработка библиотек, включая open source библиотеки
Devops / другое
Автоматизация разработки и тестирования
Функциональное тестирование
Приёмочные и функциональные тесты
QA / другое
Практики программирования
Автотесты
Взаимодействие с серверной стороной (REST, GraphQL, gRPC)
Документация
Ян Ашенкампф

Газпромбанк

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

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

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

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

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

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

Микросервисы, SOA
Непрерывная интеграция
Автоматизация тестирования
Автотесты

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

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

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

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

Андрей Синицын

Независимый эксперт

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

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

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

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

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

Функциональное тестирование
Автоматизация тестирования
QA / другое
Денис Кудряшов

Веб3 Технологии

Все, кто погружается в мир автотестов 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. Антипаттерны тестирования и рецепты тестов с БД

Фреймворки
Java
Интеграционное тестирование
Юнит-тестирование
Семен Киреков

МТС Диджитал

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

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

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

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

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

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

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

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

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

Платёжные системы, обработка платежей
Логирование и мониторинг
Нагрузочное тестирование
Автоматизация тестирования
Интеграционное тестирование
Надёжность продакшена
Проверка гипотез на проде: технологии и команды

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

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

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

Базы данных / другое
Нагрузочное тестирование

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

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

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

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

Фреймворки
Защита информации
Базы данных / другое
Отказоустойчивость
Архитектура данных, потоки данных, версионирование
Синхронизация данных, параллельная обработка, CDN
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
Нагрузочное тестирование
Автоматизация тестирования
QA / другое
Надёжность продакшена
Тестирование новых продуктов
Безопасность от планирования до эксплуатации
Хранилища
Обработка данных
Железо

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

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

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

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

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

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

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

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.
* Преимущества использования контейнеризации.
* Какие минусы и сложности.

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

Плюсы и минусы автоматизации тестовых сценариев Cucumber при частых релизах в рамках CI/CD

Автоматизация разработки и тестирования
Автоматизация тестирования
Коммуникация
Автотесты
Инструменты

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

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

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

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

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

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

Функциональное тестирование
Автоматизация тестирования
Тестирование мобильного ПО
Онбординг
Инструменты
Методологии

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

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

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

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

Методы и техника разработки ПО
Автоматизация разработки и тестирования
Методологии и процессы разработки ПО; Сроки и приоритеты
Оценка сложности проекта
Продуктовая разработка
Функциональное тестирование
Автоматизация тестирования
Интеграционное тестирование
Юнит-тестирование
Приёмочные и функциональные тесты
Teamlead
Коммуникация
Управление командой
Управление разработкой
Управление проектами
Agile / Scrum
Типовые ошибки
Лайфхаки
Инструменты
Методологии
Виктор Раев

Независимый эксперт

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

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

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

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

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

Java
Юнит-тестирование

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

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

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

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

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

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

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

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

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

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

Функциональное тестирование
Автоматизация тестирования
Приёмочные и функциональные тесты
QA / другое

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

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

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

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

QA и наука (2)

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

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

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

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

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

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

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

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

Анна Дегтева

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

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

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

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

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

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

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

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

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

PostgreSQL
MongoDB
Технологии виртуализации и контейнеризации
Профилирование и отладка кода
MySQL (MariaDB, Percona Server)

Чем отличается жизнь 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 (En)

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.

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

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

QA / другое
Лайфхаки
Образование
Екатерина Яковлева

Юла, проект VK

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

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

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

Другое (2)

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

Функциональное тестирование
QA / другое
Метрики
СУЗ / системы управления знаниями
Онбординг
Менторинг
Образование
Картирование знаний

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

Эти и многие другие вопросы мы обсудим с приглашенными звёздами. Можно будет задать и свои вопросы.

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

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

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

Функциональное тестирование
Автоматизация тестирования
Тестирование фронтенда

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

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

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

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

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

TechTalk (5)

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

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

Газпромбанк

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

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

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

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

Газпромбанк

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

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

Selenium 4 как новое сердечко фреймворков автоматизации. Сбылись ли грезы?

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

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

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

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

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

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

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

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

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

Резерв (1)

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

Функциональное тестирование
Автоматизация тестирования
Юнит-тестирование
Профилирование и отладка кода
QA / другое
MySQL (MariaDB, Percona Server)

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

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

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

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

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

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