Технический долг в разработке ПО: как QA помогает управлять стоимостью изменений

Почему технический долг становится проблемой ещё до появления ошибок

О техническом долге обычно начинают говорить тогда, когда продукт становится трудно развивать. Разработка замедляется, сроки всё чаще приходится пересматривать, а даже небольшие изменения неожиданно затрагивают десятки компонентов. В этот момент появляются разговоры о рефакторинге, пересмотре архитектуры или выделении отдельного спринта на устранение накопленных проблем.

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

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

Именно здесь роль QA (Quality Assurance — обеспечение качества) оказывается значительно шире привычного поиска дефектов.

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

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

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

Что такое технический долг в разработке ПО

Технический долг — один из тех терминов, которые инженеры используют почти ежедневно, но далеко не всегда вкладывают в него одинаковый смысл. Для одних это устаревший код, для других — отсутствие автоматизации, для третьих — сложная архитектура или накопившийся backlog (бэклог — список отложенных задач) на рефакторинг.

На практике технический долг значительно шире любого из этих определений.

Это накопленная сложность инженерной системы, которая постепенно увеличивает стоимость её сопровождения и развития. Иными словами, речь идёт не столько о качестве исходного кода, сколько о способности продукта безопасно изменяться без постоянного роста затрат и рисков.

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

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

По данным международного исследования InsighTD, проведённого среди 653 специалистов из шести стран, наиболее заметными последствиями технического долга становятся снижение сопровождаемости системы, задержки поставки изменений и рост объёма повторной работы.

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

Почему технический долг не всегда связан с качеством кода

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

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

В первой системе новая бизнес-функция реализуется за несколько дней и затрагивает один сервис.

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

Разница заключается не в отдельных классах или функциях, а в свойствах инженерной системы.

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

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

С этого момента начинает меняться и роль QA. Вместо поиска отдельных дефектов тестирование становится инструментом наблюдения за инженерной системой, позволяющим увидеть, когда её сложность начинает влиять на скорость и стоимость разработки.

Какие виды технического долга существуют

Систематический обзор 94 исследований показывает, что технический долг не ограничивается дефектами исходного кода: он может накапливаться в архитектуре, тестах, документации, инфраструктуре и других элементах инженерной системы.

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

Архитектурный технический долг

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

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

К основным признакам архитектурного долга относятся:

• высокая связанность сервисов;

• сложные и плохо прослеживаемые зависимости;

• большое количество интеграций;

• невозможность локально изменить функциональность без масштабной регрессии;

• постоянный рост стоимости изменений.

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

Кодовый технический долг

Кодовый долг связан с локальными инженерными решениями внутри отдельных компонентов системы.

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

В отличие от архитектурного долга такие проблемы обычно легче локализовать и постепенно устранять с помощью рефакторинга. Однако в крупных системах кодовый долг редко существует изолированно: зачастую он становится следствием более глубоких ограничений архитектуры.

Тестовый долг

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

Его признаками могут быть:

• нестабильные flaky-тесты;

• дублирование сценариев;

• высокая стоимость поддержки автоматизации;

• сложная подготовка тестовых данных;

• необходимость постоянно переписывать тесты после небольших изменений продукта.

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

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

Инфраструктурный технический долг

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

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

Документационный долг

Документационный долг возникает тогда, когда знания о системе перестают быть доступными и актуальными.

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

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

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

Таблица 1. Виды технического долга и их признаки

Как QA помогает выявлять технический долг

Распространённое представление о роли QA сводится к поиску дефектов до выхода продукта в промышленную эксплуатацию. Эта задача остаётся важной, однако в зрелых инженерных командах тестирование выполняет и другую функцию: показывает, как меняется сама система.

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

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

Задача QA при этом не заключается в исправлении архитектуры. Тестирование не может уменьшить связанность сервисов или восстановить модульность системы. Оно показывает, где накопленная сложность уже начала влиять на разработку.

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

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

Схема. Как архитектурная сложность превращается в измеримые инженерные метрики

Архитектурная сложность

↓

Рост стоимости изменений

↓

QA фиксирует сигналы

↓

Regression Cost

Flaky Test Rate

Test Maintainability

Change Failure Rate

↓

Инженерные решения

Какие метрики помогают измерить технический долг

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

Команда всегда наблюдает косвенные последствия накопленной сложности. Поэтому наиболее полезным становится анализ нескольких характеристик одновременно.

Regression Cost (стоимость регрессионного тестирования)

Regression Cost — стоимость регрессионного тестирования.

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

Regression Cost мы считаем одной из самых недооценённых инженерных метрик. Если стоимость регрессии растёт быстрее функциональности продукта, это может указывать на увеличение количества зависимостей и снижение способности системы к локальным изменениям.

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

Flaky Test Rate (доля нестабильных тестов)

Flaky Test Rate показывает долю нестабильных тестов, которые при одинаковых условиях могут завершаться с разным результатом.

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

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

Test Maintainability (сопровождаемость тестовой системы)

Test Maintainability характеризует сопровождаемость тестового набора.

