Если вы читали первую часть, то вы, наверное, запомнили, что уже 27 и 28 июня пройдет наша первая конференция тестировщиков — Test Driven Conf 2022. Для остальных чуть-чуть расскажу. Темы будут сплошь для профессионалов: про автоматизацию в тестировании и QA-процессах, про нагрузочное и ML-тестирование, про оптимизацию и аналитику. Чтобы лучше представлять, как все это будет, давайте посмотрим, какие решения задач тестировщиков предлагают наши спикеры.

В прошлый раз мы рассмотрели четыре секции в которых будут проходить доклады: оптимизация тестов и аналитики, автоматизация рутины, нагрузочное тестирование и cutting-edge технологии. Теперь немного погрузимся в доклады из остальных секций.

QA и саппорт

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

Чем отличается жизнь QA-инженера и Support? QA ищет проблемы, а Support старается ответить на вопросы. Но и тем и другим бывает нужно повторить сложную конфигурацию окружения, как у клиента. Сократить время ответа на вопросы поддержки с помощью быстрого старта пустых баз и найти золотую середину между воспроизводимостью бага и честностью микробенчмарка. А заодно открыть потайную дверцу в исходный код через perf и gdb. Об этом можно узнать из доклада Николая Ихалайнена Percona Как свить гнездо для бага: воспроизводим проблемы с базой данных (MySQL/Postgres/Mongo). Всё на живых примерах Docker- и LXD-контейнеров.

Еще один представитель Percona Lalit Choudhary в своем докладе How do we do it? Testing and Verifying bugs for released software поделится опытом тестирования, проверки багов, ожиданий пользователей и анализа проблем. Расскажет как делать и документировать анализ пользовательских сообщений о багах. Как помочь пользователю собрать необходимую информацию и сделать на её основе воспроизводимый тест. Какие инструменты для этого использовать. Даст примеры на основе продуктов с которыми работает. Таких, как сервер Percona MySQL, кластер PXC, резервное копирование PXB и инструмент мониторинга PMM. А еще разберет как команда QA может уменьшить количество багов в программном обеспечении после релиза.

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

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

QA и наука

Тестирование нужно любой области. Многие идеи берутся на пересечении науки с IT, а самые хорошие и интересные быстро подхватываются сообществом. Поговорим о том, что и как именно тестируют в наукоемких областях и какие специалисты там нужны.

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

Если хочется сменить вектор, поговорим про роботов и печеньки. Независимая исследовательница Анна Дегтева в своем докладе Как протестировать культурный код, или UX-тестирование детского голосового помощника расскажет о его разработке с самого создания в 2016 году. Тогда в русскоязычном сегменте аналогичных устройств ещё не существовало. У детей не было опыта и наработанной манеры взаимодействия с голосовым помощником, а у разработчиков — с детьми. Проектировать взаимодействие с устройством и проверять свои гипотезы команде приходилось «с нуля». Поэтому было много проб и ошибок. Тестирование диалогового агента взрослыми и UX-тестирование с участием детей — как в «лабораторных», так и в домашних условиях. Но результатом стало не только усовершенствование устройства, но и методов тестирования и UXR для голосовых устройств.

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

Cookbook

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

Вы наверняка знаете про концепцию Everything as Code — подход к разработке продуктов, рассчитанный на масштабируемость, легкость управления и переиспользование элементов инфраструктуры и инструментов. Он применяется практически везде: Documentation as Code, Pipeline as code, Deployment as Code. Но в тестировании всё не так радужно! Многие задачи решаются в парадигме ручной работы: переиспользуемые шаги и аттачменты, версионирование тестов, бранчевание. Тест-кейсы до сих пор создаются вручную и только потом автоматизируются. Из доклада Артема Ерошенко Qameta Software Тест-кейсы умерли. Да здравствуют тест-кейсы! вы можете узнать, что многие из этих проблем решаются, если перенести тест-кейсы в код. О там как использовать такой подход и какие бонусы он дает.

В принципе, все доклады этой секции про бонусы. Просто их полезность зависит от того, что именно сейчас вам нужно. Например, вы хотите быстро и с минимальными хлопотами получить документацию из тестов. Если генерировать тесты по документации или спецификации (swagger), то покрытие будет высоким, но люди такие тесты читать не смогут. Слишком много лишнего, а порядок вызовов сломан. Для того чтобы документация была полезна людям, она должна отражать конкретные частые примеры использования: аутентификация, проброс токенов, поиск, просмотр каталога, добавление товара в корзину, оформление покупки на партнерском сайте. Как такую получить, да ещё чтобы сама обновлялась расскажет Ян Ашенкампф Газпромбанк в своем докладе Spring REST Docs: документация из тестов, а не наоборот.

