Как вы убедили своего менеджера позволить вам пройти тестирование?
Под «использованием» я подразумеваю, что мне разрешено разрабатывать, регистрироваться в системе контроля версий и поддерживать модульные тесты во времени и т. Д.
Типичные возражения управления:
- Заказчик не оплатил юнит-тесты
- Проект не дает времени на юнит-тестирование
- Технический долг? Какой технический долг?
Знаете ли вы другие возражения? Каковы были ваши ответы?
Заранее спасибо!
project-management
management
unit-testing
tdd
louisgab
источник
источник
Ответы:
Я столкнулся с этой проблемой недавно, когда заказчик придерживался нашей методологии, но высшее руководство узнало, что разработчики тратили свое время на тестирование, а не на разработку, и были обеспокоены этим - в конце концов, у них были специалисты по тестированию, которые проводили тестирование! Я писал о том, как я справился с этим здесь:
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. Это хорошо звучит в теории, но модульные тесты могут и сделать изменения в течение долгого времени. По мере изменения требований добавляются новые функции, поэтому необходимо обновить модульные тесты. Если вы работаете в команде, ваши юнит-тесты устаревают, так как другие добавляют функции / исправления.
Я обращаюсь к конкретным пунктам, которые вы упомянули, а не подниму новые, потому что там есть свобода действий, чтобы добиться прогресса или понять, почему это взводится.
источник
Для каждого клиента, сталкивающегося с производственными проблемами,
Напишите модульный тест и отправьте электронное письмо менеджеру, в котором говорится, что вы добавили модульный тест, чтобы охватить сценарий.
И скажите ему, что эта проблема больше не возникнет в производстве, потому что наш модульный тест выполняется ночью, и мы узнаем, прежде чем код поступит в производство, наблюдая за неудачей этого модульного теста.
Скажите ему, что если бы у нас уже был этот модульный тест до того, как код был запущен в производство, такой производственной проблемы никогда бы не было.
Делайте это последовательно и настойчиво, и вскоре он будет убежден. Менеджерам не нравится, когда клиент сталкивается с производственными проблемами, и он согласится на идею модульного тестирования. Удачи.
источник