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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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