Хабрахабр

Как доказать важность тестов каждому участнику проекта

Представьте, вы за два дня полностью реализовали новую фичу. Код написан, он работает и все классно. Ваш менеджер говорит, что можно сразу в релиз. «А как же тесты?» — воскликнет какой-нибудь дотошный коллега. «А зачем?» — ответите вы в один голос с менеджером. Зачем нам писать тесты? Как объяснять их необходимость другим? Зачем вовлекать тестировщиков, аналитиков и других участников? В этом посте я расскажу, как объяснить пользу тестов любому участнику проекта, а также зачем стоит тесты автоматизировать. И подкрепим все это серьезными исследованиями.

Начнем рассуждение от обратного.
Нужна ли вам автоматизация?

Почему тесты писать не надо?

1. Это дорого

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

2. Это нудно

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

3. Это бесполезно

Зачем вообще писать тесты, если мой код работает? Каждая его строчка прошла через мой внутренний гений. Как оно вообще может создавать проблемы в приложении? Это исключено, я каждый байтик насквозь вижу.

4. Это «не мои проблемы»

Сегодня я в одной команде фичу написал, завтра пойду в другую команду новую фичу делать. Что здесь дальше будет, разберутся без меня, даже если и найдется какая-то ошибка.

Почему весь этот список — неправда?

Теперь пройдемся по всем пунктам и опровергнем каждый. Заодно приведем еще несколько интересных фактов из исследований известных компаний вроде Microsoft (On the Effectiveness of Unit Test Automation at Microsoft за авторством Laurie Williams, Gunnar Kudrjavets, Nachiappan Nagappan), а также менее известной компании из Южной Америки.

1. В масштабах проекта это недорого

Обратимся к «Совершенному коду» Стива Макконнелла. Если оценить, как со временем изменяются трудозатраты, то можно заметить, что постепенно доля тестирования, выполняемого разработчиками, сокращается с 25% до 8-10%. Больше ресурсов начинают красть другие активности.

Есть другое исследование, где Microsoft изучил примерно 30 внутренних команд разного размера — по 28-35 разработчиков и 14-20 тестировщиков в каждой.

При внедрении практик автоматизированного тестирования время на разработку выросло в среднем на 26%. Это исследование показывает примерно те же цифры. Поэтому рост на четверть только одного из множества процессов — небольшая потеря для бюджета, особенно в свете падения затрат на ручное тестирование. Но разработка — это не вся проектная активность, есть еще конструирование, интеграция, внедрение и так далее.

2. Это гораздо веселее, чем проблемы в продакшене

Возможно, написание тестов несколько скучновато — тестовый код тривиален и редко таит в себе интересные задачи. Но вашему клиенту точно не нужен вечный пожар, который вы будете тушить, находя дефекты во время внедрения или бета-тестирования.

3. Это полезно для всех

Чем меньше веришь в эталонность своего кода, тем в итоге будет лучше как команде, так и продукту. А в первую очередь вам самим — научитесь на своих ошибках и при этом без неприятных последствий.

4. Это станет вашей проблемой

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

Тестирование с точки зрения ролей в команде

Переходим в наступление. Посмотрим на тесты глазами всех участников процесса разработки: клиента, владельца продукта, тестировщика и разработчика.

Клиент

Что бывает, когда не пишут тесты? Например, ты теряешь спутник, который застрахован на 2,6 млрд рублей.

1б» запустил спутник «Метеор-М» № 2-1. 28 ноября Роскосмос с помощью ракеты «Союз-2. Разработчики ПО, которое отвечало за корректировку маршрута, забыли указать актуальные данные. Он не долетел — немного отклонился от курса и упал в океан. Один маленький тест для проверки входных данных — и 2,6 млрд рублей были бы спасены. Планировалось, что спутник будет выводиться на орбиту с космодрома «Байконур», а запуск состоялся в нескольких десятках тысяч километров от него —  с космодрома «Восточный».

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

С ним можно смело делать то, что никто не делал до тебя. С другой стороны, что бывает, если код продукта полностью закрывается тестами? И это очень классно.

Владелец продукта

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

