Для разработчика бесконечное количество статей о ценности написания автоматических тестов (эта от Эрика Эллиота - одна из моих любимых). TDD - один из наиболее распространенных терминов, используемых в описаниях должностей и на собеседованиях. Как разработчик, мне нравится уверенность в том, что я написал приличный набор тестов. Я не всегда так себя чувствовал, и эти статьи очень помогли мне завоевать расположение; Я разработчик, для которого они были написаны.

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

Прежде всего, я хочу, чтобы вы познакомились с моей модельной командой. Деловые расходы - это средняя заработная плата Glassdoor в Лондоне, Великобритания, умноженная на 1,25, чтобы учесть другие расходы (офисные помещения, пенсия, оборудование, льготы и т. Д.).

Дорогое место, правда? В сумме получается 391 250 фунтов стерлингов в год, а заработная плата в Лондоне граничит с консервативной.

Возьмем лучший сценарий. Ричард (разработчик пользовательского интерфейса) тратит 3 часа на разработку функции. Он ошибается. Николь (QA) находит его и тратит 15 минут на расследование и сбор заявки. Затем Ричарду приходится переключить контекст с того, что он делает, чтобы вернуться и исправить это, на что у него уходит 1,5 часа. QA тратит 15 минут на повторное тестирование ошибки

Общая стоимость:

UI (3 часа): 84 фунта стерлингов

Контроль качества (15 минут): 5 фунтов стерлингов

UI (1,5 часа): 42 фунта стерлингов

Контроль качества (15 минут): 5 фунтов стерлингов

Итого (5 часов): 136 фунтов стерлингов

Вероятно, это наиболее частый тип ошибки. Другими словами: если бы разработчик пользовательского интерфейса потратил 1 час на написание теста, который предотвратил ошибку, вы все равно сэкономили бы 24 фунта стерлингов (~ 20%).

Я оценил время написания теста примерно в 30%, основываясь на блестящей статье о TDD Эрика Эллиотта, где он дает начальный диапазон 15–35%. Если вы прочтете статью, он продолжит, говоря, что на самом деле он стал быстрее развиваться на основе TDD. Я придерживаюсь пессимистической точки зрения, чтобы доказать это.

Возьмем другой сценарий. Ошибка попала в продакшн.

Пользователь обнаруживает проблему. Было бы слишком сложно нанести ущерб имиджу бренда, поэтому я опущу это. Команда поддержки тратит 15 минут на то, чтобы узнать о проблеме и внести ошибку в список невыполненных работ. Владелец продукта тратит 5 минут на чтение сообщения об ошибке и расстановку приоритетов в бэклоге. Вся команда тратит 10 минут на то, чтобы изучить ошибку в доработке бэклога, оценить ее и передать разработчику пользовательского интерфейса. Разработчику требуется 2 часа, чтобы исправить это, поскольку это код, с которым они в настоящее время не работают (или, возможно, не написали с первого раза). QA тратит 15 минут на повторное тестирование ошибки.

Пользовательский интерфейс (разработка оригинальной функции) (3 часа): 84 фунта стерлингов

Поддержка (15 минут): 5 фунтов стерлингов

Владелец продукта (5 минут): 3 фунта стерлингов

Вся команда (7 × 10 минут): 34,50 фунтов стерлингов

UI (2 часа): 56 фунтов стерлингов

Контроль качества (15 минут): 5 фунтов стерлингов

Итого (6 часов 45 минут): 187,50 фунтов стерлингов

Другими словами, разработчик пользовательского интерфейса мог бы потратить 1 час на написание тестов, и вы бы сэкономили 75,50 фунтов стерлингов (~ 40%). Сколько компаний откусили бы вам руку за возможность сэкономить 40% своих затрат на разработку и улучшить имидж бренда в процессе?

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

Не писать тест - это ссуда - мы не зря называем такие вещи техническим долгом. Сейчас вы сэкономите немного времени, но позже вам придется выплатить его с процентами - примерно 20–40% по этим расчетам. И это тоже сложные проценты. По мере того, как накапливаются слои ошибочного кода, долг растет в геометрической прогрессии. Предполагая, что 20% - в первый год вы тратите 50 000 фунтов стерлингов на разработчика пользовательского интерфейса и 10 000 фунтов стерлингов на выплату процентов по техническому долгу. К десятому году вы будете платить больше за исправление проблем, являющихся результатом технического долга, чем за фактическое выполнение любой новой работы (50 000 фунтов стерлингов для разработчика пользовательского интерфейса и 51 597,80 фунтов стерлингов за исправление ошибок). К сожалению, эта ситуация будет слишком знакома многим разработчикам и компаниям, которым приходилось работать с устаревшим кодом.

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

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

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

А есть еще один аргумент против тестирования.

«Почему разработчики не могут сделать это правильно с первого раза?»

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

Это как дартс. Дартс - единственный вид спорта, в котором параметры игры никогда не меняются. Дартс всегда одного размера, вы можете использовать одни и те же дротики каждый раз, и вы стоите на одинаковом расстоянии от доски для каждого выстрела. И все же - как знает любой, кто пробовал это, - невероятно сложно достичь того, к чему вы стремитесь. Люди не безупречны. Мы всегда будем совершать ошибки, и любой, кто не понимает, попадает в стрессовую жизнь, когда дело касается разработки программного обеспечения (или любого карьерного пути). В этом случае реализм превосходит идеализм.

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

Всего наилучшего,

Ник