Представьте, вы полностью реализовали новую функцию за два дня.
Код написан, работает и все отлично.
Ваш менеджер говорит, что вы можете сразу приступить к выпуску.
— А как насчет тестов? - воскликнет какой-нибудь дотошный коллега.
"Зачем?" - ответите вы в один голос с менеджером.
Зачем нам нужно писать тесты? Как объяснить их необходимость другим? Зачем привлекать тестировщиков, аналитиков и других участников? В этом посте я расскажу, как объяснить преимущества тестов любому участнику проекта, а также почему стоит автоматизировать тесты.
И мы подкрепим все это серьезными исследованиями.
Вам нужна автоматизация? Начнем рассуждение с противоположного.
Почему не нужно писать тесты?
1. Это дорого
Программист — один из самых дорогих участников проекта, и его работа сильно влияет на бюджет. И вообще, писать тесты – это не магистерское дело.Можно просто за копейки нанять студентов и позволить им написать эти тесты и тестовые программы.
Пусть тыкают в дисплеи, нажимают клавиши - все будет хорошо.
2. Это скучно
Разработка автоматизированных тестов — очень утомительная работа.Это можно доверить кому угодно.
Я изучал программирование 5 лет в университете и еще два года в аспирантуре.
Я хочу создавать крутую архитектуру, применять крутые шаблоны и запускать ракеты на Марс.
А тесты — это не задача моего уровня.
3. Это бесполезно
Зачем вообще писать тесты, если мой код работает? Каждая строчка прошла через мой внутренний гений.Как это вообще может создать проблемы в приложении? Это невозможно, я вижу все насквозь.
4. Это «не моя проблема»
Сегодня я написал фичу в одной команде, завтра пойду в другую команду создавать новую фичу.Что будет дальше здесь разберутся без меня, даже если будет обнаружена какая-то ошибка.
Почему весь этот список не соответствует действительности?
Теперь пройдемся по всем пунктам и опровергнем каждый.Заодно вот еще несколько интересных фактов из исследований таких известных компаний, как Microsoft ( Об эффективности автоматизации модульного тестирования в Microsoft Лори Уильямс, Гуннар Кудрявец, Начиаппан Нагаппан), а также менее известная компания из Южной Америки.
1. В масштабах проекта это недорого.
Давайте посмотрим на Code Perfect Стива МакКоннелла.
Если оценить, как меняются трудозатраты с течением времени, то можно заметить, что постепенно доля тестирования, выполняемого разработчиками, снижается с 25% до 8-10%.
Другие виды деятельности начинают воровать больше ресурсов.
Есть еще одно исследование, где Microsoft изучила около 30 внутренних команд разного размера — по 28-35 разработчиков и 14-20 тестировщиков в каждой.
Это исследование показывает примерно те же цифры.
При внедрении практик автоматизированного тестирования время разработки увеличилось в среднем на 26%.
Но развитие – это не только проектная деятельность; есть еще проектирование, интеграция, реализация и так далее.
Поэтому увеличение на четверть всего лишь одного из многих процессов — небольшая потеря для бюджета, особенно в свете падения затрат на ручное тестирование.
2. Это гораздо веселее, чем производственные проблемы.
Возможно, написание тестов немного скучно — код тестов тривиален и редко содержит интересные задачи.
Но вашему клиенту точно не нужен вечный огонь, который вы будете тушить, обнаружив дефекты во время внедрения или бета-тестирования.
3. Это хорошо для всех
Чем меньше вы верите в стандарты своего кода, тем лучше будет как для команды, так и для продукта.И в первую очередь вы сами – учитесь на своих ошибках и без неприятных последствий.
4. Это станет вашей проблемой.
Если вы напишете код, а потом откажетесь от его поддержки, то через месяц-два вы запросто можете пропустить релиз.
В рамках общего тестирования продукта будет обнаружено множество дефектов — в результате как ваша фича, так и несколько других фич ваших коллег не дойдут до производства.
Тестирование с точки зрения командных ролей
Пойдем в наступление.Давайте посмотрим на тесты глазами всех участников процесса разработки: клиента, владельца продукта, тестировщика и разработчика.
Клиент
Что происходит, когда тесты не пишутся? Например, вы теряете спутник, который застрахован на 2,6 миллиарда рублей.
28 ноября Роскосмос запустил спутник № 2-1 «Метеор-М» с помощью ракеты «Союз-2.1б».
Не успел — слегка отклонился от курса и упал в океан.
Разработчики программного обеспечения, отвечавшего за корректировку маршрута, забыли предоставить актуальную информацию.
Планировалось, что спутник будет выведен на орбиту с космодрома Байконур, а запуск произойдет в нескольких десятках тысяч километров от него - с космодрома Восточный.
Одна небольшая проверка входных данных — и было бы сэкономлено 2,6 млрд руб.
В Интернете можно найти множество историй о том, как одна маленькая ошибка в программном обеспечении может привести к затратам в миллиарды долларов.
Большинство из них связаны с медициной и космосом, и есть много примеров в банковской сфере.
Например, в 2012 году сеть одного крупного западного банка выкатила на все серверы одно и то же обновление.
После этого серверы со старым кодом начали генерировать дополнительные отчеты, поскольку на проактивном фронте исчезли необходимые блокировки.
В результате 440 миллионов долларов отчетности были потрачены впустую.
С другой стороны, что произойдет, если код продукта полностью покрыт тестами? С его помощью вы сможете смело делать то, что до вас еще никто не делал.
И это очень здорово.
Владелец продукта
Важной характеристикой продукта с будущим является возможность его расширения и долгосрочной поддержки.По-английски это называется красивым словом Ремонтопригодность .
Это означает, что продукт, разрабатываемый в течение нескольких лет (или даже нескольких десятилетий), постоянно обеспечивает определенный минимальный уровень качества, а количество дефектов в нем не превышает определенного максимума.
Мы не должны ухудшать пользовательский опыт. Мы не должны значительно ухудшать качество наших функций.
Это можно гарантировать с помощью тестов, как ручных, так и автоматизированных.
Еще одну интересную цифру можно увидеть в другом исследовании Microsoft. В команде из 32 разработчиков количество дефектов, доходящих до пользователя, сократилось на 20,9% — после того, как команды разработчиков начали использовать автоматизацию тестирования и писать модульные тесты во второй версии продукта.
При этом вторая версия приобрела дополнительные возможности, увеличила объём кода примерно на 20% и была переписана ещё на 20%.
Да и сами тестировщики стали замечать, что качество их ПО стало выше — работать стало интереснее.
IBM также провела аналогичные исследования и в итоге выяснила, что стоимость исправления ошибки, обнаруженной после релиза, выше в 4-5 раз чем когда они были обнаружены во время проектирования или реализации.
Автотесты, если их проводить регулярно, помогают вовремя сигнализировать о наличии каких-то проблем.
Они помогают сократить дополнительные расходы в бюджете.
В результате стоимость поддержки программного обеспечения будет ниже, а качество пользовательского опыта повысится.
Тестер
Здесь вопрос немного в другом: зачем нужна автоматизация тестирования? Исследования Microsoft снова приходят на помощь.По его словам, после автоматизации тестирования тестировщикам стало гораздо сложнее находить ошибки.
Но при том же количестве затраченного времени они теперь находят гораздо более сложные ошибки, которые раньше с большей вероятностью попадали в продакшн.
При этом тривиальных ошибок гораздо меньше, так как они устраняются раньше тестировщиков.
Вот отчет об ошибке из одного внутреннего проекта Microsoft: 
Первая версия — до введения автоматического тестирования, вторая — после.
Ошибки делятся на четыре категории.
Чем выше категория, тем сложнее ошибки.
Всего во второй версии количество ошибок уменьшилось на 21%.
Количество ошибок из простых категорий (3 и 4) значительно уменьшилось.
Доля более сложных ошибок осталась прежней или незначительно увеличилась за счет того, что общее количество ошибок уменьшилось.
Теперь тестировщики могут писать более сложные тестовые сценарии, максимально приближенные к пользовательскому опыту.
Простейшие ошибки программист, скорее всего, устранит сам, если будет систематически дополнять свой код каким-нибудь тестовым кодом.
Почему тестировщикам сообщается о меньшем количестве ошибок? Существует известная пирамида, которая делит разные виды тестирования на слои.
Эта пирамида предполагает, что самых примитивных юнит-тестов, затрагивающих исключительно небольшую часть ПО, должно быть больше всего в проекте.
Сложных сквозных или ручных тестов должно быть минимальное количество, но при этом они должны искать наиболее сложные ошибки — это так называемые мигающие, плавающие или серые тесты.
Если эту пирамиду перевернуть, возникает так называемая воронка тестирования, в которую сыплются всевозможные баги.
Источник: https://x.com/noahsussman
На каждом уровне воронки отфильтровываются ошибки.
Чем сложнее и интереснее ошибка, тем ниже она опускается в этой воронке.
Большое количество модульных тестов позволяет устранить большинство ошибок еще до этапа ручного тестирования.
Таким образом, время на само ручное тестирование сокращается, и до пользователя могут проникнуть только ошибки, связанные с каким-то конкретным функционалом.
90-95% никогда в жизни с ними не столкнутся.
Разработчик
Для разработчика я выделил пять преимуществ, которые ему дают тесты:- Понимание требований
Допустим, вам нужно реализовать какое-то поле ввода.
Когда вы пишете тесты для своего кода, вы начинаете задавать вопросы: а что, если я подставлю сюда пустое значение? Что если я введу 150 символов вместо разрешенных 10? Уточняя эти моменты, вы делаете свой код более стабильным и устраняете простейшие ошибки.
- Стабильность во время рефакторинга
Предположим, у вас есть какой-то старый модуль — огромный легаси-код, который многие боятся трогать, потому что непонятно, что там происходит. Если мы закроем это дело тестами, они качественно проверят, что основные кейсы у нас работают. Будет не так страшно зайти и отрефакторить все это под капотом, изменить под какие-то свои новые реализации.
Мы просто подтвердим, что изменения, появившиеся в нашем приложении, ничего не нарушили.
- Формирование документации
Гораздо проще понять чужой код, когда есть какой-то потребитель этого кода.
И самый первый потребитель – это тесты.
Не заходите в Jira, не изучайте объемные комментарии в Confluence — вы можете просто открыть тестовый класс, набор каких-то тестовых методов для вашего кода и понять, что этот код делает, просто прочитав названия тестовых методов и понимание того, какие данные туда передаются.
- Улучшение API
Мы начинаем думать о том, какие данные мы запихнем в эту сущность, какие данные она нам вернет. Это позволит вам сразу написать качественный интерфейс вместо того, чтобы потом постоянно добавлять новые контексты и параметры.
- Уменьшение ошибок
Меньше ошибок – больше свободного времени.
Вот что говорят о написании тестов (в данном случае модульных) сами разработчики в исследовании Microsoft: 
Давайте подведем итоги
Написание тестов должно быть поддержано руководством.Если вы сами решите, что будете писать тесты, а другие их не пишут, то инициатива, скорее всего, заглохнет через пару месяцев.
Руководство должно поддерживать написание тестов и понимать, зачем они вообще появляются в проекте.
Конечно, с тестами разработка занимает больше времени — в среднем на 26%.
В зависимости от сложности языка программирования, особенностей и опыта программиста эта доля может уменьшаться до 8% или подскакивать до 40-50% времени.
Если время выхода на рынок для вас крайне критично, отложите написание тестов, выпустите MVP и вернитесь к тестам позже.
На мой взгляд, писать тесты внутри команды должны не только разработчики, но и тестировщики.
Все члены команды должны иметь доступ к коду, и все они должны иметь возможность влиять на изменения кода.
Тестировщики могут придумать больше исключений и разнообразных крайних случаев, чем средний разработчик.
Соответственно, улучшится качество и охват тестирования.
Надеюсь, все приведенные выше аргументы помогут вам объяснить внутри ваших команд, а заодно и себе, зачем нужны тесты, почему их следует писать каждый день и как они делают код лучше.
Теги: #тестирование ИТ-систем #автоматизация тестирования #автоматическое тестирование #юнит-тестирование #автотестирование
-
Прямая Линия С Тм. V2.0
19 Oct, 24 -
Управление Умным Домом С Телефона – Мой Опыт
19 Oct, 24 -
Блокировка — Это Хорошо И Не Очень
19 Oct, 24
