http://hawkhouse.ru/wp-content/uploads/2017/07/050717-hawkhouse1-1.jpg		

Автоматизация функционального и нагрузочного тестирования: когда достаточно одного типа тестов?

captcha

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

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

В данной статье мы рассмотрим три возможных сценария:

  • Отказ от функционального тестирования и использование только нагрузочного;
  • Отказ от нагрузочного тестирования и использование только функционального;
  • Использование как функционального, так и нагрузочного тестирования.

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

Функциональное тестирование

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

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

Функциональное тестирование позволяет получить ответы на любые вопросы подобного характера.

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

Нагрузочное тестирование

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

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

В поисках ответов на такие вопросы помогает именно нагрузочное тестирование.

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

Сценарий первый: отказ от функционального тестирования и использование только нагрузочного

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

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

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

Крупный колл-центр

При организации перехода программного продукта на новый уровень производительности нагрузочные тесты выходят на первый план

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

Отдельно здесь стоит упомянуть об автоматизированных функциональных тестах. Эксперт компании Hawk House Integration Алексей Ломаев отмечает:

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

Сценарий второй: отказ от нагрузочного тестирования и использование только функционального

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

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

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

Сценарий третий: использование как функционального, так и нагрузочного тестирования

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

Сложный выбор

Выбрать что-то одно порой просто невозможно

Заключение

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

Специалисты настоятельно рекомендуют не торопиться с уходом от тестов. Последствия непродуманного шага могут быть крайне неприятными.

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