9 ролей QA, о которых вы не знали

9 ролей QA, о которых вы не знали


Автор
Екатерина
Екатерина
QA Lead

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


Мы подключились к созданию решения для распределения и отслеживания доставки из интернет-магазинов. Оно состояло из терминала сбора данных для работников склада и веб-части для менеджеров и клиентов. Решение автоматизирует все: от получения заявки и упаковки до отслеживания посылки по номеру заказа.
Изначально его делал штатный разработчик. Он разрабатывал функционал со слов заказчика, без технического задания, сам проверял функционал. Когда продукт попал к нам, он терял пользователей из-за ошибок и нестабильной работы.


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

Роль 1: Качественник

Наша цель — выпустить качественный продукт, поэтому QA специалист принимает участие на каждом этапе жизненного цикла продукта:

  1. Проверяем функционал на соответствие техническим и бизнес-требованиям, чтобы продукт решал определенные бизнес-задачи;
  2. Выявляем архитектурные несоответствия: что можно реализовать, а что нереализуемо. Сразу обсуждаем с разработчиками, как будем внедрять идеи из технического задания;
  3. Составляем тестовую документацию, в которой разберется новый член команды;
  4. Информируем всех заинтересованных о состоянии продукта и сроках релиза;
  5. Организуем демонстрации продукта.

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

После этого я перешла к тестовой документации, покрыла тест-кейсами весь функционал. Тест-кейсы сэкономили мне время на тестирование: то, что раньше проверяли неделю, мы делали за пару дней.

Что еще почитать

«Как спасти унаследованный проект после кораблекрушения»

Роль 2: Аналитик

Аналитик превращает идеи проектов в требования, и мы в этом помогаем:

  • Если нет аналитика, совместно с заказчиком составляем требования;
  • Если есть аналитик — проверяем техническое задание: находим несоответствия, предлагаем улучшения и следим за обновлениями требований.

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

Роль 3: Организатор

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

Что делает QA:

  1. Организует взаимодействие со всеми членами команды. Не важно, где они находятся — работают дома или на другом континенте;
  2. Выстраивает единые процессы работы над задачами. Так все в команде в курсе текущих задач и знают к кому обращаться с вопросами;
  3. Выстраивает процесс тестирования, составляет тестовую документацию, определяет области тестирования и организует демо;
  4. Контролирует сроки выпуска качественного продукта.


В нашем случае процессов работы не было. Мне нужно было организовать взаимодействие между разработчиками, заказчиком и собой.
Мы подготовили:
1. Воркфлоу, по которому мы будем работать над задачами. Мы определили этапы по 3 недели, по итогам которых смотрели результаты и сверялись с курсом;
2. Сроки, в которые мы выпускаем функционал;
3. Зоны ответственности.

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

Роль 4: Эксперт

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


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

Роль 5: Оптимизатор

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


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

Функционал рос, чаще начали проводить смоук или регрессионное тестирование перед релизом. Каждый тест-кейс я отмечала как пройденный/непройденный, согласно метрике по тестовым случаям. Мы определяли критерий успешности на каждом этапе тестирования: если процент непройденных кейсов превышает норму, это повод проанализировать проблему и, возможно, перенести релиз. Самый простой пример — большая часть кейсов не пройдены в поиске, который курирует определенный разработчик. Иногда простой беседы достаточно, чтобы ошибок стало меньше.

Роль 6: Supporter

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


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

Мы провели нагрузочное тестирование, выявили слабые места, где система «падает», и составили план для разработчиков. Как мы нагружали систему — в статье «Первые шаги по нагрузке продукта».

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

Что еще почитать

«Как получить хорошие оценки и отзывы пользователей»

Роль 7: Юзабилист

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


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

Я предложила закрывать окно заказа только при нажатии на закрытие (крестик), отмена или подтверждение. Так форма перестала закрываться раньше времени, и пользователям стало удобнее.

Что еще почитать

«Как понять, что моему пользователю неудобно, пока он не ушел»

Роль 8: Аудитор

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


В нашем примере аудит не понадобился — мы съездили и изучили все нюансы еще перед аналитикой, поэтому дальше он не потребовался. О том, как мы проводили внешний аудит, мы напишем в одной из следующих статей.

Роль 9: Автоматизатор

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


Первые полгода нам не понадобилась автоматизация. Если вы пытаетесь разобраться, нужна ли она вам, советую прочитать статью «Как понять, что пора автоматизировать тестирование».


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

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

Почувствуйте наш подход и повторите
успех наших клиентов

Напишите нам
АЛЕКСАНДР НОСКОВ
АЛЕКСАНДР НОСКОВ
СЕРГЕЙ ИСАКОВ
СЕРГЕЙ ИСАКОВ