Автор: Штефан Дирнштофер (Stefan Dirnstorfer)
Оригинал статьи
Перевод: Ольга Алифанова

Для сокращения усилий тестирования или полного прекращения тестирования какой-то области может быть множество причин.

Тестирование – неотъемлемая часть разработки ПО. После первичных испытаний в ходе разработки флаг переходит к структурированному, зачастую автоматизированному процессу. Регулярный прогон тестов для проверки соответствия требований позволяет поддерживать непрерывное качество функциональности.

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

1. Код не менялся

Если оно работает, и его никто не трогал – зачем это тестировать? Исследования показали, что любое изменение с шансами внесет баги, и зрелость кода можно считать индикатором его качества. Исследования по безопасности выявили, что подавляющее большинство уязвимостей живет в новом или недавно измененном коде. Баги в основном рождаются из-за незапланированных побочных эффектов, и в итоге каждое изменение – это угроза надежности. Чем больше людей просмотрело код и оставило его в покое, тем выше шанс, что там все в порядке.

Если у вашего ПО проблемы с качеством, возможно, эффективнее притормозить разработку фич, а не плодить новые тесты. В каждом проекте я сталкиваюсь с большим объемом непротестированного кода. Я, скажем, никогда не видел тестов для функций Excel, хотя они играют очень важную роль в бизнес-разведке. В testup.io мы годами гоняем ряд сервисов, не тестируя их регулярно. Один из них собирает статистику использования в SQL, другой перебрасывает токены безопасности между системами. У них есть общие черты – они крошечные, у них четкая задача, и – что самое важное – они редко меняются.

Возможно, код НАДО изменить?

Конечно, нереально построить всю систему на компонентах, которые никогда не меняются – что-то должно развиваться. Железо нуждается в замене. Безопасность требует постоянных обновлений. Интернет развивается, и законы выдвигают новые требования к работе с данными.

Отсутствие изменений – зачастую сигнал, что менять систему небезопасно. К примеру, иногда системе нужно измениться, но необходимый рефакторинг откладывается и откладывается из-за страха перед регрессиями.

Хорошо протестированная система, очевидно, проще подвергается миграциям и обновлениям, чем система, которая вроде бы неплохо работает на проде, но протестирована плохо.

Действительно ли продукт работает, как должен?

Когда что-то работает чересчур долго, люди с шансами забывают, что там на самом деле под капотом.

• Тестирование белого ящика не только проверяет, что система работает, но и убеждается, что ее внутренняя архитектура соответствует дизайну.
• Тесты проверяют, что внутренние API и модульные структуры работают, как нужно, но также документируют архитектуру и дизайн.
• Хорошие тесты включают не только ожидаемые ответы, но и сценарии использования. В идеале они также объясняют, почему ожидается именно такое поведение, подкрепляя это техническими сведениями. Зачастую это важнее, чем проектная документация.

2. Код быстро меняется

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

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

Плох ли дизайн?

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

Даже самые быстрые проекты должны со временем создавать некие островки стабильности. Постоянные изменения снижают доверие к вашим данным – они могут отражать артефакты из предыдущих итераций.

Когда хранение данных устаканилось и протестировано, сконцентрируйтесь на бизнес-логике. Фронт и графические элементы обычно тестируются в последнюю очередь – стили и тренды быстро меняются, и с ростом числа активных пользователей проблемы тоже будут нарастать.

Действительно ли вы измеряете прогресс?

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

Стремление поддерживать высокий темп может стимулировать креативность, но редко приводит к действительно оптимизированному ПО. Говорят, что в Google не меняют даже оттенок синего без количественного тестирования влияния. Оправданность настолько экстремального подхода спорна, но ясно одно: нужен какой-то способ отслеживать успех. Это могут быть отзывы клиентов, показатели продаж или прямая выручка. Помню трейдера, который запускал фреймворк для анализа больших данных прямо на своём десктопе. Он всегда работал в проде. Он видел влияние алгоритма в течение нескольких минут, и — сюрприз — он всегда работал.

3. Когда функция никому особенно не важна

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

4. Когда тестировать слишком дорого

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

Можно ли снизить стоимость тестирования?

Когда тестировать трудно, возможно, сама конфигурация системы слишком сложна. Если фича трудно тестируется, то как её вообще эффективно разрабатывать? Я видел проекты, где разработчикам приходилось тратить минуты на ручную настройку системы только для того, чтобы увидеть результат маленького изменения — пустая трата времени и вредная привычка. Тестируемая система должна позволять быстро приводить её в любое актуальное состояние. Только тестируемая система будет расширяемой. Если тестирование слишком дорого, не ждите, что запланированные расширения обойдутся дешевле.

Отслеживаете ли вы стоимость регрессий?

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

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

Заключение

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

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

Чтобы решить, когда завершать тестирование, обдумайте риски, связанные с определенными типами тестирования, и то, что может произойти, если тестирование будет недостаточным:

• Тестирование черного ящика. Ваш компонент сложно обновлять, а необходимый рефакторинг постоянно откладывается.
• Тестирование белого ящика. Внутренняя структура отклоняется от исходного дизайна, отсутствует тест-документация.
• Юнит и компонентное тестирование. Регрессионные баги появляются на поздних стадиях тестирования, делая затратным их ручной отлов.
• Фронтэнд-тестирование. Ваш интерфейс часто ломается, и вы теряете клиентов – ваша функциональность недоступна.
• Тестирование производительности. Медленно накапливаются регрессии, и в результате все неожиданно замедляется, а выявить источник проблем невозможно.
• Тестирование безопасности. Вас взломали.

Если вы снизили эти риски, можно смело прекращать тестирование. Есть другие важные задачи, которые ждут исполнения – новые фичи, документация, планирование восстановления, оптимизация производительности. И, конечно, все это тоже нужно будет тестировать.

Обсудить в форуме