Мы не должны делать хуже пользовательскому опыту. Это значит, что продукт, который развивается несколько лет (или даже несколько десятков лет), постоянно обеспечивает какой-то минимальный уровень качества, и количество дефектов в нем не превышает некоторого максимума. Это можно гарантировать с помощью тестов, ручных и автоматизированных. Мы не должны существенно ухудшать качество наших фич.

В рамках команды из 32 разработчиков количество дефектов, которое доходило до пользователя, уменьшилось на 20,9% — после того, как во второй версии продукта команды разработки стали применять автоматизацию тестирования и писать модульные тесты. В другом исследовании Microsoft можно подсмотреть еще одну интересную цифру. Да и сами тестировщики стали замечать, что качество их ПО стало выше — стало интереснее работать. При этом вторая версия обзавелась дополнительными фичами, выросла по объему кода примерно на 20% и еще на 20% была переписана.

Автотесты, если их регулярно запускать, помогают вовремя сигнализировать о том, что есть какие-то проблемы. В IBM тоже проводили подобные исследования и в итоге выяснили, что стоимость устранения бага, обнаруженного после релиза, выше в 4-5 раз чем при обнаружении во время проектирования или реализации. В итоге стоимость поддержки ПО станет ниже — а качество пользовательского опыта при этом вырастет. Они помогают резать эти дополнительные косты в бюджете.

Тестировщик

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

Вот отчет по ошибкам в рамках одного внутреннего проекта Microsoft:

Ошибки разделены на четыре категории. Первая версия — до внедрения автоматического тестирования, вторая — после. Суммарно во второй версии количество багов уменьшилось на 21%. Чем выше категория, тем сложнее ошибки. Доля более сложных багов осталась такой же либо чуть-чуть подросла из-за того, что общее количество багов снизилось. Количество багов из простых категорий (3 и 4) уменьшилось существенно.

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

Есть известная многим пирамида, которая делит различные виды тестирования по слоям. Почему до тестировщиков стало доходить меньше багов? А сложных end-to-end или ручных тестов должно быть минимальное количество, но при этом они должны искать самые сложные баги — это так называемые мигающие, плавающие или серые тесты. Эта пирамида говорит о том, что самых примитивных модульных тестов, которые затрагивают исключительно маленькую часть ПО, должно быть в проекте больше всего. Если эту пирамиду перевернуть, появляется так называемая воронка тестирования, в которую сыплются всевозможные баги.


Источник: https://twitter.com/noahsussman

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

Разработчик

Для разработчика я выделил целых пять преимуществ, которые ему дают тесты:

  • Понимание требований

При написании теста разработчик начинает лучше понимать требования, благодаря коммуникации с нетехническими специалистами. Допустим, нужно реализовать какое-то поле ввода. Когда вы пишите тесты к своему коду, то начинаете задавать вопросы: а что если я сюда подставлю пустое значение? А что если я введу 150 символов вместо 10 разрешенных? Уточняя эти моменты, вы делаете более стабильным свой код и избавляете его от самых простых ошибок.

  • Стабильность при рефакторинге

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

  • Формирование документации

Тесты служат отличной документацией к вашему коду. Гораздо легче понять чужой код, когда есть какой-то потребитель этого кода. И самым первым потребителем как раз выступают тесты. Не заходите в Jira, не изучайте объемные комментарии в Confluence — вы можете просто открыть тестовый класс, набор каких-то тестовых методов к вашему коду, и понять, что этот код делает, просто почитав названия тестовых методов и поняв, какие данные там передаются.

  • Улучшение API

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

  • Уменьшение количества ошибок

Понятно, что тесты уменьшают число ошибок в коде. Меньше ошибок — больше свободного времени. Вот что сами разработчики говорят про написание тестов (в данном случае модульных) в исследовании Microsoft:

Подведем итоги

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

В зависимости от сложности языка программирования, фичей и опыта программиста, эта доля может уменьшиться до 8% или подскочить до 40-50% времени. Конечно, с тестами разработка становится дольше — в среднем на 26%. Если время выхода на рынок для вас максимально критично — отложите написание тестов, выпустите MVP и возвращайтесь к тестам потом.

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

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

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»