Головная боль продакт-менджера – это обеспечение гармоничного взаимодействия с командой, в частности – с разработчиками. Сегодня поговорим конкретно о взаимодействии с 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 при тестировании дизайна.