Чем отличается работа 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-проектов, нужно отдать предпочтение тому, с которым будет максимально выгодно и комфортно сотрудничать.

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

👍НравитсяПонравилось11
В избранноеВ избранном1
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

часто все хотят

КРІ

только от QA из всех членов команды. это заканчиваться плохо. конечно всякий «менеджмент» любит обмазаться метриками

тайтл статьи вообще не соответсвует тексту. различия затронуты по минимуму. Правильный заголовок «Как хорошо работать на одном продуктовом проекте после одновременной работы на нескольких.» Полностью понимаю это. Рад за вас. В целом норм статья но немного короткая.

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

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

А что касается КПI, что мешает без них хотеть освоить автоматизацию для своего личностного и проффесионального роста, а также для оптимизации процесса тестирования на проекте? Если человек хочет развиваться только ради KПІ, то это черезвычайно печально.

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

Це прям ідеальним світом запахло, напрактиці все далеко не так, компаній з налагодженими процесами дуже мало, а проектів на вчора дужееее багато, куа найняли пізно, девів дофіга, що там тестить і три проекта встигнеші так далі і тому подібне.
Результат — загнаний куа, який через рік/два валить в нібитіє на невідомий час бо працювати так більше неможливо)

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

Ничем. QA должен работать над несколькими проектами «одновременно». В смысле, вести сразу несколько, а точнее несколько десятков проектов.

Никто в здравом уме не станет применять KPI к QA, ибо этим вы убьёте то, зачем их собственно посадили. Вместо роста качества они будут делать вам KPI и прятать проблемы под ковёр. Когда об этом узнаете, будет уже поздно. Сломать людей легко, а вот обратить выгорание после введения KPI — вы не то что не сможете, вы даже пытаться побоитесь. Ибо вам самим будет страшно лишиться иллюзии контроля над процессом. То есть KPI убивает мотивацию прежде всего тем, кто их вводит, а не только тех, кому.

Подписаться на комментарии