Что должны знать продакт-менеджеры о тестировании приложений

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

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

1. Модульные тесты

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

Модульное тестирование — это тестирование единицы кодирования, чтобы убедиться, что она работает правильно. Этот тест выполняется, пока разработчик программного обеспечения кодирует. Чтобы выполнить этот тест, написан фрагмент кода [unit test] для тестирования модуля. Та же концепция работает для тестирования компонентов.

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

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

1. Интеграционные тесты

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

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

1. Дымовые тесты

Дымовое тестирование, также известное как проверка сборки, используется для проверки стабильности продукта. Слово «стабильный» в тестировании вызывает следующие распространенные вопросы:

• Является ли стабильная версия готовой к выпуску?

• Стабильный означает, что он больше не содержит ошибок?

Я хотел бы думать, что стандарт того, что является стабильным, будет различаться в компаниях. Но в целом стабильность должна изображать «достаточно безошибочную», чтобы ее можно было запустить в производство, чтобы поведение продукта больше не менялось. Значит стабильно!

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

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

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

1. Регрессионные тесты

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

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

Некоторые инструменты регрессионного тестирования для изучения: Avo Assure, Subject 7, Digivante, Testsigma и т. д.

1. Приемочные испытания

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

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

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

• [ ] Альфа-тесты

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

• [ ] Бета-тесты

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

В итоге,

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

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

Знаете человека, не являющегося техническим специалистом, который пытается проникнуть в сферу управления продуктом? Вы можете поделиться моей предыдущей статьей на тему [Обязательные технические концепции для продакт-менеджеров: ваш путеводитель по разуму разработчика] (https://hackernoon.com/explore-must-know-technical-concepts- для продакт-менеджеров-ваш-путеводитель-по-разуму-разработчика) вместе с ними. Спасибо, что поделился!

Свяжитесь со мной на LinkedIn.