Когда я пришёл в АТБ Банк на позицию лидера практик автоматизации тестирования, передо мной стояла задача не просто увеличить количество автотестов. Моя цель состоит в том, чтобы выстроить системный подход, при котором автоматизация действительно помогает командам быстрее и безопаснее выпускать изменения. Можно написать сотни автотестов, но не получить от них практической пользы. Тесты могут быть нестабильными, долго выполняться, дублировать ручные проверки и регулярно падать не из-за дефектов продукта, а из-за проблем в самих сценариях. Поэтому я начал не с вопроса: «Сколько автотестов нам нужно написать?» А с другого: «Какие проблемы команд и бизнеса должна решить автоматизация?» Для себя я определил несколько основных целей: • сокращение времени регрессионного тестирования; • получение быстрой обратной связи после изменений; • снижение количества дефектов в промышленной среде; • повышение предсказуемости релизов; • освобождение тестировщиков от повторяющихся ручных проверок; • формирование единого подхода к автоматизации во всех командах. Первым этапом стала оценка текущего состояния. Мне важно было понять: • какие системы уже покрыты автотестами; • насколько стабильно выполняются существующие сценарии; • какие процессы критичны для бизнеса; • где ручная регрессия занимает больше всего времени; • как автоматические проверки встроены в CI/CD; • насколько быстро команды могут определить причину падения теста. Следующий этап заключается в формировании общей стратегии автоматизации. Я придерживаюсь подхода, при котором автоматизация строится на нескольких уровнях. API-тесты должны проверять бизнес-логику, обработку данных и взаимодействие между сервисами. Интеграционные тесты должны подтверждать корректность обмена данными между банковскими системами. UI-тесты должны покрывать ключевые пользовательские сценарии, которые нельзя полноценно проверить на более низком уровне. Мобильные автотесты должны проверять критичные операции в приложении на Android и iOS: авторизацию, переводы, платежи, работу с картами, счетами и другими банковскими продуктами. Для мобильного тестирования особенно важны проверки на разных версиях операционных систем, устройствах, разрешениях экрана и при нестабильном интернет-соединении. При этом важно соблюдать баланс пирамиды тестирования. Основная часть проверок должна выполняться на уровне API и компонентов. UI- и мобильная автоматизация должны применяться осознанно, поскольку такие тесты обычно дороже в разработке и сопровождении. Отдельное внимание я уделяю качеству самих автотестов. Для меня важны не только количество сценариев и процент покрытия, но и: • стабильность прохождения; • скорость выполнения; • независимость тестов; • возможность параллельного запуска; • понятность отчётов; • удобство сопровождения; • скорость анализа падений. Нестабильный тест не повышает качество. Он создаёт информационный шум и постепенно снижает доверие команд ко всей автоматизации. Поэтому в рамках развития практики я работаю над едиными правилами разработки автотестов, код-ревью, управлением тестовыми данными, отчётностью и регулярным разбором нестабильных сценариев. Также для меня важно, чтобы автоматизация была встроена в процесс разработки, а не существовала отдельно от него: Изменение кода → сборка → автоматические проверки → анализ результата → решение о дальнейшем выпуске Чем раньше команда получает информацию о проблеме, тем дешевле и быстрее её исправить. Ещё одно направление моей работы заключается в формировании понятных метрик. Мы должны видеть не только количество написанных тестов, но и реальный эффект: • покрытие критичных бизнес-сценариев; • покрытие ключевых сценариев мобильного приложения; • длительность автоматизированной регрессии; • процент стабильного прохождения; • количество дефектов, найденных автотестами; • объём сокращённой ручной работы; • долю ошибок, выявленных до промышленной эксплуатации. Я не ставлю задачу автоматизировать всё подряд. Автоматизировать нужно те сценарии, которые регулярно выполняются, имеют понятный ожидаемый результат, критичны для бизнеса и дают измеримый эффект.