{"id":13505,"url":"\/distributions\/13505\/click?bit=1&hash=ca3734639136826288c9056e5c8fa03a05e87c4060ae84df200f2c90f5262470","title":"\u0412\u044b \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a? \u0410 \u043f\u043e\u043d\u0438\u043c\u0430\u0435\u0442\u0435 \u0447\u0442\u043e-\u0442\u043e \u0432 \u0438\u0441\u043a\u0443\u0441\u0441\u0442\u0432\u0435 \u043a\u043e\u0434\u0430?","buttonText":"\u041f\u0440\u043e\u0432\u0435\u0440\u0438\u0442\u044c","imageUuid":"f5f0e11f-fefd-52f5-8712-82164a59b7ce","isPaidAndBannersEnabled":false}
Андрей Смагин

Чтиво для продактов и QA-инженеров

Головная боль продакт-менджера – это обеспечение гармоничного взаимодействия с командой, в частности – с разработчиками. Сегодня поговорим конкретно о взаимодействии с QA-инженерами (они же инженеры по тестированию, они же тестировщики).

Если мы зациклены на качественном формировании требований к разработке, планировании и разработке тестирования, мы можем упустить важный момент, когда QA начинает заботиться только об инженерных аспектах своей работы, нежели о мнении клиента. Большая ошибка – создание слишком сложных решений, не релевантных для пользователя.

Давайте посмотрим, как QA-инженер видит процесс:

1. Понимаем сюжет и оказываемые услуги.
2. Создаем тестовые случаи и тестовые данные.
3. Тестируем [автоматизация + руководство].
4. Ищем баги.
5. Обновляем тестовые сценарии.

Как продакт менеджер видит процесс:

1. Поднимаем конверсию с помощью классного дизайна UX/UI.
2. Приоритезируем метрики и работаем над ними.
3. Делаем круче, чем у конкурентов, и стараемся усложнить возможный плагиат (например, какой-нибудь функции).
4. Устраняем потенциальные риски и обеспечиваем бесперебойную работу на всех этапах.

Важно, восполнить этот пробел в понимании, с которым сталкивается каждая Agile-команда.

Что нужно сделать продакту?

1. Максимально понятно составляйте user story с упоминанием всех затрагиваемых систем и customer cases. Лучше создать некий шаблон пользовательской истории, чтобы у команды было понимание «стандарта».

2. Делитесь циклом развития каждой фичи, которая была выпущена по завершению спринта. Это мотивирует QA.

3. Не забывайте о груминге. Ухаживайте за бэклогом, «чистите» и оптимизируйте его. Нужно держать команду в курсе событий и донести до каждого контекст и смысл работы.

4. Убедитесь, что у QA есть доступ к управлению данными (например, Confluence). Плохо, если QA приходится постоянно запрашивать данные.

5. Объясните, каким образом вы будете приоритезировать метрики в случае релиза фичи.

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

Что нужно сделать команде QA?

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

2. Главным QA-инженерам: внедрите KPI, чтобы каждый QA уведомлял о том, как работает фича после ее релиза, и делился этим в общем чате QA.

Это поможет собрать тестовый набор данных, которым вы воспользуетесь в будущем.

3. Периодически взаимодействуйте со службой поддержки клиентов, чтобы понимать болевые точки своей аудитории.

4. Фиксируйте влияние багов в стейджинге и подумайте, как это может повлиять на бизнес и на пользователя.

Проблема: не работает кнопка «Заказать».

Влияние на бизнес: мы потеряли 25 000 пользователей.

5. Подумайте о том, когда пользователь может злоупотребить фичей. Сообщите об этом продакту.

6. Главным QA-инженерам: распорядитесь, что фичи одного модуля не назначаются одному и тому же QA в каждом спринте. Каждый QA получает новый модуль для изучения и тестирования.

7. Определите потребности бизнеса и представьте себе customer journey при тестировании дизайна.

0
Комментарии
Читать все 0 комментариев
null