QA Engineer’s Adventures in Web3Land

На The Scaling Meetup в Тбилиси, Даня XO, QА Engineer из 1inch Network, рассказал про все тонкости процесса обеспечения качества программного обеспечения, разрабатываемого для использования в децентрализованных приложений и сервисах, использующих технологию блокчейн, на примере DEX агрегатора 1inch Network!

Экосистема

Основой 1inch Network является протокол агрегации, который за доли секунды сканирует различные пулы ликвидности и протоколы, чтобы найти наиболее выгодную для пользователя цену обмена крипто-активов с минимальными затратами на газ. Кроме того, у проекта есть Liquidity Protocol, DAO, токен и собственный кошелек, который в настоящее время разрабатывается мобильной командой. Отдельная команда занимается разработкой Hardware кошелька. Помимо этого, у 1inch есть собственный Limit Order Protocol, а также в ближайшем будущем планируется предоставить опытным трейдерам доступ к новому продукту, под названием 1inch Pro.

Фичи

QA - что это и зачем?

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

Задачи QA

Задачи QA очень разнообразны и включают в себя множество всего. На первом месте тестирование фичей и поиск багов. Но помимо этого, в QA также входят: автоматизация тестирования, настройка CI/CD, создание документации и мониторинг построения мониторинга. Важной задачей является разработка тест-дизайна, построение систем тест-планов, разработка внутренних инструментов и процесса построения метрик. Анализ качества ПО, которое уже находится в production, и оценка качества новых фичей.

Web3 QA Engineer Starter Pack

Как правило, стек инструментов для тестирования - это множество браузеров, консолей, IDE, инструменты для тестирования API, различные кошельки от разных компаний и команд для проверки интеграций и их работоспособности с dApp 1inch. Также различные интеграции проходят тестирование и анализ, чтобы гарантировать корректную работу приложения 1inch внутри этих же приложений.

Чем занимается QA

Релизный цикл и процессы

Релизный цикл dApp организован следующим образом: работа идет в спринтах длительностью две недели, в каждом спринте происходит от 2 до 4 релизов. У проекта есть тестовое окружение для разработки и тестирования, идет тесная поддержка коммуникации внутри команды с бэкендом, фронтендом, дизайном и продактами.

Рабочая схема Jira workflow включает этапы спецификации: To Do, In Progress, Review, QA, Ready For Release и Released. QA-инженер должен присоединяться к проекту на этапе спецификации, но это не всегда возможно. В таком случае, инженер подключаемся к разработке фичи на этапе коммитов, чтобы выявить и отловить “детские” баги, которые могут помешать функциональному тестированию. В таких случаях он может вернуть задачу обратно разработчикам, чтобы они исправили найденные проблемы, или же подтвердить готовность к релизу и перейти к следующему этапу.

Ручное тестирование

Автоматизация

Как сделать хорошо

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

2. Выстроить процессы как внутри команды QA, так и внутри команды разработки, чтобы максимально фокусироваться на новых фичах и не пропускать какие-то громадные баги в production.

3. Развивать документацию. В случае, если в команду приходит новичок, то чтобы не проводить с ним по многочасовые звонки, можно отправить ему confluence и рассказать, какую конкретно документацию ему нужно изучить. И если у него появятся какие-то вопросы, тогда проводить с ним звонок.

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

5. Подружиться с поддержкой. Если у проекта есть реальные пользователи, то в первую очередь нужно объяснить юзерам из поддержки, какие репорты нужны команде для анализа багов. Хороший репорт - это когда поддержка запросила у пользователя, например, скриншот, скринкаст, логику девайса или браузера, которые можно использовать для тестов, и всё это зафиксировано в одном тике. Таким образом, QA-инженер может уже сразу догадаться в чём проблема, взять тестовые данные, пойти проверить их и убедиться, есть ли проблема, и почему она происходит.

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

Что еще

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

2. Использование feature-toggles помогает внедрить новую функциональность лишь для определенной части пользователей, чтобы понять, где есть проблемы и где нет, без влияния на всех юзеров.

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

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

5. А/Б тестирование - скорее относится product-разработке.

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

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

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