Чем отличается работа QA-инженера над одним продуктом и несколькими проектами одновременно. Наблюдения из личного опыта

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Меня зовут Марина Горобчук, я — Manual QA Engineer на проекте Lift, который разрабатывается в экосистеме Genesis. В тестировании я более трех лет. Из них два года работала в компании, которая занималась фулстек-разработкой XR-приложений. Это были мобильные приложения под заказ для любого сегмента на рынке. Тогда я самостоятельно вела 3–4 разных проекта одновременно. Одни могли быть в разработке пару недель, другие — больше года. Все они использовали разные технологии, имели свои особенности, поэтому требовали много внимания и тщательного тестирования.

Сейчас я работаю над одним продуктом, а именно над мобильным приложением для іOS Lift: Story Maker. Это фото/видеоредактор для SMM-специалистов и блогеров. Lift — это готовое решение для создания профессионального контента с помощью шаблонов для социальных сетей. Ежемесячно приложение использует 450 тысяч пользователей, более 2 млн человек загрузили приложение в течение года с момента запуска. Сейчас я единственный QA в команде разработки и веду только один проект.

Начав заниматься одним продуктом, я увидела другой спектр задач QA-специалиста, ощутила значительную разницу в развитии. Хочу поделиться своим опытом, определив основные отличия в работе с одним и несколькими проектами одновременно.

Зона ответственности QA-инженера

Основная задача QA-специалиста — обеспечение качества продукта. Это остается неизменным, независимо от количества проектов. Работая с несколькими приложениями, внимание и время рассеиваются. Каждый проект важен для компании, имеет свой дедлайн. Нужно все успевать, все держать в голове и не тормозить. Проверка нового функционала — основная работа Manual QA-инженера, на это уходит все рабочее время. Просто физически не хватает времени, чтобы проводить анализ требований, разрабатывать стратегию, вести всю документацию. Но этого и не требуется при таком формате.

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

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

Процессы: митинги, эстимейты

Много продуктов = мало процессов. Раньше мы не использовали определенную методологию разработки. Это ускоряло работу, но вносило хаос в процессы. Мы всегда успевали отдать проект в срок, но время на тест сокращалось, и не было возможности участвовать в остальных этапах разработки.

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

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

Зона роста QA-инженера. Наличие КРІ

Сложно оценить, насколько важны, нужны и измеримы КРІ для QA-инженера.
Только сейчас они появились в моей работе. Мне нравится ставить цели, которые максимально связаны с ростом — продукта и моим профессиональным. Это мотивирует развиваться, понимать ценность своего вклада. К примеру, у нас на проекте появилась необходимость автоматизировать тестирование основного флоу пользователя, что повысит качество и уменьшит затраты на ручное тестирование. Это и есть мой КРІ на следующий период. Так я смогу развиваться в направлении Automation QA.

Продуктовая аналитика

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

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

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

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

В планах есть идеи по автоматизации проверки отправки/получения ивентов, чтобы обезопасить себя от ошибок в их записях.

Продукт — это бизнес

Раньше мы разрабатывали B2B-решения по конкретным требованиям от заказчика, которые предоставлялись в начале разработки, иногда менялись и имели свой дедлайн выполнения. Сами приложения были бесплатными на сторах, но их использование было дополнением к основному бизнесу заказчика.

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

Подписки — самая важная часть приложения, их проверка всегда в приоритете. Для этого мы используем TestFlight — тестовое окружение sandbox от Apple, которое покрывает основной флоу теста, но имеет ряд уязвимостей. Например, протестить family subscription в точности с продовским флоу невозможно. От корректности работы подписок напрямую зависит заработок бизнеса. От QA требуется детальных знаний, как работают подписки Apple, как убедиться в прохождении транзакции, и понимания, что мы отправляем на Apple и что получаем взамен.

Саппорт продукта от релиза до нового апдейта

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

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

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

Один продукт — как ребенок всей команды

Много приложений даёт возможность заниматься разными типами продуктов. Особенно при работе с XR-продуктом все приложение интересные, необычные и новые для команды и пользователя. Время для разработки некоторых приложений было всего 1–2 месяца, при этом команда переключалась на другие проекты. Это позволило много учиться, охватывать новые технологии, но не дало возможности влиять на продукт, не было личной мотивации в его развитии.

Сейчас я вижу, что вся команда сконцентрирована на одной долгосрочной цели — создании приложения № 1 для SMM-специалистов и блогеров, которое сосредоточит в себе все необходимые инструменты для создания любого типа контента. Я вижу, как команда уверенно работает над «безумными» креативными идеями, верит в результат, не видит никаких препятствий, и это очень вдохновляет и дает силы. Мне нравится категория моего проекта, возможность проявить и реализовать себя. Круто понимать, что твои знания приумножают продукт. Очень ценно, когда твои идеи принимают и реализуют для достижения общего результата.

Выводы

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

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

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