Я много лет работаю в продуктовой компании, которая занимается разработкой мобильных приложений. Провела сотни собеседований аутсорс и продуктовых тестировщиков. И сейчас хочу поделиться наблюдениями о том, что отличает специалистов этих двух направлений.
Следует отметить, что в аутсорсе обычно нанимают на конкретную работу:
- Ручное тестирование, которое часто ограничено функциональным тестированием по требованиям, проверкой интерфейса (подразумевающей сравнение с дизайном без возможности влиять на UX), проверкой переводов для локализации;
- Автоматизация или нагрузочное тестирование.
Бывают исключения, но большая часть аутсорс-проектов проходит в рамках этих задач. В продуктовой компании тестировщик не ограничен таким образом и гораздо глубже погружен в каждый из этапов разработки. Его роль более широкая.
Я пройдусь по основным стадиям разработки продукта, чтобы раскрыть компетенции, которые необходимы на каждом из этапов. Эта статья будет полезна тем, кто хочет погрузиться в тестирование продукта.
Разработка идей для развития продукта
Тестировщик не генерирует основные бизнес-идеи, но может влиять на продукт с помощью своих предложений. Его идеи должны быть своевременны и отвечать потребностям бизнеса. Например, не стоит генерировать предложения, которые не соответствуют текущим целям, а лишь приводят к увеличению бэклога и тратят время команды. Нужно понимать, каким образом пользователи взаимодействуют с приложением, что им интересно, и иметь представление о приоритетных целях компании.
Поэтому для продуктового тестировщика важны следующие компетенции:
- Умение мыслить текущими целями и понимать Product Vision (на этапе запуска MVP и при работе с удержанием пользователей идеи будут принципиально отличаться);
- Знание продуктовых метрик и принципов по проверке гипотез;
- Понимание принципов и техник оценки юзабилити, в том числе готовность проводить опросы и тесты на пользователях;
- Навыки работы с инструментами для анализа маркетинговой и пользовательской статистики.
Развивать эти компетенции поможет общение с продакт-менеджерами, анализ метрик и статистики, изучение соответствующих инструментов и материалов.
Работа с требованиями
Многие продуктовые компании, особенно на этапе стартапа, отличаются отсутствием в команде бизнес-аналитиков, которые, как правило, отвечают за сбор и подготовку требований. Важно отметить, что продакт-менеджеры не бизнес-аналитики. Это люди-движение, они уже генерируют новые идеи, в то время как команда ещё реализует предыдущие. Продакт-менеджерам может просто не хватать ни времени, ни технических скилов (не в обиду кому-то конкретному, но так, правда, бывает), чтобы детально прописывать все требования в нужном виде.
В этом случае нужен человек-фильтр по невыясненным и противоречивым требованиям. Эту роль должен выполнять каждый участник процесса разработки. Но, исходя из моего опыта, тестировщик погружается в нее с особым пристрастием.
«Фильтрация» может происходить на этапе формирования требований или когда пора переходить к тестированию продукта. Второй вариант самый распространенный, но первый эффективнее и именно к нему следует стремиться. Однако, к сожалению, тестирование требований до этапа разработки часто приводит к просьбам не смотреть, не проверять, не вычитывать, потому что «еще не готово». И я неоднократно наблюдала ситуации, когда в момент «готово» оказывается, что вопросы были важны, и если бы на них вовремя отреагировали, то правок было бы меньше.
В аутсорсе не всегда можно внедрить тестирование требований из-за ограниченности бюджета, сроков и обязанностей. В продукте же, где требования формируются внутри команды, обычно таких ограничений нет и безумно важно наладить ранний процесс тестирования требований, пояснить, почему задаваемые вопросы важны.
С другой стороны, неподготовленные тестировщики настаивают на прописывании всех требований в продукте-стартапе. Это не особо эффективно: продукт еще изменчив и фокус исключительно на прописанных требованиях будет замедлять разработку.
Поэтому важно выстраивать гибкий процесс по работе с требованиями. Помочь его наладить может:
- Опыт работы в разных процессах и техническое образование, которое включало в себя семинары по формированию и управлению требованиями. Либо тренинги по бизнес-анализу или работе с требованиями;
- Навыки аргументации, коммуникации и умение работать с возражениями. Их можно развивать как тренингами, так и личностным ростом.
Проектирование интерфейса/UX
Когда целью релизов становится удержание пользователей, на передний план среди характеристик качества продукта выходит удобство использования (юзабилити) — понятность интерфейса, логичность навигации, привлекательность. И появляется необходимость настроить два процесса: тестирование юзабилити на этапе прототипа и/или дизайна и оценка юзабилити уже в ходе основного цикла тестирования приложения. В продукте эти этапы будут обязательным, а в аутсорсе они часто отсутствуют.
К слову, тестирование юзабилити — это базовая компетенция мануального тестировщика (если ссылаться на ISTQB сертификацию тестировщиков). Поэтому вносить предложения в прототипы и дизайн можно вполне правомерно ?
Базовые знания для оценки юзабилити:
- Общие правила оформления интерфейса, принципы юзабилити;
- Работа с цветом и иконографикой;
- Гайдлайны конкретной платформы (iOS, Android) к элементам интерфейса, технологиям;
- Правила оформления текста. Важна грамотность, умение преподнести информацию в текстовом формате и оценить степень ее содержательности;
- Интуитивно понимать и чувствовать пользователя (как использует приложение, какие ошибки может допускать), ставить себя на его место;
- Понимание особенностей и предпочтений по взаимодействию с приложением пользователей из разных стран.
Разработка
На этой стадии не будет отличий между продуктом и аутсорсом.
Проверка конкретных фичей требует умения мыслить алгоритмически — понимать, каким способом запрограммирована фича и прогнозировать потенциальные баги. При этом вне зависимости от того, есть ли доступ к коду, необходимо иметь базовое представление, какие алгоритмы могли использоваться. Здесь окажется полезным «программистское» образование (из университета или специальных тренингов). Оно поможет не только лучше понимать разработчиков, но и определять, какие тесты проводить, а какие осознанно не проводить.
Тестирование
Приоритетом и выделяющейся особенностью в продуктовой разработке является тестирование фич, влияющих на монетизацию: реклама, покупки, продающие баннера, онбординг, сбор статистики. По каждому из направлений есть гайдлайны по внедрению и оформлению, особенности проверки, свои инструменты.
Также есть ряд направлений, которые могут никак не обозначаться в требованиях и не проговариваться вслух. Однако проверки по ним продуктовым тестировщиком должны проводиться.
Рассмотрим несколько примеров:
Тестирование совместимости (конфигурационное)
Важно убедиться, что пользователи разных девайсов, ОС, браузеров не сталкиваются с багами по логике, интерфейсу, производительности.
И НЕверно тестировать:
- Только на одном устройстве (это высокий риск пропущенных багов);
- На всех устройствах подряд (это очень времязатратно);
- На топ-девайсах из статистики (они могут быть одинаковыми по своим характеристикам и тесты бесполезны).
В аутсорсе выбор конфигураций для тестирования может быть ограничен или задан сразу, а в продукте нужно самостоятельно и осознанно выбирать конфигурации для тестов и покупать новые устройства. Для этого следует:
- Разбираться в производителях устройств, в моделях и их отличительных особенностях (вариации экранов, процессоров, графических процессоров, камер и так далее);
- Знать, как влияют разные версии ОС и их настройки на поведение приложения;
- Поддерживать актуальность своих знаний и парка устройств (девайсы и ОС выходят несколько раз в год).
Эти знания не дают в университетах, про это не говорят явно, а изучать нужно. И тут уже вопрос управления временем и своими знаниями.
Тестирование клиент-серверных приложений
Чтобы их проверять нужно знать:
- Что такое серверное API и как его тестировать;
- Особенности протокола, по которому идет взаимодействие клиента с сервером;
- Какие проверки делать на клиенте, какие на сервере и какие только вместе;
- Структуру базы данных (например, если изменяется БД, происходит миграция БД, то возникает риск критических багов);
- Инструменты, помогающие снифферить трафик, работать с БД (поиск и просмотр информации, наполнение тестовыми данными с помощью sql-запросов).
В аутсорсе всё это тоже важно. Однако, есть вероятность столкнуться с сильными ограничениями со стороны заказчика (например, нет доступа к БД), распределением ответственности (серверные программисты сами тестируют API) и отсутствием возможности использовать инструменты. При работе со своим продуктом таких ограничений нет, и погруженность в каждую техническую деталь становится серьезнее и важнее с ростом продукта. Эти знания получают либо через техническое образование в университете, либо заканчивая длительные курсы уже во время работы (по серверной разработке, по базам данных и другие).
Тестирование локализации
Многие продуктовые компании рано или поздно начинают делать приложения «на весь мир». А «весь мир» — это пользователи разных менталитетов, языков, привычек. И одно дело — проверить, что есть переводы на выбранные языки, и совсем другое — проанализировать адаптацию для пользователей из целевых стран.
Хорошо локализованное приложение должно подстраиваться под ряд региональных параметров (форматы дат и времени, погоды, единицы измерения веса, расстояния, валюты, летоисчисление) и под менталитет (восприятие цвета и символов, особенности чувства юмора). В разных странах есть свои праздники и любимые герои, под которые может подбираться контент в приложении. И чтобы проверить локализацию под конкретную страну, нужно либо самим изучить её особенности, либо суметь организовать тестирование нативными тестировщиками (а это поиск подходящих кандидатов и найм, постановка задач, контроль за результатом выполнения).
Аналогичные истории с нагрузочным тестированием, тестированием защищенности и другими техническими направлениями, к которым продукты приходят по мере развития (а некоторым и сразу нужны будут). Продуктовому тестировщику нужно суметь вовремя предупредить появление багов по ним, организовать тестирование. В аутсорсе принятие решений о необходимости проведения этих видов тестирования чаще всего остается в ответственности заказчика.
Саппорт и анализ поведения пользователей после релиза
В большей степени от саппорта поступают либо пользовательские баги, либо вопросы пользователей:
- Для поиска первопричин багов необходимы все вышеперечисленные навыки. Здесь максимальное сходство с аутсорсом.
- Поступающие вопросы интересны с точки зрения того, в каких улучшениях нуждается аудитория. Такую же роль играют отзывы в App Store и Google Play.
Продуктовым тестировщикам чаще доступна статистика по использованию приложения, с помощью которой можно анализировать сценарии использования, длительность пользовательских сессий, типы и объемы обрабатываемых данных, используемые конфигурации и ошибки, с которыми сталкиваются пользователи. Всё это позволяет делать тестирование более продуктивным, улучшая сценарии проверок.
Доступ к статистике дает возможность локализовать пользовательские проблемы максимально быстро и точно. Для этого важно настроить сбор статистики таким образом, чтобы отслеживать шаги конкретного пользователя.
Невозможно хорошо тестировать продукт, не понимая своего пользователя, его ценности и проблемы. Поэтому здесь мы опять говорим про важность знания и практического использования систем сбора статистики — как пользовательской, так и маркетинговой. А также про умение превратить проанализированное в предложения по улучшению продукта.
Заключение
Хороший продуктовый тестировщик — это не просто исполнитель, не тот, кто отстаивает фикс каждого пользовательского бага, пишет тонну тестовой документации, не может работать без описанных требований или увольняется из-за «некачественного продукта». Хороший продуктовый тестировщик — это тот, кто балансирует между пользователем и бизнесом, адаптирует глубину тестирования и свои подходы под текущие цели и условия работы, сопереживает и развивает продукт вместе с продакт-менеджером и другими участниками команды.
Конечно, важно разбираться во всех видах тестирования, владеть уверенной технической базой и инструментами, но без некоторых личностных компетенций эти навыки не будут играть значимой роли. А это уже совсем другая история… ?
Первое размещение на Tproger