Почему менеджеры продукта должны заботиться о тестировании
Перевод статьи Карлы Шенике из блога Saucelabs.
Мы рассмотрим, почему менеджеры по продукту должны участвовать в процессе тестирования. Если вы станете активным сторонником и сильным партнером вашей команды разработчиков, это даст больше возможностей для предоставления клиентам высококачественного пользовательского опыта.
Работа менеджера по продукту в первую очередь заключается в том, чтобы приносить пользу своим клиентам с помощью продуктов, которые они контролируют. Чтобы гарантировать качество, эти продукты необходимо тестировать. Хорошо продуманное тестирование перед выпуском дает менеджерам по продуктам уверенность в том, что они могут создавать и реализовывать высококачественные продукты и удобство для пользователей.
Однако, как правило, менеджеры по продуктам сосредоточены на тестировании только в самом конце цикла разработки, например, когда проводят приемочные испытания перед отправкой программного обеспечения пользователю. По сути, это переработка проблем на заключительных этапах, когда много времени и усилий уже было потрачено на конкретный модуль продукта. Обнаружение проблем в конце пагубно, потому что теперь команда должна исправлять проблемы под прессом срочности и не может разрабатывать новые функции, что означает увеличение стоимости задержки. Если менеджер по продукту не интересуется процессами тестирования, ему сложно по-настоящему владеть своим продуктом. Интересуясь процессами тестирования на раннем этапе, менеджеры по продукту могут вернуть себе право собственности на свой продукт.
С чего начать работу менеджерам по продукту?
Чтобы приступить к пониманию тестирования, первым делом нужно посмотреть, как устроено тестирования. Узнав больше о видах тестирования, менеджеры по продукту смогут лучше понять свой продукт с точки зрения тестирования. Есть много способов разобраться в том, как организовать отдел качества в компании. Три основных организационных варианта - это отдельный департамент QA, специальный инженер по обеспечению качества в команде разработчиков, а также «quality hat».
-
В отдельных группах обеспечения качества в основном работают специалисты по обеспечению качества и SDET, что означает, что разработка происходит в другом отделе, а затем новая фича «перебрасывается через забор» для тестирования в отделе обеспечения качества. Это приводит к длительным циклам обратной связи и высокому риску недопонимания.
-
Специализированный инженер по обеспечению качества в команде обычно выполняет сочетание ручного и автоматизированного тестирования и может служить в качестве посредника между разработчиками и менеджером по продукту, то есть оказывая некоторую помощь с критериями приемки.
-
«Quality hat» - это когда ответственность за обеспечение качества берет на себя сама команда разработчиков, без специальной роли QA или QE. В этой модели велик стимул максимально автоматизировать тесты.
Идеальная установка - это та, где каждый отвечает за качество продукта и тестирование. В данном случае наиболее близкой к этому установке будет ««quality hat». Подумав о процессе, в котором приложение будет в конечном итоге тестироваться во время разработки продукта, ваша команда может иметь оптимизированный процесс и цель от начала до конца. Сотрудничество по конвейеру тестирования также побуждает команду сосредоточиться на модели непрерывного тестирования.
Понимание различных типов тестов
Менеджеры по продукту также должны хорошо знать типы тестов, которые необходимо провести. На разных этапах жизненного цикла разработки должны выполняться разные типы тестов, и менеджерам по продуктам важно понимать каждый из них, включая типы, перечисленные ниже.
-
Модульное тестирование предназначено для тестирования отдельных модулей кода. Цель состоит в том, чтобы проверить правильность работы каждой единицы программного кода.
-
Интеграционное тестирование - это уровень тестирования программного обеспечения, при котором отдельные блоки и компоненты объединяются и проверяются, правильно ли они работают вместе как группа.
-
Функциональное тестирование - это процесс проверки способности вашего приложения успешно работать с операционной системой или устройством.
-
Тестирование доступности - это тип тестирования программного обеспечения, которое проверяет, как сайт или приложение работает для пользователей с ограниченными возможностями.
-
Тестирование производительности оценивает, как система ведет себя при определенной рабочей нагрузке. Например, насколько быстро он может обработать запрос, когда одновременно выполняются 2 миллиона других запросов.
-
Пользовательское приемочное тестирование просит заинтересованную сторону (которая может быть пользователем или менеджером по продукту) проверить или принять определенную функциональность или всю программную систему, прежде чем приложение будет перемещено на продакшен.
Если заранее знать, какое тестирование может потребоваться для определенного продукта, то менеджер продукта и группы разработки и тестирования находятся на стадии взаимопонимания с самого начала процесса создания. Включение менеджера по продукту в весь процесс разработки и выпуска программных приложений позволит им лучше контролировать процесс тестирования, чтобы команды могли быть уверены в продукте, который они предоставляют своим клиентам. Роль защитника и сильного партнера вашей команды разработчиков дает еще больше возможностей для предоставления высококачественного продукта для пользователей. У менеджеров по продуктам есть множество способов более полно взаимодействовать со своими командами тестирования. Взгляните на блог Sauce Labs чтобы узнать больше о лучших практиках тестирования и увидеть, как вы можете интегрировать это в свои собственные методы тестирования!