Тестирование возникает на разных этапах — при создании требований, при дизайне или разработке. Как кажется на первый взгляд, это необязательный этап, который замедляет создание продукта и делает его дороже. На самом деле, это не так. В этом уроке мы подробнее обсудим эту тему и выясним, какое место занимает тестирование в разработке продукта.
Почему тестирование важно
Возможно, вы слышали про игру Cyberpunk 2077 от студии CD Projekt Red. Как выяснилось уже после релиза, в финальной версии игры осталось много ошибок и багов, который портили все впечатление и расстраивали геймеров. Так произошло, потому что компания не уделила достаточно внимания тестированию.
Даже несмотря на такие показательные примеры, тестировщики иногда сталкиваются с предвзятым отношением к своей работе. Некоторые компании рассуждают так: «Без разработчиков обойтись нельзя — никто не напишет код приложения вместо них. А вот без тестировщиков можно и обойтись. Просто наймем самых профессиональных программистов, которые не будут допускать ошибки».
Практика показывает, что такой подход не работает. Любое приложение должно создаваться командой, в которой есть и программисты, и специалисты по обеспечению качества. Тестирование — это важный этап, поэтому большинство компаний выбирает тратить ресурсы на него. А ресурсов уходит много. Компании приходится:
- Платить зарплаты тестировщикам, их менеджерам и HR-специалистам
- Покупать инструменты для тестирования
- Закладывать дополнительное время на тестирование. Если речь идет о регрессионном тестировании, то на него уходит даже больше времени, чем на разработку
В обмен на все эти ресурсы компании получают два полезных момента:
Тестирование снижает затраты на проект в целом. Чем раньше мы обнаружим ошибку, тем проще ее исправить. Для примера представим, что аналитики проекта недостаточно качественно подготовили требования. В таком случае разработчики неверно реализуют продукт, и придется все переделывать. То же самое с ошибками на этапе дизайна — если они обнаружатся на этапе разработки, исправить их будет намного сложнее. Все эти исправления увеличивают стоимость и время разработки продукта. Так тестирование экономит ресурсы — помогает выявлять ошибки на ранних этапах, исправлять их быстрее и дешевле.
Тестирование создает позитивное мнение о бренде. Есть еще один неочевидный момент — восприятие бренда. Если команда проекта решила сэкономить на тестировании, в готовом продукте неизбежно появятся баги и ошибки. Скорее всего, их обнаружат пользователи. Тогда они либо просто уйдут к конкуренту, либо публично расскажут о багах. Тогда репутация продукта будет испорчена, а еще компания упустит прибыль.
Несмотря на всю пользу от тестирования, в нем важно соблюдать баланс. Например, иногда тестировщики слишком увлекаются и настаивают на исправлении незначительных багов, которые не влияют на функциональность. Так они замедляют разработку, что тоже не совсем верный подход. Как и в разработке, здесь важен баланс между скоростью и качеством. Тестирование должно быть быстрым и качественным, чтобы не замедлять разработку и не тормозить выход продукта на рынок.
Когда полное тестирование не нужно
Выше мы обсуждали плюсы тестирования, но из них не следует, что каждому проекту нужен огромный штат разработчиков.
Подробное тестирование не нужно при работе над MVP (Minimum Viable Product) — это минимально жизнеспособный продукт. С его помощью продакт-менеджеры проверяют свои гипотезы, например:
- Станут ли люди чаще нажимать кнопку «Купить», если перекрасить ее из серого в красный?
- Будут ли люди пользоваться фичей «определи фрукт по фотографии» в нашем приложении по доставке продуктов?
С одной стороны, продакт-менеджеры могут ответить на эти вопросы и другими способами — провести массовый опрос или глубинное интервью. Но эффективнее подход с MVP — быстро и дешево создать первую версию фичи, добавить ее в продукт и посмотреть на реакцию пользователей. Если фича окажется полезной, то в дальнейшем команда продукта доработает ее и исправит ошибки.
При создании MVP мы тестируем только основной позитивный пользовательский сценарий. Но это не означает, что качеством всегда можно пренебрегать.
Тут все компании находятся в разных условиях. Серьезному продукту с большой и активной пользовательской аудиторией в любом случае придется вложиться в тестирование, даже если речь идет о небольшой новой фиче. Если компания только выходит на рынок, ее немногочисленные пользователи будут более лояльны к багам, потому что они ждут от разработчиков инновационного подхода и экспериментов.
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты
- Статья «Как учиться и справляться с негативными мыслями»
- Статья «Ловушки обучения»
- Статья «Сложные простые задачи по программированию»
- Вебинар «Как самостоятельно учиться»
Для полного доступа к курсу нужен базовый план
Базовый план откроет полный доступ ко всем курсам, упражнениям и урокам Хекслета, проектам и пожизненный доступ к теории пройденных уроков. Подписку можно отменить в любой момент.
