При разработке нового продукта рано или поздно появляется вопрос «Нужно ли тратить деньги и время на тестирование?» Не буду говорить, что оно нужно всегда — это не так. На мой взгляд, есть ситуации, в которых тестирование нецелесообразно.
Когда стоит отказаться от тестирования
Представим себе некую Машу, которая в свободное время занимается мыловарением. Она не только пользуется мылом сама, но и делает подарки друзьям, близким и коллегам по работе.
И вот, получив очень хорошие отзывы, Маша решает попробовать продавать мыло. Делает себе сайт с простым списком товаров и контактной информацией. Никаких сложностей, вроде оформления заказа или добавления в корзину, там нет.
Нужно ли Маше тестирование? Конечно же нет. Даже если она прикрутит на сайт форму обратной связи — все равно пользы от тестировщиков никакой. Почему?
Все очень просто:
- Маша только пробует продавать. Она не знает, будет ли заниматься этим серьезно или нет — это всего лишь хобби.
- Маша не вкладывала деньги в создание сайта. Либо она сделала себе его сама (простых инструментов сейчас хватает), либо получила крохотную страничку за минимальную плату.
- У Маши еще нет клиентов, которые могут расстроиться из-за неработающего сайта и уйти к другим продавцам. Заплатив тестировщикам, она рискует зря потратить деньги на то, что пока не является способом получения прибыли.
Или другой пример: два разработчика решили создать мобильное приложение. Занимаются этим в свободное время для изучения новых технологий. Ничего от своего продукта не ждут, но опубликовать в магазине все-таки попробуют — вдруг что-то из этого получится.
Нужно ли им на таком этапе тестирование? Вряд ли. Опять-таки, как и в случае с Машей, ребята просто любят свою работу и хотят развиваться, их пока не интересует доход от проекта. Пойдет — хорошо, не пойдет — ну и ладно. Работа уже есть, деньги есть, потерь никаких, ведь все задумывалось как обучение.
Конечно же, есть случаи, когда тестирование перекладывается на конечных пользователей, хотя на разработку и выпуск продукта были потрачены средства и время. Например, Google и Apple спокойно передают свои программы на бета-тестирование, зная, что толпы людей бросятся искать ошибки. Выпусти они даже самый нестабильный продукт и повесь на него табличку «бета» — народ все равно бы тестировал: желание в первых рядах попробовать программы таких популярных компаний очень велико.
Когда тестирование все-таки нужно
А теперь вернемся к ранее приведенным примерам. Допустим, продажи мыла пошли в гору, и Маша начала задумываться о том, не сделать ли это полноценным бизнесом. На сайте теперь нужны и добавление в корзину, и оформление заказа, и полноценная оплата.
Со временем не только функций, но и товаров становится больше. В итоге у Маши появляется целый интернет-магазин. Можно ли все еще обойтись без тестирования? Можно. Будет ли хорошим результат? Вряд ли.
Сложным продуктам нужен комплексный подход. Если бизнес приносит деньги, и есть риск потерять клиентов при малейших проблемах — разработка и поддержка начинают требовать большей ответственности. Никто не будет оформлять заказы в интернет-магазине, где товары не добавляются в корзину, страница оплаты не всегда работает, а форма обратной связи возвращает какие-то странные ошибки. На рынке очень большая конкуренция. И если Маша не монополист, то она вскоре растеряет всех клиентов.
С разработчиками и их приложением та же ситуация. Пока они не нацелены на продажи, они могут вообще ничего не тестировать. Но как только на их продукт обращают внимание и начинают им массово пользоваться, без тестирования становится все сложнее и сложнее. Особенно, если система обладает широким функционалом.
К тому же, ни один, даже самый лучший, разработчик не сможет предотвратить появление ошибок. Я лично знаю пару программистов, которые тщательно проверяют свой код, хорошо продумывают архитектуру приложения. Они разрабатывают прекрасные и качественные продукты, однако даже им «прилетают» задачи с багами, найденными в их идеальном коде. А все потому, что эти разработчики — такие же люди, как и мы с вами. У них бывают проблемы, плохое самочувствие, их отвлекают. Я уже не говорю об интенсивных проектах, где все делается в спешке — как тут не ошибиться?
Как же тогда бета-тестирование?
Во-первых, не так много компаний могут позволить себе подобную роскошь: не все настолько популярны среди миллионов пользователей.
Во-вторых, даже такие компании зачастую сначала тестируют свои продукты, а затем выкладывают их в открытый доступ.
В-третьих, за результатами бета-тестирования и потоком багрепортов все равно следят тестировщики. Именно им нужно проанализировать проблемы, подготовить отчеты и совместно с остальной командой расставить приоритеты для внесения правок. Иначе бета-тестирование не принесет ничего, кроме огромного количества писем с информацией об ошибках.
Конечно, если продукт маленький, можно обойтись и багрепортами со стороны пользователей. Однако много ли людей захотят тестировать что-то неизвестное просто так? Если же начать им платить — появятся дополнительные затраты, а экономия на профессиональном тестировании окажется сомнительной, поскольку ни за качество, ни за результат никто нести ответственности не будет.
Простые пользователи не умеют подходить к проверке комплексно, локализовывать ошибки и грамотно их описывать. Они не могут провести глубокий анализ тестируемого приложения, составить сценарии использования, объективно оценить удобство и возникающие проблемы — это не их работа. И конечно же, они не могут подготовить грамотные и полезные рекомендации по улучшению программы, обеспечить отчетность руководству. Поэтому результаты бета-тестирования все равно приходится обрабатывать профессионалам.
Если же программа решает какие-то серьезные задачи (например, онлайн-банкинг или медицинское ПО), то пользователям явно не захочется получить «сырой» продукт. Подобные приложения должны проходить контроль качества и попадать на рынок в лучшем виде, иначе репутация выпустившей их компании будет навсегда испорчена.
Есть еще и такой нюанс, как оценка производительности и проверка работы продукта под нагрузкой. Это очень важное направление тестирования, которое позволяет заранее предупредить появление критичных проблем, связанных с большим количеством пользователей. Его грамотная организация напрямую влияет на качество продукта. Нет ничего хуже тормозящей программы, с постоянными падениями и зависаниями. Вряд ли кому-то захочется такое терпеть. Я уже не говорю о тестировании безопасности, где важно быть профессионалом своего дела, иначе данные пользователей вполне могут оказаться в руках злоумышленников.
Что говорят эксперты
Алистер Коберн, один из адептов гибкой методологии разработки (Agile), дал хорошее определение уровням критичности программного обеспечения и ущербу, который могут нанести найденные в нем проблемы. Так, согласно этому определению, потери могут быть следующими:
- комфорт в работе — из-за поломки системы людям придется выполнять больше ручной работы или связываться друг с другом, чтобы устранить недостатки коммуникаций. Например, проблемы в системах контроля продаж или управления корпоративной инфраструктурой;
- восполнимая сумма — потеря средств принесет лишь мелкие неудобства. Например, ошибки в счетах или при выплате зарплат. Эти проблемы легко исправить, приложив дополнительные усилия;
- существенная сумма — потеря средств, способная привести к банкротству. Хорошим примером являются ошибки в банковских системах;
- жизнь — сбои в системе могут повлечь за собой смерть других людей. Например, атомные станции, космические шаттлы, системы управления самолетами.
На следующей схеме представлена модель выбора методологии разработки проекта, где показаны разные уровни критичности продукта и количества вовлеченных людей:
Чем ниже и левее по шкале, тем проще становится продукт, и тем менее затратным является процесс его разработки. Пользователям же, в случае возникновения сбоев, будет нанесен меньший ущерб. Если вспомнить Машу и ее хобби, то проблемы на сайте с каталогом привели бы лишь к утрате интереса или дополнительным вопросам со стороны пользователей — та самая потеря комфорта.
Но чем выше и правее по шкале, тем сложнее и комплекснее становится создаваемый продукт: растут и ответственность со стороны его владельцев, и степень важности правильно налаженных коммуникаций. Соответственно повышается риск нанесения серьезного ущерба другим людям. В этом случае Маша, в интернет-магазине которой при оплате снимается двойная сумма со счета пользователя, получила бы кучу жалоб, головную боль с возвратом денег и недоверие покупателей. В результате чего бизнес бы значительно пострадал.
Немного статистики
- В 1990 году абоненты американского оператора сотовой связи AT&T не могли пользоваться дальней связью в течение 9 часов. Причиной стало обновление программного обеспечения. Убытки компании составили 60 миллионов долларов.
- Баг американской системы противовоздушной обороны Patriot, выпущенной в 1991 году, унес жизни 28-ми солдат. Точность расчетов системы падала при использовании более 14-ти часов. В реальных условиях она была задействована около 100 часов.
- В 1974 году один программист написал систему расчета платежей, где года записывались в виде двух последних цифр, что влекло за собой проблемы с вычислениями в 2000-х. В 1995 году компания, которой принадлежала программа, потеряла несколько сотен миллиардов долларов в процессе замены ПО на компьютерах по всему миру.
- В 1994 году компании Disney пришлось иметь дело с большим числом разгневанных покупателей. Ее первая компьютерная игра, The Lion King Animated Storybook, запускалась только на небольшом числе компьютеров — таких, которые использовали разработчики, когда писали код. История также попала в новости многих газет и телеканалов.
- В 1994 году рейс №140 компании China Airlines закончился гибелью 271 человека. Причиной стал баг в программном обеспечении, из-за которого самолет потерял управление и упал при посадке.
Какие можно сделать выводы?
Итак, тестирование не нужно, если продукт:
- делается для себя;
- не нацелен на продажи;
- не предусматривает особых финансовых вложений;
- не используется другими людьми или не создает им существенных проблем.
Тестирование необходимо, если:
- продукт делается с целью получения прибыли;
- он призван решать важные задачи;
- плохое качество выпущенного продукта нанесет удар по репутации компании и понизит ее авторитет среди пользователей.
И напоследок хочется сказать, что исправить можно многое: «косяки» дизайна, неудобно расположенные элементы, скорость работы, «дырки» в безопасности. Но вот вернуть доверие пользователей — крайне сложно. Если программа не выполняет поставленных задач или наносит людям ущерб — они уйдут к конкурентам. И с очень большой вероятностью не вернутся обратно.
