05 апреля 2018

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

Все знают, что 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-команда выросла с одного человека до трех. Мы актуализировали требования, покрыли их тест-кейсами и выстроили процессы работы. Так в релиз начали выходить только проверенные версии. Мы заметили, что жалобы пользователей сократились вдвое  — это показатель того, что пользователи довольны.

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

Понравилась статья?
Подпишитесь на рассылку SimbirSoft! Пришлём письма о лайфхаках в разработке, поделимся опытом управления командами и компанией, а также расскажем о новых ивентах SimbirSoft.

Другие статьи

Вебинар «Красиво vs Качественно. Какие метрики вашего бизнеса зависят от Frontend-разработки?»
12 марта 2024
На форуме Seymartec Energy эксперты SimbirSoft поделятся опытом использовании ИИ в энергетике
07 марта 2024
WMS для управления складом: что такое и как выбрать
07 марта 2024
Написать нам
Оставьте контакты, чтобы обсудить проект и условия
сотрудничества, или позвоните: 8 800 200-99-24
Прикрепить файл до 10Мб
Файл выбран
Можно прикрепить один файл в формате: txt, doc, docx, odt, xls, xlsx, pdf, jpg, jpeg, png.

Размер файла до 10 Мб.
Оставьте свои контакты
SimbirSoft регулярно расширяет штат сотрудников.
Отправьте контакты, чтобы обсудить условия сотрудничества.
Прикрепить резюме, до 10 Мб
Файл выбран
Можно прикрепить один файл в формате: txt, doc, docx, odt, xls, xlsx, pdf, jpg, jpeg, png.

Размер файла до 10 Мб.
Написать нам
Расскажите, какие задачи сейчас на вашем проекте.
Проконсультируем и предложим подходящих специалистов, а также сориентируем по ставкам на аутстаф.
Направление
Количество специалистов
Middle
TeamLead
Senior
TechLead
Прикрепить файл до 10Мб
Файл выбран
Можно прикрепить один файл в формате: txt, doc, docx, odt, xls, xlsx, pdf, jpg, jpeg, png.

Размер файла до 10 Мб.
Экспресс-консультация
Заполните все поля формы.
Эксперт свяжется с вами в течение рабочего дня.
Тематика
Прикрепить файл до 10Мб
Файл выбран
Можно прикрепить один файл в формате: txt, doc, docx, odt, xls, xlsx, pdf, jpg, jpeg, png.

Размер файла до 10 Мб.
Порекомендуйте друга — получите вознаграждение!
  • Middle Fullstack QA Engineer (Mobile)
  • Python-paзработчик
  • Java-разработчик
  • Angular-разработчик
  • Аккаунт-менеджер IT-проектов
  • Системный аналитик
  • QA Engineer Fullstack (Python)
  • C#-разработчик
  • Инженер по нагрузочному тестированию
  • Golang-разработчик
  • DevOps-инженер
  • 1С-аналитик
  • 1C QA Engineer
  • Юрист
  • Разработчик на C++
  • 1С-разработчик
  • DWH-разработчик
  • Разработчик Bitrix24
  • Data Scientist
  • Маркетолог
  • Менеджер по продажам IT SaaS
  • QA Engineer Fullstack (Java/Kotlin)
  • C# /.NET-разработчик
  • Бизнес-аналитик
  • Аналитик DWH
  • Team Lead Java
  • Специалист по адаптации персонала
  • Менеджер проектов 1С
  • Vue-разработчик
  • Руководитель отдела Backend
  • SDET (Java)
  • Менеджер по продажам IT продуктов на иностранное направление
  • Менеджер по продажам IT продуктов
  • Team Lead Python
  • SAP-аналитик
Прикрепить резюме, до 10Мб
Файл выбран
Можно прикрепить один файл в формате: txt, doc, docx, odt, xls, xlsx, pdf, jpg, jpeg, png.

Размер файла до 10 Мб.