Работа в продуктовой компании: какие навыки нужны тестировщику

Наталья Савастюк

Head of QA Department, офис разработки компании AIBY

Я много лет работаю в продуктовой компании, которая занимается разработкой мобильных приложений. Провела сотни собеседований аутсорс и продуктовых тестировщиков. И сейчас хочу поделиться наблюдениями о том, что отличает специалистов этих двух направлений.

Следует отметить, что в аутсорсе обычно нанимают на конкретную работу:

• Ручное тестирование, которое часто ограничено функциональным тестированием по требованиям, проверкой интерфейса (подразумевающей сравнение с дизайном без возможности влиять на UX), проверкой переводов для локализации;
• Автоматизация или нагрузочное тестирование.

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

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

Разработка идей для развития продукта

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

Поэтому для продуктового тестировщика важны следующие компетенции: 

1. Умение мыслить текущими целями и понимать Product Vision (на этапе запуска MVP и при работе с удержанием пользователей идеи будут принципиально отличаться);
2. Знание продуктовых метрик и принципов по проверке гипотез;
3. Понимание принципов и техник оценки юзабилити, в том числе готовность проводить опросы и тесты на пользователях;
4. Навыки работы с инструментами для анализа маркетинговой и пользовательской статистики.

Развивать эти компетенции поможет общение с продакт-менеджерами, анализ метрик и статистики, изучение соответствующих инструментов и материалов.

Работа с требованиями

Многие продуктовые компании, особенно на этапе стартапа, отличаются отсутствием в команде бизнес-аналитиков, которые, как правило, отвечают за сбор и подготовку требований. Важно отметить, что продакт-менеджеры не бизнес-аналитики. Это люди-движение, они уже генерируют новые идеи, в то время как команда ещё реализует предыдущие. Продакт-менеджерам может просто не хватать ни времени, ни технических скилов (не в обиду кому-то конкретному, но так, правда, бывает), чтобы детально прописывать все требования в нужном виде.

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

«Фильтрация» может происходить на этапе формирования требований или когда пора переходить к тестированию продукта. Второй вариант самый распространенный, но первый эффективнее и именно к нему следует стремиться. Однако, к сожалению, тестирование требований до этапа разработки часто приводит к просьбам не смотреть, не проверять, не вычитывать, потому что «еще не готово». И я неоднократно наблюдала ситуации, когда в момент «готово» оказывается, что вопросы были важны, и если бы на них вовремя отреагировали, то правок было бы меньше.

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

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

Поэтому важно выстраивать гибкий процесс по работе с требованиями. Помочь его наладить может:

1. Опыт работы в разных процессах и техническое образование, которое включало в себя семинары по формированию и управлению требованиями. Либо тренинги по бизнес-анализу или работе с требованиями;
2. Навыки аргументации, коммуникации и умение работать с возражениями. Их можно развивать как тренингами, так и личностным ростом.

Проектирование интерфейса/UX

Когда целью релизов становится удержание пользователей, на передний план среди характеристик качества продукта выходит удобство использования (юзабилити) — понятность интерфейса, логичность навигации, привлекательность. И появляется необходимость настроить два процесса: тестирование юзабилити на этапе прототипа и/или дизайна и оценка юзабилити уже в ходе основного цикла тестирования приложения. В продукте эти этапы будут обязательным, а в аутсорсе они часто отсутствуют.

К слову, тестирование юзабилити — это базовая компетенция мануального тестировщика (если ссылаться на ISTQB сертификацию тестировщиков). Поэтому вносить предложения в прототипы и дизайн можно вполне правомерно :)

Базовые знания для оценки юзабилити:

1. Общие правила оформления интерфейса, принципы юзабилити;
2. Работа с цветом и иконографикой;
3. Гайдлайны конкретной платформы (iOS, Android) к элементам интерфейса, технологиям;
4. Правила оформления текста. Важна грамотность, умение преподнести информацию в текстовом формате и оценить степень ее содержательности;
5. Интуитивно понимать и чувствовать пользователя (как использует приложение, какие ошибки может допускать), ставить себя на его место;
6. Понимание особенностей и предпочтений по взаимодействию с приложением пользователей из разных стран.

Разработка

На этой стадии не будет отличий между продуктом и аутсорсом.

Проверка конкретных фичей требует умения мыслить алгоритмически — понимать, каким способом запрограммирована фича и прогнозировать потенциальные баги. При этом вне зависимости от того, есть ли доступ к коду, необходимо иметь базовое представление, какие алгоритмы могли использоваться. Здесь окажется полезным «программистское» образование (из университета или специальных тренингов). Оно поможет не только лучше понимать разработчиков, но и определять, какие тесты проводить, а какие осознанно не проводить.

Тестирование

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

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

Рассмотрим несколько примеров:

Тестирование совместимости (конфигурационное)

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

И НЕверно тестировать:

