При разработке нового продукта рано или поздно появляется вопрос «Нужно ли тратить деньги и время на тестирование?» Не буду говорить, что оно нужно всегда — это не так. На мой взгляд, есть ситуации, в которых тестирование нецелесообразно.

Когда стоит отказаться от тестирования

Представим себе некую Машу, которая в свободное время занимается мыловарением. Она не только пользуется мылом сама, но и делает подарки друзьям, близким и коллегам по работе.

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

Нужно ли Маше тестирование? Конечно же нет. Даже если она прикрутит на сайт форму обратной связи — все равно пользы от тестировщиков никакой. Почему?

Или другой пример: два разработчика решили создать мобильное приложение. Занимаются этим в свободное время для изучения новых технологий. Ничего от своего продукта не ждут, но опубликовать в магазине все-таки попробуют — вдруг что-то из этого получится.

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

Конечно же, есть случаи, когда тестирование перекладывается на конечных пользователей, хотя на разработку и выпуск продукта были потрачены средства и время. Например, Google и Apple спокойно передают свои программы на бета-тестирование, зная, что толпы людей бросятся искать ошибки. Выпусти они даже самый нестабильный продукт и повесь на него табличку «бета» — народ все равно бы тестировал: желание в первых рядах попробовать программы таких популярных компаний очень велико.

Когда тестирование все-таки нужно

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

Со временем не только функций, но и товаров становится больше. В итоге у Маши появляется целый интернет-магазин. Можно ли все еще обойтись без тестирования? Можно. Будет ли хорошим результат? Вряд ли.

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

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

К тому же, ни один, даже самый лучший, разработчик не сможет предотвратить появление ошибок. Я лично знаю пару программистов, которые тщательно проверяют свой код, хорошо продумывают архитектуру приложения. Они разрабатывают прекрасные и качественные продукты, однако даже им «прилетают» задачи с багами, найденными в их идеальном коде. А все потому, что эти разработчики — такие же люди, как и мы с вами. У них бывают проблемы, плохое самочувствие, их отвлекают. Я уже не говорю об интенсивных проектах, где все делается в спешке — как тут не ошибиться?

Как же тогда бета-тестирование?

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

Во-вторых, даже такие компании зачастую сначала тестируют свои продукты, а затем выкладывают их в открытый доступ.

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

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

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

Если же программа решает какие-то серьезные задачи (например, онлайн-банкинг или медицинское ПО), то пользователям явно не захочется получить «сырой» продукт. Подобные приложения должны проходить контроль качества и попадать на рынок в лучшем виде, иначе репутация выпустившей их компании будет навсегда испорчена.

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

Что говорят эксперты

На следующей схеме представлена модель выбора методологии разработки проекта, где показаны разные уровни критичности продукта и количества вовлеченных людей:

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

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

Немного статистики

Какие можно сделать выводы?

И напоследок хочется сказать, что исправить можно многое: «косяки» дизайна, неудобно расположенные элементы, скорость работы, «дырки» в безопасности. Но вот вернуть доверие пользователей — крайне сложно. Если программа не выполняет поставленных задач или наносит людям ущерб — они уйдут к конкурентам. И с очень большой вероятностью не вернутся обратно.