Многие разработчики и начинающие тестировщики считают регрессионное тестирование рутинной и скучной работой. Максим Атлашкин, руководитель отдела регрессионного тестирования РСХБ-Интех, готов развеять этот миф.
Из интервью вы узнаете, как за 2,5 года пройти путь от джуна до лида регрессионного тестирования. Максим расскажет реальные истории о спасении релизов благодаря тестированию и поделится инсайдами о процессах тестирования в крупном банковском IT-проекте.
Максим, как ты пришёл в сферу тестирования?
Пришел в тестирование в 20-м году из сопровождения первой линии другого банка, где во время процесса перехода на новую систему ДБО (другими словами клиент-банк) мой отдел начал изучать систему раньше пользователей и находил ошибки. Делали мы это исследовательским путем, ошибки записывали по шагам и передавали письмом (багтрекера для сопровождения не было) в отдел разработки. Мне этот процесс понравился, особенно когда была обратная связь и ошибки действительно исправляли, и нужно было сделать ретест. Тогда-то и начал интересоваться тестированием в целом, искал информацию в интернете по типу «Как тестировать», прошел несколько бесплатных курсов и решил, что нужно профессионально идти в тестирование, параллельно продолжая изучать эту сферу.
Что тебя вдохновило на занятие регрессионным тестированием?
Цели идти именно в регрессионное не было. У меня не было опыта, и я не до конца понимал, как это работает на тот момент. Я оказался в РСХБ-Интех и изначально попал в команду регресса ДБО для юридических лиц. Только месяц-два изучил, как и что тут работает, как пришла пора «распиливать» монолит на микросервисы, появились продуктовые команды разработки, и колесо фортуны закинуло меня в одну из них, да еще и с очень критичным продуктом платежей и переводов. Там я на практике познакомился с большим количеством инструментов (Postman, Swagger, BrowserStack, DBeaver, Fiddler и др.). Впервые поработал в гибкой методологии agile, ранее был знаком только с waterfall-ом. Моему счастью не было предела. Шутка =)
Как добился успеха в тестировании и перешёл из уровня джуна в руководители?
Спустя полтора года усердной работы я значительно вырос как специалист и стал обучать других. Естественно вырос и уровень до мидла в технической части. У меня появились инициативы по развитию проекта, процессов тестирования, внедрению новых правил выпуска релизов и в том числе регресса. У меня был другой взгляд на тестирование. Как бывший специалист первой линии я видел то, что не видели другие, и предлагал коллегам новые решения. Одни решения нашли отклик и были успешно внедрены, другие после совместного анализа с лидом тестирования переработали или отменили. Главное не бояться, пробовать, предлагать, но с умом.
Часто задерживался, чтобы проверить, действительно ли новый процесс упростит жизнь команды. Мне был интересен результат. Но вышло так, что это оказалось инвестицией в будущее. Инновации требуют смелости — иначе это просто рутина.
На тот момент больше всего на проекте страдал процесс тестирования релизов и их внедрение, а я успешно помогал внедрять сам процесс и подходы. Спустя время за привнесенный вклад в развитие процессов эта активность была высоко оценена руководством, и мне предложили возглавить направление регрессионного тестирования. И продолжать в том же духе =)
На старте мне доверили одну команду регресса ДБО, в дальнейшем направление выросло до двух полноценных отделов, обслуживающих ключевые банковские системы.
Каковы основные задачи твоего отдела, и как они влияют на общий процесс разработки программного обеспечения?
Основная задача — это финальное тестирование перед релизом и принятие решение о выводе доработки в промышленную эксплуатацию. Весь процесс тестирования на проекте я разделю на три этапа.
Первый — это изучение и тестирование требований, написание тестовой документации и моральная подготовка к работе с новой фичей =)
Второй этап — тестирование фичи по функциональным и нефункциональным требованиям, соответствие дизайну и все, что с этим связано, будь то большая новая фича с кучей интеграций или перекрас кнопки из синей в серо-буро-малиновый.
Третий этап — регрессионное тестирование. В первые два этапа участвует только тестирование продуктовой команды, а вот на третий этап приходим мы. Проверяем, что не сломался уже существующий и зависимый функционал, плюс перепроверяем, что новые изменения соответствуют функциональным требованиям. Скажете, двойная работа? А я скажу доверяй, но проверяй.
На проектах больше 30 продуктовых команд, в каждой работает от 1 до 4 тестировщиков. Шанс, что кто-то пропустит что-то важное невелик, но и не равен нулю. Например, был опыт, когда во время переноса одной готовой фичи со стенда разработки на стенд регресса зацепили лишнюю и сырую фичу, отловили, вернули в работу, все счастливы, что ничего сырого не уехало на прод.
И если так случается, что кто-то своим кодом ломает функционал, еще и если функционал соседа, то принимается решение об отказе релизе для данной команды. И такое бывало. И не раз. И это не страшно в рамках проекта. Куда страшнее разбор падений на проде и в конечном итоге все равно откат функционала.
Какие инструменты и технологии вы используете для автоматизации регрессионного тестирования, и как они помогают твоей команде?
На проекте есть отдельная команда автоматизации, с которой мы плотно сотрудничаем для сокращения времени регресса и улучшения качества продукта.
Немного про стек автоматизации.
В качестве языка программирования взяли Java
Для тестирования Frontend — Selenium, Backend — REST‑assured.
Для хождения в БД используем стандартные библиотеки из Java.
И для разработки самих автотестов взяли Cucumber.
Красивые отчеты в Allure.
Как я уже сказал есть отдельная команда автоматизации, но Cucumber используем не просто так, а для обучения manual QA в продуктовых командах написания самих автоматизированных сценариев и дальнейшего их запуска.
Этот процесс — заслуга команды автоматизации. Почитать подробнее о нашем процессе можно в этой статье на Хабре.
Мы (команда регресса) в свою очередь используем уже готовые автотесты для запуска и дальнейшего анализа упавших ТК.
Все прогоны фиксируются в Test-IT, поэтому после прогона мы анализируем и проходим только упавшие и те тест-кейсы, что невозможно автоматизировать (из-за специфики интеграций) вручную.
Помощь в этом процессе на самом деле колоссальная, особенно при большом количестве конфигураций. Без автотестов команда регрессионного тестирования была бы в два раза больше и вся в мыле =).
Как ты определяешь приоритеты для тестов? На что ты обращаешь внимание при выборе сценариев для регрессионного тестирования?
Тут стандартно, как у всех. В первую очередь тест-кейсы, охватывающие критический путь, чтобы убедиться в том, что основные функции работают корректно после изменений. И далее по убыванию приоритета тест-кейса и критичности функционала.
С какими основными вызовами сталкивается твой отдел, и как вы их преодолеваете?
Основной вызов — успеть ВСЕ в срок ). Ну а если серьезно, то это заставить работать все интеграционные сервисы и системы, так как регрессионное тестирование проводим не на заглушках/моках, а на реальной интеграции с другими тестовыми стендами других жизненно необходимых систем для ДБО.
Почему не на заглушках? Потому что сквозное интеграционное тестирование тоже нуждается в регрессе. Иначе как понять, что интеграционная система присылает в одних случаях абракадабру, а в других придет какой-нибудь null.
Ну и сложности коммуникации с другими «сильно занятыми отделами». С этим ничего не поделать, у всех свои задачи и дедлайны. Все понимаем, но иногда приходится быть капельку настойчивее, конечно, в рамках корпоративной этики. Об этом не забываем.
Как вы работаете с командами разработчиков и менеджеров проектов, чтобы обеспечить качественное тестирование?
Основная коммуникация у тестировщиков команды регресса — это тестировщики из продуктовой команды, например, по вопросам тест-кейсов и требований. Но если вдруг возникает вопрос, где нужен именно разработчик, тестировщик продукта подключает его или решает вопрос сам и передает нам результат. Но как правило, такая коммуникация происходит в рамках найденного нами дефекта.
А вот если уже говорить про позицию лида регрессионного тестирования, тут чаще прихожу не я, а ко мне. Это релиз-менеджер, продакт-оунеры, аналитики, менеджеры задач, и — да, порой приходят разработчики, дизайнеры, архитекторы и кто только ко мне не приходит с вопросами =)
И я на самом деле готов помочь каждому, чем смогу.
Какие у тебя будут рекомендации для начинающих тестировщиков, желающих специализироваться в регрессионном тестировании?
Регресс вовсе не скучный (по крайней мере у нас) и не однообразный, как может показаться на первый взгляд, это хорошее начало в карьере для закрепления теории тестирования, работы с основными инструментами тестирования и понимания SDLC и STLC.
Тем, кто хочет развивать карьеру, могу рекомендовать проявлять активный интерес, к продукту, который вы создаете, любить его. Не бояться проявлять инициативу и выстраивать дружескую коммуникацию как со своим лидом, так и с коллегами. Прокачивайте soft skills, если планируете расти из QA в руководители, иначе никак. Тогда у вас все получится, и вознаграждение вас настигнет.