А это уже скорее лайфхак для «дайверов». Для всех тех, кто погружался в мир автотестов UI и сталкивался с паттерном Paje Object. Что будет, если погрузиться ещё глубже и попробовать применить этот паттерн к API? Или к модели БД? Если Page Object описывает «модель» тестируемой страницы, справится ли он с подобной задачей для других слоев приложения? Можно ли применить паттерн для тестирования требований? Ответы на эти вопросы можно получить из доклада Дениса Кудряшова Веб3 Технологии По следам Мартина Фаулера. Расширяем область применения Page Object. Там будет моделирование тестируемой сущности и тестирование требований при помощи Test Definition Object. TDO и автогенерация. И, конечно же, примеры применения в автотестах.

Что ещё? Любой продакт в компании хочет услышать: «Мы автоматизировали регресс». Ведь в этом случае не придется тратить много времени на долгий ручной прогон. Но на пути автоматизации неизбежно возникает выбор фреймворка и проблема получения отчетов. Виталий Акулов Утконос Онлайн в своем докладе Применение автотестов в ежедневных релизах предлагает сравнить ряд фреймворков. Он расскажет, какой они выбрали у себя и почему. А еще поделится тем, как установить Cypress и Allure.

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

TechTalks

Тут самые насущные вопросы и тренды. Которые показывают, как и в какую сторону в ближайшее время изменится IT. Или то, что уже стало нашей новой реальностью, но пока еще не нашло достаточно последователей и массовую поддержку.

Если хотите узнать, как выглядит прогресс, как тестовыми средами управляют в блоке цифровых технологий Газпромбанка вам на доклад Магазин виртуалок и магазин тестовых данных Ольги Тимашевой. Будет рассмотрена терминология, работа полигона, ноу-хау, проблемы и решения тестовых данных.

Хотите разобраться как лучше использовать Автоматизированное тестирование внутри команды или как внешний сервис — вам на доклад Кирилла Гилевича Газпромбанк. Сможете сравнить плюсы и минусы обоих подходов, поискать золотую середину. Попробовать решить, что лучше выбрать автоматизацию UI или API. Подумать стоит ли мерить объем автоматизации. Послушать про её централизованные инструменты, отчетности и инфраструктуры выполнения автотестов. Про планирование тестирования, эксплуатацию автотестов командой и анализ результатов. Тогда наверняка сможете сделать выводы и решить, что использовать самим.

Нужно еще больше сравнений, плюсов и минусов? Тогда попробуйте обзор вкусных фич Selenium 4. В рамках доклада Selenium 4 как новое сердечко фреймворков автоматизации. Сбылись ли грезы? Александр Кузьмичев Sportmaster Lab расскажет про переход на W3C protocol, поддержку Chrome DevTools protocol и прочие фичи. Историю про Deprecate'ы и то, что осталось за бортом релиза. Устроит битву подходов к автоматизации между Selenium и Selenide. Оценит какую пользу они смогли извлечь из этого апгрейда. Поделится историями из практики и планами по внедрению нового функционала из Selenium-стека.

Хотите ещё больше автоматизации? Сергей Слесарев РСХБ-Интех / Россельхозбанк в своем докладе Автотестирование десктопного приложения: критерии выбора между автоматизацией через GUI и API разберет, как понять на каком из уровней пирамиды, писать тесты. Будет и про особенности десктопного приложения с толстым клиентом, и про варианты автоматизации его регрессионного тестирования. И, конечно, же про критерии выбора способа автоматизации.

Еще в секции будет о проблематике тестирования сложных e-commerce-систем, механизме подготовки согласованных данных для автотестов и удобном формате их ведения. Об этом расскажет Александр Колесников Sportmaster Lab в докладе Подготовка данных для интеграционного е2е-тестирования сложных систем.

И это еще не всё! В рамках конференции пройдет круглый стол «Как учиться и чему учить в тестировании?». Будет обсуждаться как развиваться и до чего можно дорасти? Как правильно выстроить онбординг? Какие есть горизонтальные и вертикальные пути в карьере? Где пригодятся навыки тестировщика? И для чего нужно развивать специальные навыки (не soft skill)?

Все это и многое другое будет обсуждаться с приглашенными звёздами: Даниилом Закирьяновым Lesser Evil Games, Виктором Раевым Test IT, Александром Бобылевым МТС Digital, Кириллом Гилевичем Газпромбанк, Русланом Остропольским SberHealth и Зоей Чижковой Coins.ph. Будет много чего, но главное будет много общения с интересными людьми, новые знакомства и приятная дружеская атмосфера в среде профессионалов своего дела. Это точно!

TestDriven Conf 2022, конференция для senior тестировщиков и QA-инженеров пройдет 27-28 июня в Москве и будет посвящена всем вопросам автоматизации в тестировании и рядом с ним. Расписание и тезисы докладов смотрите на сайте конференции. Билеты еще можно купить здесь.

До встречи в понедельник 27 июня!