Такой подход меня удивляет. Разве вы будете указывать строителю, какую марку бетона выбрать для постройки дома? Или автомеханику – какую деталь двигателя ремонтировать, а какую нет, если в машине мотор забарахлил? Вряд ли, ведь это серьезные технические вопросы, решение которых надо доверить профессионалу. У профессионала есть необходимые навыки и инструменты, которые позволяют ему решить проблему быстрее и дешевле.
Зачем считать деньги
В Гражданском Кодексе есть понятие «экономия подрядчика за счет опыта и знаний». Его смысл в том, что работу выполняет профессионал, который знает, как оптимизировать процесс, как сделать лучше, но при этом дешевле. И разработчики как профессионалы должны выдавать заказчику лучшие решения за наименьшие деньги.Но на самом деле программисты сосредоточены на другом. Многие из них уверены, что разработка ПО – это чисто технический процесс, который, само собой, имеет свою стоимость, но дело программиста – писать, а не деньги считать. Однако, на мой взгляд, разработка – это прежде всего экономический проект, за которым стоят деньги и расчеты, и только после этого – техническая задача.
Логика тут простая: бизнесу – тем самым клиентам, которые заказывают нам разработку ПО для своих компаний, – на самом деле нужен вовсе не софт. Бизнесу нужны деньги, выгода, которую этот софт принесет.
А значит, и программистам не обойтись без понимания экономики разработки, знания стоимости технических решений и того, какие из них оптимальны с точки зрения не только технологии, но и финансов.
Разработка ПО – вообще не самая дешевая часть бизнеса, но некачественный софт может привести к большим потерям. Даже простой оборудования ведет к упущенной выгоде, а проблемы с ПО могут привести к миллионным потерям. Поэтому разработчик как профессионал должен быть уверен в качестве своего продукта и гарантировать это своему клиенту. А ведь именно качество продукта – важнейший показатель. И заказчик должен знать, что это качество можно измерить и быть в нем уверенным. А как именно – это уже задача программиста.
Я, как и многие мои коллеги, считаю, что программисты не должны обсуждать с заказчиком инженерные решения. Достаточно в целом знать, что важно клиенту, какой функционал и для каких целей ему нужен. Какие решения выбрать – ответственность программиста. И в рамках этой ответственности он должен использовать для данного конкретного проекта наилучшие инженерные практики с экономически оправданными затратами. Поэтому профессионалы, знающие, как сделать процесс разработки дешевле, выигрывают.
Какой тест выгоднее
Одна из практик, позволяющая контролировать качество продукта – это тестирование. Но какой тест выгоднее? Чтобы ответить на этот вопрос, достаточно сравнить несколько параметров. Все тесты можно условно разделить не только по типу технологии, но и по скорости, а главное – по стоимости.Unit-тест – тестирование production юнитов. Под юнитами я понимаю программные единицы, в зависимости от языка представленные классами, функциями, реже файлами. При использовании TDD подхода тестирование изначально вплетено в процесс разработки продукта. На проекте могут использоваться тысячи таких тестов для проверки отдельных частей кода. У них отличный показатель скорости – весь набор тестов можно выполнить за секунды. Это самые дешевые тесты.
Интеграционный тесты – тестирование 2х-3х или больше юнитов вместе. Таких тестов на проекте могут быть сотни или тысячи, в зависимости от программиста. Скорость – секунды или минуты на весь набор тестов. Стоимость выше, чем у юнит-тестов.
Acceptance-тесты имитируют действие пользователя с программой. Требуют подготовки эксплуатационной среды, поэтому они сложные и дорогие. Количество на проекте – обычно делается один тест на бизнес историю. Скорость работы – обычно от десятков минут до нескольких часов на весь набор тестов.
Самое дорогое и сложное – ручное тестирование. Надо нанять человека, обучить его, создать и дать ему карту бизнес-истории, чтобы он по ней тестировал новое ПО. На такое тестирование уходит несколько дней на весь набор тестов.
Любой тип тестов требует подготовки, а также определенного вложения денег. И чтобы получить экономию (а значит, выгоду), надо прежде всего учитывать скорость тестирования и сложность его запуска. Если на проекте нет автоматических тестов, то остается один выход – ручное тестирование, самое дорогое и медленное.
Однако современный подход к разработке ПО – это непрерывный цикл: за неделю создается новый функционал или новая версия и проверяется – автоматически или вручную. То есть продукт меняется часто, и все эти изменения надо держать под контролем, чтобы программист был уверен, что и новый, и старый функционалы работают хорошо. Поэтому ручное тестирование проигрывает сразу по всем показателям.
Что касается разных типов автоматического тестирования, то надо учесть еще три важных аспекта.
Прежде всего, это надежность – насколько тест легко «сломать» (этот показатель у unit-тестов самый лучший).
Затем окружение, которое необходимо для выполнение тестов. Unit-тесты очень просты, они сами создают окружение вокруг тестируемого юнита. Интеграционные тесты нуждаются в сервисе, который должен быть установлен, запущен и т.д. Acceptance-тесты требуют подготовки, так как приложение должно работать в своей среде.
И наконец – покрытие (test coverage). Unit-тесты имеют хорошее покрытие, используются на протяжении всего проекта. Интеграционные тесты обычно используются на определенных частях проекта, то есть покрывают программу не полностью. Покрытие у аcceptance-тестов хуже – это связано со сложностью их написания и запуска, чаще всего они покрывают основные бизнес-кейсы, это 20-40% от общего объема проекта.