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

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

Фото: из личного архива Светланы Ивановой by Светлана Иванова, https://creativecommons.org/public-domain/pdm/

Светлана Иванова, инженер по автоматизации тестирования

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

— Светлана, что вообще проверяет автоматизация и зачем она нужна?

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

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

— Как система, созданная для экономии времени, начинает его отнимать?

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

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

— Как понять, что система движется в эту сторону?

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

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

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

— Почему нельзя сразу построить систему правильно? И всегда ли нужно объединять похожие решения?

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

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

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

— С чего вы начинаете, когда создаете систему автоматизированных проверок с нуля?

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

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

— Почему тестовые данные и независимость проверок настолько важны?

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

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

— А если проверка сообщает об ошибке, но после повторного запуска все проходит?

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

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

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

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

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

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

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

— А если система уже стала сложной? Как понять, что ее пора переписывать?

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

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

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

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

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

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

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

— Вы больше десяти лет работаете в автоматизации. Что за это время изменилось в вашем понимании хорошей системы?

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

Хорошая система должна отвечать на практические вопросы: что мы проверили, что произошло, насколько можно доверять результату и что делать дальше. И еще один важный момент — она должна оставаться понятной по мере роста.

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

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