Я готовлю презентацию об модульном тестировании для менеджеров. Моя команда уже много лет пишет модульные тесты, но другим областям компании, похоже, трудно ее принять. Я могу заставить разработчиков задуматься об этом, но если у руководства нет бай-ин, он не станет стандартом.
У вас есть предложения, как лучше всего подойти к управлению этим? Какие вещи вы пытались использовать в прошлом? Какие вещи не работают?
Для нетехнических менеджеров я вернулся к аналогии с строительством дома. Будут ли они строить один без чертежей, просто беря кирпичи из кучи и ставя одного поверх другого с неопределенной идеей в форме дома? Если нет, то почему они не будут принимать правильную документацию перед кодированием, обзорами дизайна и т.д.
Для unit test вы можете попробовать сравнить его с качеством тестирования различных компонентов дома отдельно, прежде чем собирать их вместе (кирпичи, цемент, двери, окна, сантехника).
Для тех, у кого есть какие-либо технические возможности, я упоминаю, что от 30% до 50% справляется с условиями ошибки и восстановлением (в критически важных встроенных системах), и вы просто не можете проверить это без модульного тестирования. EG, если вы только тестируете интеграцию с черным ящиком, то как вы можете - контролируемым и повторяемым образом - проверить, что происходит, когда модуль A не может выделить память в данной точке, или тайм-аут истекает глубоко в модуле C, ожидая ответного сообщения откуда-либо, или прочитанной базы данных, которая обычно будет успешной. Объясните, что, вымывая интерфейсные модули, вы можете имитировать свое ошибочное поведение по своему усмотрению.
И, конечно, я рисую свой фавориальный граф с символом $на одной оси и часами на другом. Я побеждал руководство над головой этим при каждой возможности, чтобы показать, что стоимость получения ошибок увеличивается, а позже они обнаруживаются (изменение строки в спецификации потребности - 5 минут, несколько парасов в проектных документах - несколько, несколько строки кода (при просмотре кода или стадии unit test) - дни, поиск иглы в ошибке стопки сена и исправление ее при системных тестах - недели).
Это не просто unit test - вам нужно убедить руководство - и ваших коллег-разработчиков - что "лишние накладные расходы" на документацию, обзоры, тестирование... s/w Процессы вообще (и это включает в себя изучение новых инструментов)... фактически экономит время, а не добавляет время на проект. Другими словами, для этого требуется больше времени и стоит дороже. Мера дважды, вырезать один раз и т.д.
Для unit test расскажите им о непрерывной интеграции. Я настоятельно рекомендую Дженкинса, но использую то, что работает для вас. Объясните, что регулярная сборка, будь то в ночное время или с любой регистрацией, может автоматически вытаскивать модульные тесты из вашего VCS и запускать их, отправлять электронную почту или иным образом предупреждать о новом коде, который нарушил существующие тесты почти сразу, как только это произойдет.
Если это не работает, найдите новое задание (если вы находитесь в Сингапуре или хотите поговорить со мной;)
Покажите им пример того, где тестирование уже поймало проблему и сохранил день.
Не вводите в заблуждение.
При цитировании сокращенных затрат вы подразумеваете, что стоимость QA и более простой рефакторинг больше, чем цена на создание и поддержание тестов. Было бы неплохо указать на это и попытаться ввести некоторые показатели, чтобы укрепить вашу точку.
Проблема заключается в том, что вы не можете поместить значение доллара на выбранный путь ( "Мы избегали 1000 дефектов, которые стоили бы $1 млн для исправления!" ).
Но вы должны быть уверены в том, что есть затраты на создание тестов, и их нужно поддерживать. Если вы их создадите, а затем дайте им упасть в негодность, вы так же плохи.
Ваш аргумент получит толчок при добавлении новых функций, и это проще, потому что вы сохранили код в чистоте.
Я думаю, что статистика сделает наилучший случай для нетехнических менеджеров. Code Complete, 2nd Ed. содержит краткое изложение нескольких исследований, показывающих, что модульное тестирование приводит к средней скорости обнаружения дефектов 30% (таблица 20-2, p 470). Я думаю, что это должно быть легко взять оттуда и сделать так, чтобы меньше ошибок переводилось на большее количество денег.
В некоторых случаях я обнаружил, что ожидание подходящей возможности является ключевым.
Например, в одном случае я ждал, пока не появится горячий сайт с клиентом. Это было очень больно (думаю, $$$). Одним из неотложных вопросов, заданных высшим руководством, было то, как избежать такой же проблемы в будущем. И это, когда я представил модульное тестирование руководству...
Итак, я думаю, это зависит от обстоятельств.
1 - Нужно ли им знать или даже одобрять? Вы инженер, и вы знаете лучше, чем строить, что работает, поэтому им действительно не следует вмешиваться. Будут ли они заботиться о том, какие инструменты и какие методы обеспечения качества/безопасности вы использовали, если это была новая модель автомобиля, которую вы построили для них? Не думал бы так.
2 - Стоимость дефектов очень, очень высокая. Низкое качество, дефекты и технический долг - очень серьезный проектный риск, который может поставить под угрозу все инвестиции в программный проект. Предотвращение дефектов легче экономически выгоднее, чем обнаружение дефектов (много кратных по исследованиям). Модульные тесты имеют самую короткую петлю обратной связи, что позволяет избежать систематического низкого качества проекта и значительно снизить риск проекта.
3 - Вы не можете идти быстро в течение длительного периода времени без очень низкой скорости дефекта - иначе, Инвестирование превосходит расходы/спекуляции (это они должны получить).
Скажите им, что код делает его более удобным и сэкономит деньги в долгосрочной перспективе. Он также уменьшает количество ошибок, если все сделано правильно.
Иными словами, это снижает затраты и повышает надежность программного обеспечения.
Чтобы построить ответ на @hvgotcodes, не просто расскажите им, как это улучшит ситуацию, скомпилируйте некоторые статистические данные из вашей собственной команды о том, как она имеет
В особенности расходы, предприятия любят экономить деньги:)
Тестирование модулей, если все сделано хорошо, предполагается
Есть ли какая-либо соответствующая статистика, собранная в вашей компании, которая может основывать эти претензии конкретно? То есть количество ошибок, обнаруженных QA/пользователями в разных продуктах, или средние затраты на исправление ошибок/функций,...
Если возможно, я попытаюсь представить реальные примеры трудностей, с которыми сталкивалась ваша компания в прошлом, когда поддерживал живой код без тестов. Затем перейдем к тому, чтобы выделить, возможно, конкретные примеры, что сокращение расходов на поддержку обновлений и исправлений было на месте.
Удачи и дайте нам знать, как вы поживаете.:)
Представить это как Поведенческая разработка или Test Driven Development, а не только как модульное тестирование.
Оба BDD и TDD имеют проблемы, которые легко понять нетехническим специалистам. Фактически, одним из их ключевых преимуществ является то, что они сосредоточены на нетехнических.
Модульное тестирование, с другой стороны, является технической концепцией, которая может быть очень абстрактной для не-программиста. Проверьте свой код? Разве вы не делаете это при разработке? Почему мы платим за тестовый персонал? И так далее.
Нарисуйте аналогию с тем, что менеджеры, вероятно, используют на регулярной основе - как средство проверки орфографии в своем почтовом клиенте или редакторе документов....