Как убедить спонсора проекта в том, что все функции в вашем коде должны иметь модульные тесты [закрыто]

Question

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

Answer 1

Лучший способ - не быть таким техничным с "нетехническими" людьми.Просто встраивайте это в сроки доставки, не вдаваясь в детали.

С другой стороны, похоже, что сроки реализации проекта были нереалистичными для его реального создания.

Answer 2

Я просто подробно написал как раз на эту тему.

Подводя итог моим аргументам против распространенных жалоб:

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

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

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

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

Answer 3

Попробуйте использовать аналог.Спросите их, хотели бы они, чтобы их дети ездили на "Вольво" или "Кит-карах", сделанных каким-нибудь парнем на соседней улице.Ответом всегда должен быть Volvo.Тогда спросите, почему?Ответ заключается в том, что это более надежно и безопасно.Откуда они знают.Ответ - это тестирование.Все автомобили проходят экстремальные испытания, и стоимость отражает это.Если они хотят, чтобы программное обеспечение было как можно более надежным, им нужны тесты.(Или они становятся манекенами для краш-тестов)

Answer 4

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

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

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

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

Answer 5

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

Answer 6

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

Answer 7

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

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

Answer 8

@Craig, я тоже думал об аналоге автомобиля, но я думаю, что аналогия разваливается, поскольку звучит так, будто в проекте уже есть тестирование, и это просто вопрос степени.В этом случае аналогия с автомобилем становится "Вас волнует, проверяется ли плафон в автомобиле до тех пор, пока тестируются критические системы (тормоза, фары, трансмиссия и т.д.)".Как измученному спонсору проекта, который видит, что срок окончания проекта истекает, мне на самом деле все равно, будет ли протестирован плафон или нет.

Answer 9

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

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