9 ролей QA, о которых вы не знали
Все знают, что QA-инженеры проверяют ПО и ищут баги. Многие думают, что с этой задачей справится даже простой пользователь, и пытаются обойтись без QA. На самом деле эта роль гораздо глубже, чем принято думать. Я расскажу о ролях QA на одном из моих проектов.
Мы подключились к созданию решения для распределения и отслеживания доставки из интернет-магазинов. Оно состояло из терминала сбора данных для работников склада и веб-части для менеджеров и клиентов. Решение автоматизирует все: от получения заявки и упаковки до отслеживания посылки по номеру заказа.
Изначально его делал штатный разработчик. Он разрабатывал функционал со слов заказчика, без технического задания, сам проверял функционал. Когда продукт попал к нам, он терял пользователей из-за ошибок и нестабильной работы.
Наша команда выстроила систему качества в проекте с нуля, поэтому это идеальный пример, чтобы показать наши роли в действии.
Роль 1: Качественник
Наша цель — выпустить качественный продукт, поэтому QA специалист принимает участие на каждом этапе жизненного цикла продукта:
- Проверяем функционал на соответствие техническим и бизнес-требованиям, чтобы продукт решал определенные бизнес-задачи;
- Выявляем архитектурные несоответствия: что можно реализовать, а что нереализуемо. Сразу обсуждаем с разработчиками, как будем внедрять идеи из технического задания;
- Составляем тестовую документацию, в которой разберется новый член команды;
- Информируем всех заинтересованных о состоянии продукта и сроках релиза;
- Организуем демонстрации продукта.
Итак, мы поняли, что, кроме недоделанного продукта, на проекте нет ничего...
Я начала с анализа и обновления устаревшей документации, которая не соответствовала текущим требованиям. Когда наша команда выросла, документация помогла новым сотрудникам включаться в проект быстрее.
После этого я перешла к тестовой документации, покрыла тест-кейсами весь функционал. Тест-кейсы сэкономили мне время на тестирование: то, что раньше проверяли неделю, мы делали за пару дней.
Что еще почитать
«Как спасти унаследованный проект после кораблекрушения»
Роль 2: Аналитик
Аналитик превращает идеи проектов в требования, и мы в этом помогаем:
- Если нет аналитика, совместно с заказчиком составляем требования;
- Если есть аналитик — проверяем техническое задание: находим несоответствия, предлагаем улучшения и следим за обновлениями требований.
У нас аналитик появился не сразу. До этого особенности продукта изучала я. Чтобы лучше в них разобраться, я поехала на склад, пообщалась с сотрудниками и заказчиками и даже поработала на складе. По итогам я дополнила техническое задание — добавила пожелания всех пользователей и новые требования.
Роль 3: Организатор
Идеально, когда вся команда работает в одном месте, но бывает по-разному. Если участники находятся в разных местах, нужно организовать коммуникацию и процесс работы команды.
Что делает QA:
- Организует взаимодействие со всеми членами команды. Не важно, где они находятся — работают дома или на другом континенте;
- Выстраивает единые процессы работы над задачами. Так все в команде в курсе текущих задач и знают к кому обращаться с вопросами;
- Выстраивает процесс тестирования, составляет тестовую документацию, определяет области тестирования и организует демо;
- Контролирует сроки выпуска качественного продукта.
В нашем случае процессов работы не было. Мне нужно было организовать взаимодействие между разработчиками, заказчиком и собой.
Мы подготовили:
1. Воркфлоу, по которому мы будем работать над задачами. Мы определили этапы по 3 недели, по итогам которых смотрели результаты и сверялись с курсом;
2. Сроки, в которые мы выпускаем функционал;
3. Зоны ответственности.
В результате задачи перестали теряться, работа над ними стала прозрачной для всех участников: каждый знал, к кому идти с какими вопросами. Это сэкономило нам время и упростило подключение новых членов команды.
Роль 4: Эксперт
Анализируем потребности продукта и выбираем инструменты для мануального и автоматизированного тестирования и ведения документации. Эксперт должен хорошо разбираться в разных инструментах, чтобы подобрать подходящий целям и нуждам продукта.
Еще на старте я поняла, что все инструменты надо подбирать и настраивать заново. Так как до этого тестированием занимался сам разработчик, он делал это на свое усмотрение. Я проанализировала и выбрала инструменты тестирования и ведения тестовой документации, которые удовлетворяли целям продукта, и которыми было удобно пользоваться всей команде.
Роль 5: Оптимизатор
Мы собираем метрики по проекту, анализируем их и разрабатываем план дальнейших улучшений наших продуктов.
Существует много метрик, и не все они нужны в проекте одновременно. Обычно мы определяем, что будем измерять, после погружения в проект и анализа проблем.
Вернемся к началу работы. Я не снимала метрики первые пару месяцев, пока адаптировались и настраивали процессы работы.
Функционал рос, чаще начали проводить смоук или регрессионное тестирование перед релизом. Каждый тест-кейс я отмечала как пройденный/непройденный, согласно метрике по тестовым случаям. Мы определяли критерий успешности на каждом этапе тестирования: если процент непройденных кейсов превышает норму, это повод проанализировать проблему и, возможно, перенести релиз. Самый простой пример — большая часть кейсов не пройдены в поиске, который курирует определенный разработчик. Иногда простой беседы достаточно, чтобы ошибок стало меньше.
Роль 6: Supporter
Мы собираем фидбек от пользователей или заказчика: анализируем, что неудобно, где сложно и чего не хватает. Затем эти предложения и улучшения обсуждаем с заказчиком. После выпуска продукта следим, что пользователи больше не сталкиваются с такими проблемами.
Еще во время поездки на склад я нашла слабые места, на которые жаловались пользователи. Например, система сильно «тормозила» без проверки нагрузки. Клиент ждал по несколько минут, чтобы посмотреть статус заказа или добавить адрес доставки. В итоге он нервничал и жаловался на сервис. Компания теряла клиента.
Мы провели нагрузочное тестирование, выявили слабые места, где система «падает», и составили план для разработчиков. Как мы нагружали систему — в статье «Первые шаги по нагрузке продукта».
Через пару недель мы собрали фидбек от фокус-группы и получили положительный ответ. Процент отказов у компании сократился.
Что еще почитать
«Как получить хорошие оценки и отзывы пользователей»
Роль 7: Юзабилист
Мы анализируем удобство использования продуктом. Иногда проверяем сами по гайдлайнам, иногда привлекаем фокус-группы. Это нужно, когда область применения нетипична. Например, приложение для охотников или дальнобойщиков: QA инженерам сложно предположить, как поведет себя охотник на месте действия или в какую область экрана дальнобойщик нажимает во время движения. По итогам собираем данные и дорабатываем продукт.
После того, как продукт заработал стабильно, мы занялись менее очевидными, но не менее важными вещами — удобством. Так мы выявили проблему при оформлении заказа. При заполнении даты и времени доставки с помощью календаря клиент мог попасть мимо формы. Тогда она закрывалась, и все введенные данные по заказу стирались, приходилось заполнять все заново.
Я предложила закрывать окно заказа только при нажатии на закрытие (крестик), отмена или подтверждение. Так форма перестала закрываться раньше времени, и пользователям стало удобнее.
Что еще почитать
«Как понять, что моему пользователю неудобно, пока он не ушел»
Роль 8: Аудитор
Для аудита мы ездим в офис заказчика: на месте анализируем состояние продукта, выявляем слабые и уязвимые места, процессы работы, чего не хватает для полноценной работы.
Так получаем отчет с проблемами и их решениями, разрабатываем стратегию исправлений и улучшений.
В нашем примере аудит не понадобился — мы съездили и изучили все нюансы еще перед аналитикой, поэтому дальше он не потребовался. О том, как мы проводили внешний аудит, мы напишем в одной из следующих статей.
Роль 9: Автоматизатор
Анализируем, какие действия можно автоматизировать, чтобы сэкономить время на рутине. Затем выявляем, что из найденного функционала можно покрыть автотестами, составляем план и автоматизируем.
Первые полгода нам не понадобилась автоматизация. Если вы пытаетесь разобраться, нужна ли она вам, советую прочитать статью «Как понять, что пора автоматизировать тестирование».
За год работы QA-команда выросла с одного человека до трех. Мы актуализировали требования, покрыли их тест-кейсами и выстроили процессы работы. Так в релиз начали выходить только проверенные версии. Мы заметили, что жалобы пользователей сократились вдвое — это показатель того, что пользователи довольны.
Все это получилось благодаря слаженной работе команды, которую мы выстроили сообща. Наши специалисты могут комбинировать роли в зависимости от потребностей и целей бизнеса, чтобы ваши продукты всегда отвечали вашим потребностям.