Интервью с Денисом Кульчавым: как выстроить архитектуру тестирования

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

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

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

Что на самом деле значит «архитектура тестирования»

Денис, что ты называешь архитектурой тестирования? Где заканчивается просто организация тестов и начинается архитектура?

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

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

Архитектура начинается тогда, когда мы смотрим на продукт целиком. Какие части системы для бизнеса критичны? Где ошибка будет стоить особенно дорого? Что имеет смысл проверять на уровне отдельных компонентов, что — через API (программный интерфейс приложения), а что обязательно нужно пройти через пользовательский интерфейс? Какие проверки должны выполняться за несколько минут, а какие можно оставить для полного регресса?

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

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

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

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

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

Можно ли уже на старте понять, что архитектура тестирования построена плохо? Какие признаки ты замечаешь первым?

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

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

Другой признак — любое изменение продукта приводит к непропорционально большому объему работы с тестами. Разработчики поменяли один элемент интерфейса, а команда несколько дней исправляет десятки или сотни сценариев. Значит, проверки слишком сильно зависят от деталей реализации.

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

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

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

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

Где архитектура встречается с качеством

Как архитектура тестирования влияет на качество самого продукта? Можешь объяснить эту связь на простом примере?

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

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

Бывает ситуация: автотестов много, покрытие хорошее, отчеты зеленые, а уверенности в качестве у команды все равно нет. Почему так происходит?

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

Какие ошибки в архитектуре приводят к тому, что критические дефекты обнаруживаются слишком поздно?

— Я бы выделил несколько типичных ошибок:

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

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

• У всех тестов одинаковый приоритет. Платежный сценарий и редко используемая функция не должны иметь одинаковый вес при планировании проверок.

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

Решения, которые дорого обходятся через год

Какие архитектурные решения на старте кажутся удобными, но через год начинают мешать команде?

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

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

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

Был ли в твоей практике проект, где архитектурное решение пришлось серьезно пересматривать? Что пошло не так и как вы это поняли?

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

Что изменилось в твоем подходе с опытом?

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

Как не построить слишком сложную систему

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

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

Можно ли создать универсальную архитектуру тестирования или она каждый раз должна строиться вокруг конкретного продукта и его рисков?

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

Как ты решаешь, какие проверки автоматизировать, какие оставить ручными, а от каких вообще отказаться?

— Я смотрю не только на возможность автоматизации, но и на ценность конкретной проверки. Обычно решение зависит от нескольких вещей:

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

• Критичность для бизнеса. Основные пользовательские и финансовые сценарии должны контролироваться постоянно.

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

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

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

Хорошая архитектура должна выдерживать изменения

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

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

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

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

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

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

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

Что бы ты сделал сегодня

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

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

1. Определить основные риски продукта. Что должно работать всегда и где ошибка будет стоить бизнесу дороже всего.

2. Распределить проверки по уровням. Не переносить все в пользовательский интерфейс, если бизнес-логику быстрее и надежнее проверить на уровне компонентов или API.

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

4. Продумать поддержку тестов. Еще до автоматизации стоит оценить, как будут меняться тестовые данные, интерфейсы, интеграции и сами сценарии.

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

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

Вместо заключения

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

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