«Меня вдохновляет то, что я многого не знаю, но хотел бы узнать». SDET-инженер крупного российского банка об архитектуре автоматизации тестирования и о кайфе от сложных задач

IT Test продолжает серию интервью с QA-инженерами и тестировщиками из бигтеха, чтобы узнать, как устроена работа по обеспечению качества известных IT-продуктов изнутри. SDET-инженер крупного российского банка Антон Мурзинов рассказывает, почему недостаточно писать только автотесты, зачем иногда идти на риск в работе и как кайфовать от сложных задач.

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

SDET-инженеры сокращают ресурсы на тестирование за счет того, что разрабатывают фреймворки, инструменты, внедряют автоматизацию и налаживают процессы в команде. Возможно, я не прав, но SDET-инженеры, на мой взгляд, обладают большим спектром технических навыков, чем AQA. Это мастера на все руки в разработке, тестировании и DevOps-практиках. Считаю ли я себя полноценным SDET? В последние полгода, наверное, стал считать, потому что мои проекты уже не просто про автотесты: в последний квартал я полностью снес legacy автоматизацию и спроектировал архитектуру, на базе которой автотесты собираются также легко, как конструктор Lego.

Изначально я хотел стать плюсовым разрабом (разработчик С++), но из-за того, что на стажировке не оказалось мест, я пошел в QA, причем вслепую. На втором курсе университета я попал на стажировку во французскую IT-компанию: команда разработки находились в РФ, а менеджмент — во Франции. Там я сразу начал писать хлюпенькие автотесты для десктоп-приложения. Это был важный опыт, потому что всё было на английском, и я за год работы на позиции джуна смог хорошо подтянуть язык.

Совмещать учебу с работой было дико сложно, но мне повезло, потому что я жил в пяти минутах от ННГУ имени Лобачевского, где учился, и мне было удобно бегать на пары и обратно. В этой компании я проработал до ее ухода из России в конце 2022 года, а потом устроился в IT-подразделение «Мегафона». Затем пришел покорять финтех.

В прошлом квартале я переписывал фреймворк для UI-тестирования. По сути, самих автотестов я почти не писал: переделывал архитектуру и само ядро, а уже потом накидывал тесты. Суть в том, что если правильно спроектировать систему, то сами тесты сделать будет легко. Основная сложность — реализовать гибкий высокоуровневый API: чтобы тестики писались быстро, легко и стабильно, а логи в автотестах были понятны любому ручному тестировщику. Я много времени посвятил этому фреймворку и сейчас привожу в порядок автотесты, которые были написаны до меня.

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

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

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

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

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

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

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

Советы начинающим QA-специалистам.

Больше экспертных материалов о тестировании в Telegram-канале TMS DoQA.