Убедительное управление ценностью модульного тестирования
Автор Эрик Дитрих из Блог Typemock
Вот сценарий, который я видел снова и снова в магазинах разработки. Это связано с разными мнениями об относительной ценности модульного тестирования.
У вас есть стабильная и хорошо зарекомендовавшая себя команда, которую возглавляют разработчики с довольно большим стажем работы. Эти люди могут иметь титулы вроде «главный разработчик» или «архитектор», и они знают как программное обеспечение, так и проблемную область внутри и снаружи. С годами они разработали и усовершенствовали свой способ работы, и руководство им доверяет. В конце концов, они делают свою работу.
В том же магазине у вас есть когорта новых разработчиков. У них меньше лет в отрасли и они относительно новички в компании, но у них много энтузиазма. Они приходят с желанием внедрить передовые отраслевые практики и вещи, приобретенные в других магазинах.
«Мы должны настроить автоматическую сборку с помощью Jenkins».
«И мы также должны начать писать модульные тесты».
Тогда возникает предсказуемая динамика. Занятые люди с более длительным сроком службы скептически относятся к шквалу предлагаемых изменений. Новички чувствуют, что группа немного отстала и должна идти в ногу со временем. Обе стороны отстаивают свои дела перед руководством. И обычно руководство полагается на людей, у которых есть долгий срок.
Аргумент скептиков модульного тестирования
Модульное тестирование больше не является открытой дискуссией в мире программного обеспечения. Мнения в отрасли неодинаковы, что отражено в этом вопросе о переполнении стека. В подавляющем большинстве люди согласны с тем, что это хорошая идея. Но это не означает, что это обязательно делают все.
Таким образом, скептики модульного тестирования в группе не возражают против достоинств этой практики. Вместо этого они утверждают, что затраты на усыновление перевешивают выгоды. И руководству, и энтузиастам говорят примерно следующее.
Послушайте, я фанат модульного тестирования в теории, как и все остальные. Но это займет некоторое время, а наш код не настроен для модульного тестирования. К тому же, откровенно говоря, это средство от всех наших проблем переоценивается.
Если мы все-таки внедрим его, нам придется потратить месяцы на его разработку, и это отодвинет наш график выпусков. Так что сейчас это просто не имеет смысла. Нам следует отложить время для дальнейшего расследования.
И это часто решает проблему в глазах руководства.
Понимание того, как думает руководство
Поставьте себя на место руководства в этих организациях. У вас, по общему признанию, несовершенная операция, в которой есть свои проблемы. Вы пропускаете изрядное количество сроков и имеете много производственных ошибок. Но люди, которым вы доверяете, всегда выполняют свою работу в конечном итоге и исправляют возникающие ошибки.
Новые, менее известные товары говорят вам, что дела обстоят хуже, чем кажется. Но не волнуйтесь! У них есть как раз то, что нужно исправить: передовой отраслевой метод, который все говорят, что вы должны принять его.
С другой стороны, более устоявшийся, более известный товар возражает, что этот новый подход на самом деле не так уж хорош и определенно отсрочит наступающие сроки.
Как менеджер, вы теряете тонкости тестирования кода и автоматических тестов. Итак, вы смотрите на это просто с точки зрения риска и вознаграждения. Одна группа обещает вам неизвестную прибыль за неизвестную цену, которую вы должны принять на веру. Другая группа не советует этого и предлагает вам более предсказуемый статус-кво.
Как бы то ни было, это очевидная вещь в пользу скептиков-тестировщиков.
Поэтому, если вы хотите убедить руководство в ценности модульного тестирования и недостатках статус-кво, вам нужно научиться говорить на их языке.
Полезная метафора о ценности модульного тестирования
Пытаясь убедить людей использовать модульное тестирование, многие сторонники ссылаются на широкое распространение среди уважаемых деятелей отрасли. Или говорят о меньшем количестве дефектов, более высоком качестве кода и меньшем техническом долге.
И хотя руководство понимает эти концепции, они на самом деле не чувствуют их глубоко. Если вы хотите такого глубокого эффекта, вы должны говорить о таких вещах, как риск, несвоевременные сроки, перерасход бюджета и неожиданный взрыв планов. Эти вещи действительно привлекают их внимание.
Поэтому, лоббируя ценность модульного тестирования, сосредоточьтесь на часто упускаемом из виду свойстве практики: фиксированной стоимости изменений. С модульными тестами разработчики так же уверены, что изменят код в двенадцатый месяц, как и в первый месяц проекта. Без него с каждым месяцем растет боязнь прикоснуться к определенным частям кодовой базы.
Представьте себе машину. Кодовая база с модульными тестами - это автомобиль, который вы берете для регулярных проверок и технического обслуживания, и у него есть работающий индикатор проверки двигателя. Кодовая база без модульных тестов - это такая, в которой нет предупреждающих индикаторов и которую вы не проверяете.
На раннем этапе приобретения машины вы не замечаете никакой разницы. Но со временем автомобиль, не прошедший тестирование, начинает вас беспокоить. Вы перестаете с ним совершать длительные поездки из-за страха перед тем, что случится. Когда ты в ней, чувствуешь себя параноиком. В конце концов, вы перестаете приносить его куда-либо, кроме продуктового магазина, прежде чем полностью отказываетесь от него. Задолго до того, как его ожидаемый срок службы закончится, вы обмениваете его на новый, который вас не пугает.
Модульные тесты снижают стоимость изменений
Имея эту метафору в заднем кармане, теперь вы можете поговорить с руководством (и скептически настроенными архитекторами) о своей кодовой базе. Ваша кодовая база - это автомобиль с регулярными проверками и сигнальной лампой.
Будет ли это идеально? Нет, конечно нет. У вас всегда будут икать и время от времени возникать проблемы. Но при регулярных осмотрах и своевременном получении отзывов о проблемах вы можете совершать поездки без постоянно нависшего чувства обреченности.
Возможно, наиболее важным преимуществом модульных тестов является чувство уверенности, которое они вселяют в разработчиков, которым необходимо изменить кодовую базу. Они могут безбоязненно изменять код, зная, что сердитый красный тест даст им знать, если они что-нибудь сломали. Это означает, что вы можете ожидать, что аналогичные функции потребуют одинакового времени для реализации на протяжении всего проекта.
Все участники обсуждения могут относиться к противоположной ситуации, когда функции занимают дни, затем недели, а затем месяцы, поскольку проекты затягиваются. Скорее всего, вы даже можете собрать данные об этом из журнала невыполненных работ по вашему проекту. Затем вы можете объяснить, что такая ситуация не является неизбежной.
Модульные тесты сокращают стоимость и время цикла дефектов
Еще раз проведя аналогию с автомобилем, можно говорить об экономии, связанной с ранним обнаружением. Если у вас есть индикатор неисправности, который загорается, когда в вашей шине заканчивается воздух, вы можете решить проблему на заправке с помощью нескольких монет. Вы просто наполняете шину воздухом.
Но если вы не получите такой обратной связи, вы можете не заметить проблемы, пока не поскребете обод вдоль шоссе. Теперь решение проблемы стоит гораздо дороже: цена новой шины и нового обода.
Модульное тестирование имеет тот же эффект. Если вы сделаете изменение, при котором тест станет красным, вы просто исправите ошибку. Без этой системы раннего обнаружения ошибка находится в коде. Может быть вы поймаете это при запуске приложения, но, вероятно, нет. Ответить на это должно QA или даже конечному пользователю. И когда они это сделают, ремонт окажется гораздо более дорогостоящим и запутанным.
Модульные тесты избавят вас от ненужных переписываний и капитального ремонта
Напомним, что, описывая метафору, я говорил о торговле на автомобиле без системы обратной связи. Вы отказываетесь от вещи до того, как истечет срок ее службы.
Используйте это при разговоре с руководством. Магазины, не практикующие модульное тестирование, непропорционально сильно переписывают свое программное обеспечение. Его становится так сложно поддерживать, и разработчики так боятся прикоснуться к нему, что в конце концов вскидывают руки и требуют переписать.
Когда это происходит, это пустая трата времени. Многие организации принимают это как просто стоимость владения программным обеспечением, но это совсем не так. Когда у вас фиксированная стоимость изменений и вы уверены в программном обеспечении, вы можете развивать его, чтобы не отставать от новых структур и технологий. Как и в случае с автомобилем без сигнальной лампы, полное переписывание происходит только в хрупких кодовых базах с глубокими проблемами.
Позитив и экспериментирование
Теперь в вашем распоряжении убедительная метафора и несколько бизнес-аргументов для лоббирования модульного тестирования. Если бы вы были так склонны, вы могли бы погрузиться в более технические детали: модульные тесты продвигают слабосвязанный код, препятствуют использованию позолоты и т. Д. Но я бы не стал этого делать, учитывая аудиторию, о которой мы здесь говорим.
Вместо этого найдите победу для всех сторон. Специалисты с длительным сроком службы могут почувствовать угрозу, а руководство может опасаться значительных временных затрат на получение сомнительной прибыли. Используйте аналогию с автомобилем, чтобы обосновать свою практику в целом, а затем успокаивайте их на оставшейся части вашего шага.
Предложите просто попробовать это в небольшом масштабе, не подвергая риску сроки. Учитывая упомянутые вами преимущества, становится довольно сложно сказать «нет», когда вы предлагаете способ сделать вложения почти нулевым. Это также устраняет некоторые факторы дискомфорта, связанные с новым подходом.
Принесите тесты, поддерживайте их и ждите момента «ага». Этот момент наступит, когда набор тестов впервые спасет скептика от непреднамеренного внесения регрессионного дефекта в кодовую базу. Как только это произойдет, вы начнете получать новообращенных.
Привлечение сотрудников вашей организации к новым методам работы может быть неприятным, но не забывайте сохранять позитивный настрой. Естественный скептицизм руководства проистекает из заблуждения как по поводу риска, так и по поводу вознаграждения за деятельность. Сведите к минимуму риск для них, четко сообщите о награде и продемонстрируйте как можно большую ценность на этом пути. Выполнив все это, им будет действительно сложно сказать «нет».
