BugsBusters’23

То, что всё это мы упоминали на нашем ежегодном митапе для QA-специалистов — Bugs Busters. Было много интересного:

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

Смотрим доклады и пополняем копилку знаний обо всех видах тестовых покрытий.

Это был обычный, не предвещающий беды день: конвейер выкладки релизов работал как часы — таска прилетала и автоматически выкладывалась на прод. Но внезапно после выкатки задачи, в которой менялась конфигурация PgBouncer и приложения, что-то пошло не так: сработали триггеры, загорелась тревога. Из-за новой конфигурации к базе данных увеличилось количество активных соединений, а в самой БД — количество активных блокировок. При этом утилизация CPU со стороны базы выросла в целых пять раз! Конфигурацию спешно откатили обратно, выдохнули и стали разбираться, кто виноват: приложение, баунсер или база. Казалось, что проблема — со стороны приложения, в самой задаче, которая берётся из очереди, однако было непонятно, как именно её обработка деградирует.

03:14 — Как нам прилетела обычная таска, которая потянула за собой ряд проблем
05:13 — Пошли разбираться, кто в этом виноват, и решили, что это очередь
06:24 — Как наше приложение работает с PostgreSQL и как подружить PostgreSQL с Java App с помощью JDBC Driver
08:21 — Как настроить пул HikariCP, чтобы не возникала очередь ожидания между потоками
09:04 — Что такое JOOQ и для чего он нужен
09:53 — Почему новые соединения для PostgreSQL могут сильно нагружать CPU и как эту проблему решает пул соединений PgBouncer
11:56 — Какие бывают режимы работы PgBouncer: session transaction и statement
13:38 — Что происходит при переключении сессионного режима пулинга в транзакционный
16:46 — Что такое сильно нагруженная для финтеха очередь и как мы поняли, что она не виновата
18:17 — Как мы воспроизвели задачу нагрузки очереди и увидели разницу между режимами
21:00 — Что такое партицированные таблицы
24:26 — Что такое подготовленные операторы и как посмотреть, существуют они или нет
28:47 — Два эксперимента, которые показали, что вызывает проблему в задаче
32:04 — Как работает PG JDBC Driver
32:53 — Ещё три эксперимента, которые показали, как решить проблему
34:18 — Что делает патч и какие у него проблемы
36:16 — Чтобы получить полное понимание картины, нужно читать документацию и проводить эксперименты
36:27 — Какой результат мы получили и на каком варианте остановились

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

• Как его оценить. Здесь мы изучим плюсы и минусы двух подходов: покрытия кода продукта и покрытия требований. Также мы выясним, почему второй метод — это Rolls-Royce в мире покрытий.
• В чём особенность автотестов для веба. Как визуализировать автотесты и внедрить Allure-отчётность.
• Какой профит мы получаем от всего этого. Например, начинаем понимать, что проверяется в тестах и насколько мы их «сломаем», если поменяем структуру элементов.

06:29 — Что такое дыра в покрытии и какие вопросы задают менеджеры тестировщикам
09:07 — Как оценить покрытие кода продукта и как оно выглядит
10:29 — Как снимается покрытие
11:30 — Какие плюсы и минусы у покрытия кода продукта
13:45 — Как выглядит покрытие требований: инструменты для работы, плюсы и минусы подхода
19:14 — Как взять лучшее от каждого из подходов
19:27 — В чём особенность веба
23:30 — Как визуализировать автотесты
31:54 — Какой профит мы от этого получаем
34:15 — Какие ещё есть идеи: поддержка Playwright, сценарий теста в плагине и отдельный таб в Allure
36:24 — Подведём итоги

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

03:19 — Вводная часть: про компанию, команды и зоны ответственности
04:35 — Что такое регрессионное и приёмочное тестирование
06:24 — Достаточно ли нашей команде автотестов и почему много не значит хорошо
08:23 — Как мы работали раньше: что содержат тест-кейсы, как выглядят автотесты и как мы считаем покрытие тест-кейсов автотестами
10:22 — Про внутренний инструмент Metric Reporter, метрику Coverage и её ограничения
12:52 — Про бизнес-процессы и из чего они состоят
13:37 — Связь бизнес-процессов и тест-кейсов, метрика US и её ограничения
16:34 — Идея генерации матрицы трассировки
20:49 — Matrix MVP: знакомство с API, написание техзадания, реализация
23:53 — Итоги Matrix MVP
25:00 — Добавление матрицы трассировки в Metric Reporter
26:38 — Итоги внедрения фичи в Metric Reporter
27:35 — Как будем развивать этот инструмент
33:50 — Сколько тестов достаточно: рекомендации