Доклады

Другое (1)

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

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

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

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

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

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

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

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

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

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

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

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

Зачем QA работать за релиз-инженеров

В Ozon mobile QA выполняют задачи релиз-инженеров. Это помогает нам ускорить разработку фич и наращивать экспертизу там, где обычно не принято среди QA инженеров. Как мы к этому пришли и почему это работает — Дарья расскажет в своём докладе.

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

How to Automate Routine Tasks Using Bash

Roel Van de Paar

Dream Computers Pty

Sharpen your Bash scripting skills and learn how to customize your scripts for improved task automation on Linux systems.

“With some creativity and ingenuity, almost any task can be automated with Bash.”

This talk will discuss how to automate routine tasks with Bash at a medium to advanced level. It will cover various advanced Bash commands and show how they can be used to accomplish complex and repetitive tasks. Attendees will also discover how to make their automation scripts more efficient.

The key Bash features the speaker will discuss include pipes, conditionals and looping, advanced Bash idioms, xargs, sed, and regular expressions. We will also explore parallel processing and script optimization.

Duration: ~60-90 minutes.

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

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

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

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

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

Нюансы тестирования распределенной базы данных

Если с тестированием сайта, мобильного приложения или даже игры все, вроде бы, понятно, есть множество людей занимающихся этим и готовых поделиться опытом, то что насчет базы данных, да еще и распределенной?
Тема тестирования "монстров" вроде Apache Ignite показалась мне малораскрытой и я решил поделиться подробностями нашего опыта в этом докладе.

Я занимаюсь разработкой распределенного хранилища Apache Ignite с тех самых пор как проект вошел в Apache Software Foundation.
И под разработкой я понимаю не только написание кода, но и тестов, бенчмаркинг, автоматизированные испытания и демонстрации.

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

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

QA и наука (4)

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

Анна Дегтева

Альфа-Банк

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

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

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

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

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

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

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

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

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

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

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

Метрика вовлечённости, или Как измерить качество изменений на образовательной онлайн-платформе

Чем больше ученик вовлечён в процесс обучения, тем больше вероятность, что он доучится до конца. Поэтому при разработке платформы онлайн-образования важно учитывать не только успехи учеников в получении сертификатов, но и их вовлечённость в учебный процесс. Ориентируясь на вовлечённость учеников, можно оценивать качество изменений на платформе и принимать решения об их целесообразности.

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

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

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

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

Биометрические гаджеты как инструмент usability-тестирования

Исторически использование биометрии (пульс, кожно-гальваническая реакция, электроэнцефалография, отслеживание направления взгляда и т.д.) для оценки когнитивной и физической нагрузки, испытываемой пользователем программного или аппаратного продукта, оставалось уделом крупных лабораторий из-за дороговизны и эксклюзивности соответствующего оборудования. Однако современные гаджеты потребительского сегмента, ориентированные на фитнес и развлечения, сильно изменяют баланс: они достаточно широко доступны, чтобы обеспечить тестирование на адекватной выборке, и при этом достаточно точны, чтобы предоставить информацию, полезную для оценки UI/UX.
В докладе будет рассмотрено использование в тестировании таких гаджетов, как фитнес-трекеры, потребительские гарнитуры с функциями электроэнцефалографа и айтрекеры. Для каждого типа устройств будут предложены метрики, по которым можно выполнять сравнение и оценку результатов эксперимента, и кратко рассмотрены сценарии их использования для сравнения схожих программных продуктов в двух типах задач: задачах, связанных с последовательностями разнотипных операций, и с длинной последовательностью рутинных операций.
Также будет уделено внимание преодолению проблемы иного целевого назначения потребительских гаджетов, из-за которого их использование в исследовательских целях может оказаться затруднено: будут рассмотрены способы извлечения данных, вопросы шифрования биометрической информации и лицензирования.

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

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

QA and Support Pro’s: A Match Made in Heaven?

Roel Van de Paar

Dream Computers Pty

Quality assurance and support professionals share a lot of common ground. They both have to understand the product's goals and features, be able to identify issues, and have a thorough understanding of the procedures for interacting with users — from support calls to bug reports.

In this talk, learn how these two jobs can work together better to create a great customer experience.

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

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

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

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

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

Чем отличается жизнь QA инженера и Support на примере баз данных MySQL, MariaDB, Percona Server, Postgresql, Mongo? QA ищет проблемы, а Support старается ответить на вопросы.
Сокращаем время ответа с помощью быстрого старта пустых баз. Ищем золотую середину между воспроизводимостью бага и честностью микробенчмарка. Открываем дверцу в исходный код через perf и gdb.
Воспроизводим конфигурацию репликации и кластеров, чтобы найти ошибки конфигурационных опциях.
Всё это на живых примерах Docker и LXD контейнеров.

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

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

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

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

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

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

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

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

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

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

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

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

Postgres Professional

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

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

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

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

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

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

Сергей Мишанин

ПАО "Банк "Санкт-Петербург"

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

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

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

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

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

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

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

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

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

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

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

Доклад посвящен подходу, который активно применяется на "Платформе прогнозирования спроса X5", и позволяет реализовывать нагрузочное тестирование на Python.

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

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

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

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

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

Spring Boot. Эффективное тестирование Service и Data layer

Семен Киреков

МТС Диджитал

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

Когда речь идет о тестировании Service и Data layer, можно использовать моки и стабы, а можно и реальную СУБД. Я расскажу на примере Spring Boot, что это ничуть не сложнее, чем подход “мокать все и вся”. С помощью аннотаций @DataJpaTest и @SpringBootTest покажу, как настроить H2, Testcontainers и Flyway. И попробую вас убедить, что писать тесты, работающие с базой данных, не сложно и не страшно.

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

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

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

Никита Чурсин

Технологический Центр Дойче Банка

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

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

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

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


Именно о них и пойдет речь в докладе:
DataInu: говорит где у нас больше всего багов, что даёт повод для рефакторинга и фокус для написания автотестов. Вопрос: “Как объяснить ПМу, что авторизацию давно пора рефакторить?” больше не стоит, он и сам это понимает.
https://github.com/artkuznetsov/datadog ;
Workflow Simulation Service (WSS). Позволяет мне безопасно для проекта, команды и бюджета определять вероятность успешности изменений, на основе чего уже я могу принимать решение о их внедрении или отмене на живом проекте. Этот инструмент вместо меня отвечает на вопрос: “Зачем вам ЕЩЕ тестировщики??”
https://github.com/artkuznetsov/workflow-simulation-service ;
Подход, который даёт понимание, какие части приложения мы еще не покрыли, какие покрывать не надо,а какие - вообще мёртвые. Это понимание позволило нам правильно расставлять акценты при планировании скоупа автотестов на спринт. Способ применим только для Java приложений, но мы также сравним его с современными аналогами, такими, как Drill4J.
Теперь мы знаем сколько и что именно покрывают наши автотесты, а сколько - ручные.
https://bit.ly/3jdXzbP

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

Скорость как показатель качества

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


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

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

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

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

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

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

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

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

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