Как лучше всего представить поблочное тестирование управлению? [закрытый]
12 ответов
Для нетехнических менеджеров я прибегал к аналогии со строительством дома. Смогли бы они построить один без чертежей, просто взяв кирпичи из кучи и положив один на другой, имея в виду расплывчатую идею дома? Если нет, то почему они не принимают надлежащую документацию перед написанием кода, обзором проекта и т. Д.?
Для модульного тестирования вы можете попробовать сравнить его с проверкой качества различных компонентов дома по отдельности, прежде чем собирать их вместе (кирпичи, цемент, двери, windows, сантехника)
Для тех, кто хоть немного разбирается в технологиях, я упоминаю, что от 30% до 50% обрабатывают ошибки и восстановление (в критически важных встроенных системах) и что вы просто не можете проверить это без модульного тестирования. Например, если вы только тестируете интеграцию с черным ящиком, то как вы можете - контролируемым и повторяемым образом - протестировать, что происходит, когда модуль A не может выделить память в заданной точке или тайм-аут истекает глубоко в модуле C при ожидании ответного сообщения откуда-то, или чтение базы данных, которое обычно завершается успешно. Объясните, что, создавая макеты для сопрягаемых модулей, вы можете произвольно имитировать их ошибочное поведение.
И, конечно же, я рисую свой любимый график с символом $ на одной оси и часами на другой.Я бью руководство этим по голове при каждой возможности, чтобы показать, что стоимость устранения ошибок увеличивается по мере их обнаружения (изменение строки в спецификации требований - 5 минут; несколько параграфов в проектной документации - часы; несколько 100 строк кода (на этапе проверки кода или модульного тестирования) - дни; поиск ошибки в стоге сена и исправление ее при тестировании системы - недели).
Это не просто модульное тестирование - вы должны убедить руководство - и ваших коллег-разработчиков - в том, что это «ненужные накладные расходы» на документацию, обзоры, тестирование ... s / w Процессы в целом (включая изучение новых инструментов). .. фактически экономит время, а не добавляет время проекту. Другими словами, ошибиться нужно дольше и дороже. Дважды отмерьте, один раз отрежьте и т. Д.
Для модульного тестирования расскажите им о непрерывной интеграции . Я настоятельно рекомендую Jenkins, но используйте то, что вам подходит. Объясните, что обычная сборка, будь то ночью или с каждой регистрацией, может автоматически извлекать модульные тесты из вашей VCS и запускать их, отправляя электронное письмо или иным образом предупреждая о новом коде, который нарушает существующие тесты, почти сразу же.
Если ничего из этого не сработает, ищите новую работу (если вы в Сингапуре или хотите быть, поговорите со мной; -)
Покажите им пример того, как тестирование уже выявило проблему и спасло положение.
Я думаю, что статистика будет лучшим примером для нетехнических менеджеров. Код завершен, 2-е изд. содержит сводку нескольких исследований, показывающих, что модульное тестирование приводит в среднем к 30% -ному уровню обнаружения дефектов (таблица 20-2, стр. 470). Я думаю, что будет легко взять это оттуда и доказать, что меньше ошибок приводит к большей экономии денег.
В некоторых случаях я обнаружил, что ключевым моментом является ожидание подходящей возможности.
Например, в одном случае я ждал, пока не появится горячий сайт с покупателем. Это было очень больно (думаю, $$$). Один из неизбежных вопросов, которые задавало высшее руководство, заключался в том, как избежать такой же проблемы в будущем. И тогда я представил руководству модульное тестирование ...
Так что, я думаю, это во многом зависит от обстоятельств.
Если возможно, я бы попытался привести реальные примеры трудностей, с которыми ваша компания сталкивалась в прошлом при поддержке живого кода без тестов. Затем, возможно, на конкретных примерах выделите сокращение затрат на поддержку обновлений и исправлений в случае проведения тестов.
Удачи, дайте нам знать, как у вас дела. :)
Скажите им, что это делает код более удобным в сопровождении и в конечном итоге сэкономит им деньги. Это также уменьшает количество ошибок, если все сделано правильно.
Другими словами, это снижает затраты и увеличивает надежность программного обеспечения.
Представьте его как Разработка через поведение или Разработка через тестирование , а не просто как модульное тестирование.
И BDD, и TDD имеют свои преимущества, которые легко понять неспециалистам. Фактически, одним из их ключевых преимуществ является то, что они сосредотачиваются на нетехнических аспектах.
Модульное тестирование, с другой стороны, представляет собой техническую концепцию, которая может быть очень абстрактной для непрограммиста. Проверить свой код? Разве вы не делаете этого во время разработки? Почему мы платим за тестовый персонал? И так далее.
В развитие ответа @hvgotcodes, не просто расскажите им, как это улучшает ситуацию, соберите статистику от своей команды о том, как это
- Уменьшило оборот
- Уменьшило затраты
- Уменьшило регрессии
- и т.д.
Особенно затраты, компании любят экономить деньги :)
Юнит-тестирование, если оно сделано хорошо, должно
- отлавливать ошибки раньше, тем самым уменьшая количество ошибок, найденных QA или в производстве, а также уменьшая стоимость исправления ошибок
- поддерживать рефакторинг, тем самым сохраняя дизайн чистым и расширяемым, что в долгосрочной перспективе должно сделать поддержку дешевле
Есть ли соответствующая статистика, собранная в вашей компании, которая может конкретно обосновать эти утверждения? Например, количество ошибок, найденных QA / пользователями в различных продуктах, или средняя стоимость исправления ошибок / реализации функций, ...
1 - Им нужно знать или даже одобрять? Вы инженер и лучше их знаете, как создавать вещи, которые работают, поэтому они действительно не должны мешать. Будет ли им интересно, какие инструменты и какие методы обеспечения качества / безопасности вы использовали, если бы вы построили для них новую модель автомобиля? Не мог бы так подумать.
2 - Стоимость дефектов очень и очень высока. Низкое качество, дефекты и техническая задолженность - это очень серьезный риск проекта, который может поставить под угрозу все инвестиции в программный проект. Предотвращение дефектов намного эффективнее с точки зрения затрат, чем обнаружение дефектов (согласно исследованиям, их количество кратно). Модульные тесты имеют максимально короткий цикл обратной связи, что позволяет избежать систематического низкого качества проекта и значительно снижает риски проекта.
3 - Вы не можете работать быстро в течение длительного периода времени без очень низкого уровня дефектов - иначе говоря, инвестирование лучше траты / спекуляции (они должны это получить).
Не вводите в заблуждение.
Когда вы ссылаетесь на снижение затрат, вы подразумеваете, что затраты на QA и облегчение рефакторинга больше, чем затраты на создание и поддержку тестов. Было бы неплохо указать на это и попытаться ввести некоторые метрики, чтобы подкрепить свою точку зрения.
Проблема в том, что вы не можете оценить в долларах не выбранный путь ("Мы избежали 1000 дефектов, исправление которых стоило бы $1M!").
Но вы должны открыто говорить о том, что создание тестов требует затрат, и их необходимо поддерживать. Если вы создадите их, а затем позволите им прийти в негодность, вам будет так же плохо.
Ваши аргументы получат поддержку, когда вы начнете добавлять новые функции, и это будет проще, потому что вы поддерживали код в чистоте".
Проведите аналогию с чем-то, что менеджеры, вероятно, используют регулярно - например, с программой проверки правописания в почтовом клиенте или редакторе документов ....