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

Как выстраивать процессы контроля качества под конкретный продукт, рассказала Светлана Иванова, ведущий инженер по автоматизации тестирования в М.Тех (технологическое подразделение М.Видео).

Светлана Иванова, ведущий инженер по автоматизации тестирования в М.Тех

Светлана, почему нельзя создать универсальную систему тестирования для всех программных продуктов по аналогии с ГОСТами в промышленности?

«Ответ кроется в разном уровне риска. Сравните платформу для публикации кулинарных рецептов и систему управления банковскими переводами. Сбой на первом сайте вызовет лёгкое раздражение, а во втором миллионные убытки. Универсальная система подразумевает усреднение. Примените строгие банковские правила к развлекательному проекту разработка станет невыносимо дорогой. А лёгкий подход в госреестре обернётся катастрофическими уязвимостями. Защитные рубежи выстраиваются исходя из того, сколько на самом деле стоит пропущенная ошибка».

То есть «дешёвый» продукт не требует качественного тестирования? Это звучит опасно.

«Нет, я не это имею в виду. Качество нужно всегда, но уровень его контроля разный. Для стартапа нет смысла гонять полный регресс по 500 тест-кейсам перед каждой отправкой кода вы просто не выпустите продукт. Но когда этот стартап вырастет до 10 миллионов пользователей, подход должен измениться кардинально. Проблема в том, что компании часто не меняют стратегию вовремя».

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

«Выделю три фактора: архитектуру, частоту обновлений и специфику аудитории. Монолитная программа требует масштабной повторной проверки всех функций при каждом изменении, мы называем это регрессом. В одном из моих проектов на монолите полный прогон занимал 1 рабочий день. Когда мы разделили систему на независимые микросервисы, те же проверки в изолированных средах стали занимать до 30 минут. Если выпуск новых возможностей происходит несколько раз в день, без мощной автоматизации не обойтись. И ещё важно, где работает продукт: в закрытой корпоративной сети с одинаковыми компьютерами или на тысячах разных устройств у обычных пользователей. Во втором случае потребуются огромные ресурсы на проверку совместимости».

Один день и 30 минут это впечатляющая разница. Но разве микросервисы сами по себе решают проблему?

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

Почему копирование процессов тестирования из успешных ИТ-гигантов часто приводит к проблемам в других компаниях?

«Процесс обеспечения качества формируется вместе с проектом. У крупной корпорации есть вычислительные мощности и десятки инженеров, чтобы код проходил сотни автоматических проверок до попадания в общую базу. Если руководитель потребует внедрить то же самое в молодой компании из 30 человек, цепочка сборки просто остановится. Инфраструктура не справится, разработчики будут часами ждать результатов».

Можете привести конкретный пример, когда «копирование» закончилось плохо?

«Был случай, когда я пришла в компанию, и там только что внедрили практику известного западного гиганта: каждый запрос на изменение проходил 12 часов автотестов перед слиянием. В теории здорово. На практике команда из 15 разработчиков начала создавать ветки локально и неделями не отправлять код в репозиторий, чтобы не ждать. В итоге интеграционные проблемы всплывали не в момент отправки кода, а за неделю до релиза. Мы откатились к упрощённой схеме: короткие тесты на входе, полный регресс ночью. Скорость выросла втрое».

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

«В банковских системах главное безопасность и точность транзакций. Здесь проводят многоуровневый анализ уязвимостей и строгие проверки целостности данных. Для интернет-магазинов критична производительность при наплыве покупателей и удобство клиентской части. В госуслугах акцент на строгое соответствие законам и доступность для людей с ограниченными возможностями. Мобильные приложения требуют тестирования на парке реальных устройств: мы держим около 40 физических устройств, чтобы проверить поведение при обрывах связи, входящих звонках или переполненной памяти. А на высоконагруженных платформах мы намеренно создаём сбои прямо во время работы, это проверка способности системы к самовосстановлению».

Как определить, что существующая стратегия тестирования уже не подходит продукту?

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

А есть какая-то цифра, за которой нужно бить тревогу? Доля багов от пользователей?

«Если критические дефекты от клиентов начинают превышать 5-7% от общего числа найденных проблем, это повод остановиться и пересмотреть процесс. Но главный маркер даже не цифра, а поведение команды. Когда разработчики говорят: „Я лучше не буду трогать этот модуль, а то опять всё сломается", у вас серьёзная проблема».

Какие ошибки чаще всего совершают компании при построении процессов тестирования?

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

Расскажите подробнее про первую ошибку. Вы сами в это попадали?

«О да. На текущем проекте в первое время у нас были частые изменения в интерфейсе, потому что проект подстраивался под пользователей и мы старались в короткие сроки вносить правки. Написали около 200 тестов. Через месяц 60% из них падали не из-за багов, а из-за смены вёрстки. Мы потратили два месяца на поддержку скриптов вместо поиска реальных проблем. Вывод: автоматизируйте стабильное, а не всё подряд».

Почему автоматизация сама по себе не решает проблему качества?

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

Как меняется стратегия тестирования по мере развития продукта?

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

Есть ли точка, когда нужно резко наращивать команду тестирования?

«Не „резко", а плавно. Обычно это момент, когда релизный цикл сокращается до одной-двух недель, а команда разработки растёт быстрее, чем успевает проверять результат. Но наращивать команду без автоматизации всё равно что лить воду в решето».

Как найти баланс между скоростью разработки и качеством?

«Помогает подход, основанный на оценке рисков. Для критических путей (оплата, регистрация, сохранность данных) мы выстраиваем строжайшие автоматические проверки. А для второстепенных функций, вроде изменения цвета профиля, можно выпустить версию быстрее и исправить мелкие недочёты по отзывам. Чтобы не терять скорость, мы распараллеливаем процессы в изолированных контейнерах: отчёт о состоянии системы получаем за считанные минуты».

Но пользователи же ругаются, когда видят мелкие баги даже в косметике?

«Ругаются. Но есть разница между „кнопка не того оттенка" и „кнопка списала деньги дважды". Риск-ориентированный подход не означает, что мы выпускаем некачественный продукт. Он означает, что мы тратим 80% ресурсов на то, что может сломать бизнес, а не на перфекционизм в деталях».

Какие рекомендации вы дадите компаниям, которые хотят построить эффективную систему тестирования?

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

Если оставить один совет тем, кто читает это интервью и завтра пойдёт внедрять изменения в своей команде?

«Не начинайте с покупки инструментов. Начните с разговора. Посадите разработчиков, тестировщиков и аналитиков за один стол и спросите: "Какая ошибка, найденная пользователем, стоила нам больше всего за последний год?" Ответ на этот вопрос покажет, где у вас действительно боль. Всё остальное уже техника».