В этом году я приняла участие в конференции TestCon c докладом Бета-тестирование. Переобуваемся в полете. В этот статье я хотела бы поделиться некоторой информацией моего доклада. О будет чем текущая статья:
- Рассмотрим контекст создания продукта.
- Поговорим об архитектуре решения.
- О тех шагах, которые мы выполнили для подготовки к ЗБТ.
- Что в действительности мы получили.
- И какие мы для себя сделали выводы.
Бета-тестирование. Первоначальные задачи
- Архитектура приложения должна быть масштабируемой для обеспечения совместной разработки.
- Приложение обязано выдерживать высокие нагрузки.
- Выпустить продукт с «киллер фичами» для захвата высоко-конкурентного рынка.
- Работа приложения в условиях высоких рисков с точки зрения пользователя.
- Фаза закрытого бета-тестирования длиной в 2 месяца с определенными начальными условиями.
Проблемы
-
- Исчерпанный клиентский рынок.
- Распределенная команда.
- Жесткие дедлайны.
- Ограниченное кол-во высококвалифицированных разработчиков и тестировщиков.
- Работа с локальной электронной подписью.
Но в каждой из проблем мы смогли найти и положительные моменты. Например “исчерпанный клиентский рынок” чем нам помог. Мы знали какие типичные проблемы есть у наших аналогов и конкурентов. И мы на старте закладывали архитектуру таким образом, чтобы этих проблем избежать.
Бета-тестирование. Необходимость
Так как мы решили переписать «ветхий завет» бух. учета с точки зрения пользовательского опыта. Для этого мы использовали такие инструменты как VPC, CJM, работу с гипотезами. Которые нам позволили не только заново проанализировать рынок, сегменты пользователей, но и формализовать киллер-фичи. Эти инструменты позволяют проследить все взаимодействия и контакты пользователя с различными сервисами компании. Тем самым улучшая их для создания более комфортного пользовательского опыта. VPC позволяет взглянуть на продукт с точки зрения клиента, выявить его истинные потребности, найти источники проблем, с которыми сталкивается пользователь, решая ту или иную бизнес-задачу. Кроме того, эти инструменты позволяют сфокусироваться не только на функциональной части, но и на эмоциях, а мы учитывали их не в последнюю очередь.
Немного об архитектуре решения
Чтобы выпустить успешное приложение с учетом всего контекста мы решили сделать акцент на новые технологии, которые нам могли бы быть конкурентоспособными как с технологической точки зрения так и продуктовой. Поэтому мы решили реализовать приложение на основе микросервисной архитектуры в основе которой лежат .Net микросервисы, взаимодействующие через брокер очередей. Кроме того, наличие собственных экспертов предметной области позволило нам грамотно выделить нужные микросервисы. Однако у нас было достаточно специалистов, у которых не было такого бизнес бэкграунда. Это были специалисты, которые в разработку пришли с различных областей: автозаводов, литейки, университетов, но это уже были высококвалифицированные разработчики. Это был большим плюсом, так как команда не находились в жестких рамках бизнес-контекста.
Но не забываем о том, что у нас было не только мало разработчиков, но и тестировщиков, поэтому нам необходим был продукт с высокой степенью удобства тестирования. Также это обеспечило бы нам в критичных ситуациях (а мы знали что они будут) способность принимать важные бизнес решения, которые будут влиять на репутацию нашего продукта.
Бета-тестирование. Гипотеза
Пользователи в стадии бета-тестирования ожидают стабильный продукт без багов, поэтому к нему применялись жесткие требования к качеству.
Бета-тестирование. О тестировании и не только
- Обратились за помощью к MoT: 1) используйте контрактное тестирование микросервисов, 2) используйте BDD 3) тесты стройте опираясь на тестовую пирамиду.
- Стратегия: основана на рисках, пирамида, предложенная Мартином Фаулером для тестирования приложения с микросерверной архитектурой.
- Компонентные тесты для каждого микросервиса. Здесь микросервис разворачивается вместе с его необходимым окружением изолированно. В этом случае мы используем разработанный ранее фреймворк для автотестов.
- Когда мы подошли к нагрузочному тестированию мы поняли очень важный принцип всех инструментов автоматизации. Необязательно использовать сразу большое и сложное решение, можно использовать “легкий” инструмент, который обеспечит быстрый старт. Для того чтобы сразу был виден результат испытаний и и мы смогли бы понять какие у приложения проблемы и решить как их исправить.
- После нагрузочного тестирования мы перешли к тестированию безопасности на OWASP 10. Почему безопасность это важно несмотря на закрытый бета-тест? Потому что мы являемся хранилищем персональных данных пользователей, данных реальной отчетности.
- Также есть пласт программных решений для автоматизации тестовой рутины. Набор служебных утилит и инструментов для генерации тестовых данных, тестовых окружений, виртуалок и тд.
- А где же е2е. Было принято решение, что на момент ЗБТ он был избыточен, ресурсозатратен и бессмыслен, так как приложение находилось в стадии активной разработки и менялся интерфейс постоянно.
- И конечно же вершина нашей пирамиды: высокоуровневое исследовательское тестирование акцентированное на потребностях клиента, и постоянное улучшение автоматизации в тестировании. Мы используем session-based testing, тестовые туры, использование эвристик (“shaded figs”), различных технологий брейн-шторминга. Естественно исследовательское тестирование, у нас было с самого старта проекта
- Помимо тестирования для повышения уверенности в том, что наш продукт готов мы положились на инфраструктурные решения
- UX-тестирование. В качестве инструментов мы решили использовать Я.Метрику(сбор статистики и работа с целями, в том числе и составными) + ВебВизор (для записи сессий пользователя с отслеживанием перемещения курсора, а мы знает куда взгляд туда и руки) и Sentry из коробки для трекинга ошибок.
Бета-тестирование. Пользователи
Но нам нужны бета-тестеры, нам нужны наши первые пользователи, те, на ком мы будем проводить наши тестовые испытания, эта задача решалась службой маркетинга параллельно с созданием продукта.
Непосредственно для ЗБТ была сделана выборка партнеров из нашей партнерской сети, занимающейся продвижением продуктов компании в регионах, которые в свою очередь представляли нам уже лояльных клиентов. Клиенты — это те кто кто работал с продуктами нашей компании, в том числе и по сдаче электронной отчетности, так и с аналогичными продуктами конкурентов.
Бета-тестирование. Мы готовы!
Итак благодаря всей проделанной работе, наша команда была уверена в том, что мы полностью готовы к ЗБТ. Команда была рада и довольна, гордилась проделанной работой!
Бета-тестирование. Некоторые итоги
Схема на английском: https://www.xmind.net/m/WkHe/
Бета-тестирование. Проблемы
- Неожиданное использование системы нашими клиентами.
- Сложная локализация клиентских багов, связанных с проблемами локальной подписи.
- Устаревшие клиентские платформы.
- Одна из корневых проблем : это несоответствие полученных изначальных бизнес требований и реальности, а именно полное несоответствие ожидаемых типов клиентов/ клиентских окружающей реальности.
- Взаимодействие с менеджерами и продвиженцами продукта.
- Классическая проблема. Неготовность Команды одновременно вести разработку нового функционала и вести поддержку клиентов.
Чтобы мы изменили сейчас
Итоги
ЗБТ- это очень важный этап в процесс развития Вашего продукта. Самое главное Вы должны понимать какие его цели и на какие вопросы он вам даст ответы.
Слайды доклада можно посмотреть тут.
Другие конференции. Спикер