Как убедить руководство «инвестировать» в модульные тесты?

46

Как вы убедили своего менеджера позволить вам пройти тестирование?

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

Типичные возражения управления:

  1. Заказчик не оплатил юнит-тесты
  2. Проект не дает времени на юнит-тестирование
  3. Технический долг? Какой технический долг?

Знаете ли вы другие возражения? Каковы были ваши ответы?

Заранее спасибо!

louisgab
источник
6
В artofunittesting.com есть целая глава на эту тему.
StuperUser
6
Не смешивайте тесты и TDD, ПОЖАЛУЙСТА ! Это заставляет людей думать, что им не нужны тесты, если они не делают TDD!
П Швед
1
Людей, которые нуждаются в убеждении, невозможно убедить. Считайте, что ваш сценарий потерян
Марк Канлас
@Pavel, сначала я думал, что ты придирчив, но ты прав. Я хочу получить «разрешение» на юнит-тест, точка. TDD это моя собственная вещь.
Луисгаб,
6
почему вы чувствуете необходимость получить разрешение для проверки того, что ваш код работает должным образом?
Яап

Ответы:

25

Я столкнулся с этой проблемой недавно, когда заказчик придерживался нашей методологии, но высшее руководство узнало, что разработчики тратили свое время на тестирование, а не на разработку, и были обеспокоены этим - в конце концов, у них были специалисты по тестированию, которые проводили тестирование! Я писал о том, как я справился с этим здесь:

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

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

Мой вывод, основанный на этом опыте:

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

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

Так что в вашем случае я бы сделал это скрытно, если это необходимо (возможно, есть небольшая область кода, которую вы можете начать тестировать, которая часто изменяет или за которую вы несете ответственность), но следите за своими номерами - что такое усилия для создания ваших тестов? Какова частота дефектов? Как это соотносится с другими проектами / членами команды?

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

Paddyslacker
источник
Спасибо за ответ. Я попробовал ссылку, но она кажется сломанной. Я думаю, что я бы с удовольствием прочитал его, если бы он был доступен.
Джо Дж.
Джо, извини за тупик. Я разместил это в своем личном блоге, поэтому ссылка должна работать.
паддислакер
2
Это хороший ответ, но не все могут легко сравнить то, что они делают, с каким-то другим проектом. Я не могу вспомнить, где я это читал, но самым убедительным аргументом для делового человека, которого я видел, было сравнение модульного тестирования с двойной бухгалтерией. Наивно делать числа дважды - пустая трата времени. Но любой, кто знает что-либо о бухгалтерском учете, подумал бы о том, чтобы сделать только одну сторону книги непростительно безответственным нарушением обязанностей. Модульное тестирование является разработкой аналога двойной бухгалтерии.
JimmyJames
@JimmyJames, я согласен, что вы не всегда можете сравнить с другим проектом, и я согласен с вашей аналогией о двойной бухгалтерии. Я думаю, что если вы начинаете использовать модульные тесты на существующей кодовой базе без тестов, вы можете сравнить частоту дефектов кодовой базы и другие метрики между частью, охваченной модульными тестами, и непокрытым кодом, так что у вас есть реальные данные для резервного копирования твой подход тоже.
Paddyslacker
@Paddyslacker Я не согласен. Это что-то вроде курицы и яйца. Если вам нужно разрешение, чтобы начать писать модульные тесты, их трудно использовать для доказательства того, что разрешение должно быть предоставлено. Это не то или другое. Сравнение с реальными данными - гораздо более сильный аргумент. Этот альтернативный аргумент слабее, но его легче смонтировать.
JimmyJames
20

Показать возврат инвестиций (ROI)

Написание автоматических тестов требует времени. Однажды. Запуск автоматизированных тестов занимает нулевое время, потому что вы можете делать что-то еще, пока они работают.

Пример. Проверка функции X вручную занимает 30 минут. Написание автоматизированного теста для этого заняло бы 1 час. Даже если у нас нет ошибок, нам придется тестировать элемент X десять раз в течение проекта, так как его зависимые слои и компоненты модифицируются. Таким образом, автоматизация теста функции X сэкономит нам 4 часа в течение всего срока реализации проекта.

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

Бизнес понимает экономию времени и денег. Вот как это продать.

Стивен А. Лоу
источник
3
Кроме того, как только приложение развернуто, и кто-то просит изменения, намного легче увидеть, что вы что-то нарушаете своими изменениями.
m4tt1mus
4
@mattimus: абсолютно - автоматизированный набор тестов окупается как аннуитет; это, на самом деле, страховка
Стивен А. Лоу
15

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

Руководство не будет подсчитывать строки кода, но они увидят, что все ваши проверки имеют более высокую скорость прохождения от QA (или клиентов), и они в конечном итоге спросят, почему ... тогда вы можете быть похожи на "BAM! TDD !»

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

Стивен Эверс
источник
4
+1: ты все равно должен проверить. Просто пишите модульные тесты, а не спорьте о том, как тестирование «должно» быть сделано.
S.Lott
1
Просто иметь их локально не очень хорошо в командной среде с базой общего кода, другие люди будут ломать ваши тесты со своими изменениями.
Алб
3
@Alb: Это цена, которую вы платите, когда руководство не попадает на борт - лучше, чем никаких тестов.
Стивен Эверс
3
Браво. Любой тест лучше, чем никакой тест. Если тест прерывается из-за чужого изменения, это хорошая причина спросить, почему API изменился без какого-либо объявления.
S.Lott
«Менеджмент не собирается считать строки кода», это очень верно. Спасибо за ответ!
Луисгаб,
7

1) Заказчик не оплатил юнит-тесты

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

2) Проект не дает времени на TDD

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

3) Технический долг? Какой технический долг?

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

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

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

Ян
источник
5
«Я не рекомендую писать тесты в любом случае» - я был в этой позиции раньше. Трудно поддерживать тесты самостоятельно. Если это бремя становится слишком тяжелым, просто бросьте тесты. По крайней мере, они были у вас, когда вы активно работали в базе кода, что должно помочь с первоначальным дизайном / исправлением, если не улавливает регрессии. Я обнаружил огромное значение в модульных тестах для целей проектирования, но обнаружил довольно мало регрессий, когда тесты не поддерживаются на том же уровне, что и код.
Стив Джексон
1
Кто бы ни добавил функции / исправления и не обновил юнит-тесты, он не понимал концепцию юнит-теста.
Акира Ямамото
На самом деле, Акира, это одна из самых сложных проблем, влияющих на жизнеспособность TDD или связанных процессов. Имейте в виду, я, по-видимому, написал это 7 лет назад, многое еще актуально. Написание (хороших, объективных, лаконичных) тестов сложно. Написание тестов для кодовой базы, у которой их нет, очень сложно. Трудно заставить нетехнический менеджмент увидеть преимущества - это сложно (если только они не прочитают статью об этом, и в этом случае вы будете «метричны» до смерти. Даже концепция того, что такое единица, сложна. Я - классик, так мое представление о юните не совпадает с представлением мокиста (как пример с 30 оставшимися символами).
Ян
4

Для каждого клиента, сталкивающегося с производственными проблемами,

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

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

  3. Скажите ему, что если бы у нас уже был этот модульный тест до того, как код был запущен в производство, такой производственной проблемы никогда бы не было.

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

java_mouse
источник
Это хорошо :-)
Б.В. Венгеров