Инвестирование в тестирование. Часть 1. До релиза

Подход к тестированию у некоторых компаний напоминает поход к стоматологу. Пока ничего не болит, про него никто не вспоминает, а вот уж как щека надулась и глаза на лоб от боли лезут – можно заложить аспиринчика и подождать еще недельку ;) К счастью или к сожалению, проект – это не больной зуб, и если вы хотите зарабатывать на своем продукте, то с ним такая отсрочка не пройдет.

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

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

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

Причина 1. Соблюдение дедлайнов и запланированной даты релиза

Если в вашей команде не нашлось места для тестировщика, то и вашему продукту может не найтись места на рынке. Цепочка событий не очень веселая, зато какая интересная!

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

Что может пойти не так?

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

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

Причина 2. Большие планы

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

Что может пойти не так?

Баг найдет не ваш тестировщик, а пользователь. В идеальном случае он сообщит об этом вам на email, свяжется с командой поддержки или с администратором группы в соцсетях, и попросит помочь! Такого лояльного пользователя надо заслужить, а потом холить и лелеять.

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

Причина 3. Вопросы к качеству продукта

Приемо-сдаточные испытания проводятся в двух случаях:

1. Когда продукт разрабатывается внутри команды, но есть сомнения в готовности программы к релизу, и хочется провести независимое тестирование.

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

Давайте обоснуем смысл стороннего тестирования.

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

Этого недостаточно, чтобы быть уверенным в качестве кода продукта и его «незабагованности». Как мы уже говорили, у «домашней» или сторонней команды есть свои тестировщики и разработчики. Они могут предоставить вам свои пользовательские сценарии, обещать золотые горы и моментальное исправление ошибок, если их вдруг найдут пользователи.

Что может пойти не так?

Банально – продукт недостаточно протестирован, и как только дошло дело до релиза, программа тут же показала себя и «обрадовала» новых пользователей вылетами, вечной загрузкой, нерабочими кнопками и прочими штуками. Это чревато перекладыванием ответственности с Фомы на Ерему, следовательно, и временными/финансовыми затратами.

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

Помимо обычных способов проверки продукта, существует еще и UAT-тестирование (User Acceptance Testing – приемочное пользовательское тестирование), конечная стадия приемо-сдаточных испытаний. Здесь бывает необходимо подготовить и конечного пользователя, и программу:

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

Помните:

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

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

А если вы все-таки решили потерпеть, и умудрились выпустить продукт на рынок без адекватного тестирования, что ж. Боржоми пить уже поздно, но кое-что еще можно сделать. И об этом мы расскажем в следующей статье.