• Только на одном устройстве (это высокий риск пропущенных багов);
• На всех устройствах подряд (это очень времязатратно);
• На топ-девайсах из статистики (они могут быть одинаковыми по своим характеристикам и тесты бесполезны).

В аутсорсе выбор конфигураций для тестирования может быть ограничен или задан сразу, а в продукте нужно самостоятельно и осознанно выбирать конфигурации для тестов и покупать новые устройства.  Для этого следует:

1. Разбираться в производителях устройств, в моделях и их отличительных особенностях (вариации экранов, процессоров, графических процессоров, камер и так далее);
2. Знать, как влияют разные версии ОС и их настройки на поведение приложения;
3. Поддерживать актуальность своих знаний и парка устройств (девайсы и ОС выходят несколько раз в год).

Эти знания не дают в университетах, про это не говорят явно, а изучать нужно. И тут уже вопрос управления временем и своими знаниями.

Тестирование клиент-серверных приложений

Чтобы их проверять нужно знать:

1. Что такое серверное API и как его тестировать;
2. Особенности протокола, по которому идет взаимодействие клиента с сервером;
3. Какие проверки делать на клиенте, какие на сервере и какие только вместе;
4. Структуру базы данных (например, если изменяется БД, происходит миграция БД, то возникает риск критических багов);
5. Инструменты, помогающие снифферить трафик, работать с БД (поиск и просмотр информации, наполнение тестовыми данными с помощью sql-запросов).

В аутсорсе всё это тоже важно. Однако, есть вероятность столкнуться с  сильными ограничениями со стороны заказчика (например, нет доступа к БД), распределением ответственности (серверные программисты сами тестируют API) и отсутствием возможности использовать инструменты. При работе со своим продуктом таких ограничений нет, и погруженность в каждую техническую деталь становится серьезнее и важнее с ростом продукта. Эти знания получают либо через техническое образование в университете, либо заканчивая длительные курсы уже во время работы (по серверной разработке, по базам данных и другие).

Тестирование локализации

Многие продуктовые компании рано или поздно начинают делать приложения «на весь мир». А «весь мир» —  это пользователи разных менталитетов, языков, привычек. И одно дело — проверить, что есть переводы на выбранные языки, и совсем другое — проанализировать адаптацию для пользователей из целевых стран.

Хорошо локализованное приложение должно подстраиваться под ряд региональных параметров (форматы дат и времени, погоды, единицы измерения веса, расстояния, валюты, летоисчисление) и под менталитет (восприятие цвета и символов, особенности чувства юмора). В разных странах есть свои праздники и любимые герои, под которые может подбираться контент в приложении. И чтобы проверить локализацию под конкретную страну, нужно либо самим изучить её особенности, либо суметь организовать тестирование нативными тестировщиками (а это поиск подходящих кандидатов и найм, постановка задач, контроль за результатом выполнения).

Аналогичные истории с нагрузочным тестированием, тестированием защищенности и другими техническими направлениями, к которым продукты приходят по мере развития (а некоторым и сразу нужны будут). Продуктовому тестировщику нужно суметь вовремя предупредить появление багов по ним, организовать тестирование. В аутсорсе принятие решений о необходимости проведения этих видов  тестирования чаще всего остается в ответственности заказчика.

Саппорт и анализ поведения пользователей после релиза

В большей степени от саппорта поступают либо пользовательские баги, либо вопросы пользователей:

• Для поиска первопричин багов необходимы все вышеперечисленные навыки. Здесь максимальное сходство с аутсорсом.
• Поступающие вопросы интересны с точки зрения того, в каких улучшениях нуждается аудитория. Такую же роль играют отзывы в App Store и Google Play.

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

Доступ к статистике дает возможность локализовать пользовательские проблемы максимально быстро и точно. Для этого важно настроить сбор статистики таким образом, чтобы отслеживать шаги конкретного пользователя.

Невозможно хорошо тестировать продукт, не понимая своего пользователя, его ценности и проблемы. Поэтому здесь мы опять говорим про важность знания и практического использования систем сбора статистики — как пользовательской, так и маркетинговой. А также про умение превратить проанализированное в предложения по улучшению продукта.

Заключение

Хороший продуктовый тестировщик — это не просто исполнитель, не тот, кто отстаивает фикс каждого пользовательского бага, пишет тонну тестовой документации, не может работать без описанных требований или увольняется из-за «некачественного продукта». Хороший продуктовый тестировщик — это тот, кто балансирует между пользователем и бизнесом, адаптирует глубину тестирования и свои подходы под текущие цели и условия работы, сопереживает и развивает продукт вместе с продакт-менеджером и другими участниками команды.

Конечно, важно разбираться во всех видах тестирования, владеть уверенной технической базой и инструментами, но без некоторых личностных компетенций эти навыки не будут играть значимой роли. А это уже совсем другая история… ?