Если изменение одного API требует обновления десятков Page Object, фикстур, моков и сценариев, тестовая система постепенно начинает повторять сложность продукта.

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

Change Failure Rate

Change Failure Rate — одна из метрик DORA, показывающая долю изменений, которые приводят к сбоям, инцидентам или необходимости исправлений после поставки.

Рост этого показателя может свидетельствовать о снижении предсказуемости релизного процесса и о том, что система хуже переносит изменения.

Сам по себе Change Failure Rate не измеряет технический долг, однако в сочетании с ростом стоимости регрессии и ухудшением сопровождаемости тестов помогает увидеть более общую тенденцию.

Покрытие кода тестами

Покрытие кода остаётся полезной инженерной метрикой, но практически ничего не говорит о техническом долге само по себе.

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

Поэтому оценивать технический долг только по покрытию некорректно.

Наиболее информативной становится совместная динамика показателей. Если одновременно растут Regression Cost, Flaky Test Rate, Change Failure Rate и стоимость сопровождения автоматизации, команда, скорее всего, сталкивается уже не с локальной проблемой тестирования, а с системным накоплением инженерной сложности.

Таблица 2. Метрики, которые помогают выявлять технический долг

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

Как уменьшить технический долг в разработке ПО

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

Поэтому эффективная работа с техническим долгом начинается не с переписывания кода, а с понимания того, какие изменения становятся наиболее дорогими и почему.

Начинать с архитектурных ограничений

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

Если реализация новой функции требует изменений сразу в нескольких сервисах, пересмотра интеграций и масштабной регрессии, причина обычно заключается не в качестве конкретного класса, а в архитектуре системы.

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

Делать стоимость изменений измеримой

Большинство команд умеет оценивать трудоёмкость разработки новой функциональности.Гораздо реже оценивается стоимость её безопасной поставки.

Сколько времени занимает анализ влияния изменений? Насколько вырос объём обязательной регрессии? Требуются ли новые тестовые данные, дополнительные интеграционные проверки или ручные сценарии?

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

Управлять тестовым долгом так же, как архитектурным

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

Игнорирование тестового долга постепенно снижает ценность автоматизации и увеличивает стоимость каждого следующего релиза.

Использовать метрики как систему раннего предупреждения

1. Инженерные метрики редко бывают полезны по-отдельности.

2. Высокое покрытие тестами не гарантирует качественную архитектуру.

3. Небольшое количество дефектов ещё не означает низкий технический долг.

4. Даже стабильная регрессия не всегда говорит о простоте сопровождения.

Совсем иначе выглядит ситуация, когда несколько показателей начинают изменяться одновременно. Рост Regression Cost, Flaky Test Rate, Change Failure Rate и стоимости сопровождения автоматизации обычно свидетельствует о том, что инженерная сложность уже начинает влиять на процесс разработки.

Важно не абсолютное значение каждой метрики, а их совместная динамика.

Не пытаться погасить весь технический долг сразу

Одна из самых распространённых ошибок — попытка полностью устранить накопленный технический долг отдельным проектом.

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

Гораздо эффективнее устранять наиболее дорогие участки системы постепенно, совмещая эту работу с развитием продукта. Такой подход позволяет снижать стоимость изменений без остановки разработки и не превращает технический долг в бесконечный внутренний проект.

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

Как встроить контроль технического долга в SDLC

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

Оценивать не только разработку, но и проверку изменений

Во время планирования новой функциональности полезно обсуждать не только объём разработки, но и стоимость проверки изменений.

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

Такой подход помогает заметить накопление технического долга значительно раньше, чем он станет очевиден по срокам разработки.

Регулярно анализировать тестовую систему

Автоматизация тестирования требует такого же внимания, как и основной код.

Полезно регулярно отслеживать:

• Regression Cost;

• Flaky Test Rate;

• Test Maintainability;

• количество quarantined-тестов;

• длительность полного regression suite;

• объём обязательных ручных проверок.

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

Анализировать последствия изменений

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

Например:

• увеличилось ли количество зависимостей между сервисами;

• вырос ли объём обязательной регрессии;

• стало ли сложнее локализовать влияние изменений;

• появились ли дополнительные ручные проверки;

• усложнилась ли подготовка тестовых данных.

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

Использовать метрики для принятия решений

Инженерные метрики должны помогать принимать решения, а не становиться KPI.

Рост Regression Cost — повод пересмотреть архитектуру изменений.

Рост Flaky Test Rate — проверить стабильность окружений и взаимодействие компонентов.

Рост Change Failure Rate — разобраться, почему релизы становятся менее предсказуемыми.

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

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

Почему технический долг должен стать управляемым

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

Сначала это проявляется в более осторожных оценках задач. Затем увеличивается объём регрессионного тестирования, усложняется анализ зависимостей и растёт стоимость сопровождения. Со временем архитектурные ограничения становятся заметны уже не только инженерам, но и бизнесу: выпуск новых функций требует всё больше ресурсов, а скорость развития продукта постепенно снижается.

Именно в этот момент технический долг перестаёт быть внутренней инженерной проблемой.

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

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

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