Привет!

Меня зовут Антон, я специалист по автоматизации тестирования (AQA) в 2ГИС.

В автоматизацию я пришёл из Python backend-разработки. Так вышло, что среди обычных задач мне захотелось попробовать написать e2e-тесты. В итоге тестирование стало моей основной работой. Обычно про карьерный путь рассказывают в обратном направлении: начал с тестирования, а потом перешёл в разработку. У меня получилось иначе. Поэтому я хочу ответить себе и вам на вопрос: «Почему я продолжаю работать в тестировании, не переходя обратно в разработку?»

Для этого расскажу, из чего складывается моя работа и что обычно остаётся незримым за формулировкой «пишет автотесты». Надеюсь, что после этой статьи вы посмотрите на AQA немного иначе ?

Не ступень перед разработкой, а отдельная специализация

Наверняка многие слышали про идею «войти в IT через тестирование» или «тестирование — лишь временная ступень перед разработкой».

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

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

Среди разработчиков я не раз встречал мнение, что работа тестировщиков скучная и однообразная:

• проверяют одно и то же по сто раз;

• пишут однотипные простые тестики;

• проверяют только готовый функционал и не влияют на инженерные решения.

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

Написать тест — только часть работы

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

Разработка тестового кода

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

• API-клиенты для REST и gRPC;

• вспомогательные библиотеки;

• генераторы тестовых данных;

• моки и тестовые сервисы;

• фикстуры и механизмы очистки;

• отчётность и диагностика падений;

• параллелизация;

• конфигурация запуска на разных окружениях.

Всё это нужно спроектировать, поддерживать и рефакторить. А ещё сделать так, чтобы другой человек мог добавить проверку, не разбираясь несколько дней во внутренней магии фреймворка. Поэтому при написании тестового кода возникают вполне обычные для разработки вопросы:

• Что вынести в общую библиотеку?

• Где абстракция действительно помогает, а где только прячет происходящее?

• Как избежать дублирования и при этом сохранить читаемость сценариев?

• Как написать документацию, чтобы она приносила пользу?

Например, общая фикстура может ускорить запуск, но усилить зависимость между тестами. Полная изоляция делает результат предсказуемее, но иногда обходится дороже по времени и ресурсам. Универсальный API-клиент выглядит красиво, пока для простого запроса не приходится проходить через несколько слоёв обёрток.

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

Данные и состояние системы

Будь то подготовка тестовых данных, проверка результата или диагностика бага — везде AQA работает с базами данных и брокерами сообщений. Это может быть SQL-запрос, локально поднятая БД/Kafka, применение миграций, работа через CLI или графический клиент. И интерес здесь не в количестве инструментов. Важнее другое: как получить нужное состояние системы и убедиться, что проверка не зависит от случайностей?

Допустим, тест создаёт сущность и затем проверяет её изменение. Откуда взять исходные данные? Создать через публичный API, воспользоваться внутренним инструментом или записать напрямую в БД? Каждый вариант имеет свои плюсы и минусы.

А что произойдёт при параллельном запуске? Не изменят ли два теста одну и ту же запись? Не удалит ли очистка данные соседнего теста? Сможем ли мы повторить упавший сценарий?

Иногда для диагностики недостаточно ответа API. Нужно посмотреть, что записалось в БД/Kafka, как изменилось состояние после обработки события и на каком этапе результат разошёлся с ожиданием.

Всё это не делает автоматизаторов специалистами по проектированию и эксплуатации баз данных. Но без этих знаний сложно решать все описанные проблемы.

Интерфейсы и тестируемость

Для разработки UI-тестов часто приходится работать с DevTools: изучать DOM, искать элементы, смотреть сетевые запросы и сообщения в консоли. При этом задача не сводится к «найти кнопку и нажать». Нужно понять, когда интерфейс действительно готов к действию, какое состояние считать результатом операции и как найти элемент так, чтобы небольшая правка вёрстки не сломала половину тестов.

Поэтому полезно обсуждать тестируемость ещё до того, как функциональность полностью готова. Например:

• какие устойчивые атрибуты будут у элементов;

• как определить нужное состояние UI;

• по какому признаку понять, что загрузка закончилась;

• как воспроизвести ошибку внешнего сервиса.

В некоторых командах AQA может самостоятельно вносить правки в продуктовый код, чтобы улучшить его тестируемость. Такой подход даёт возможность непосредственно влиять на продукт, помогать делать его более наблюдаемым и проверяемым. Это полноценное влияние на инженерные решения, пусть и в пределах своей области ответственности.

Окружения и автоматический запуск

Тест, который работает только на моём ноутбуке, не приносит команде пользы. Нужен тест, который будет запускаться автоматически и в воспроизводимых условиях. В зависимости от команды AQA может настраивать это самостоятельно или работать вместе с инфраструктурными инженерами.

Здесь появляются GitLab Pipelines, GitHub Actions, Jenkins, Docker и Docker Compose, а иногда Kubernetes и Helm. Но задача не состоит в том, чтобы просто «запихнуть проект в Docker». Перед запуском может потребоваться поднять backend, frontend, базу данных и моки, передать конфигурацию и дождаться готовности всех зависимостей. После запуска — сохранить отчёт, логи и другие артефакты, а затем освободить ресурсы.

Отдельное удовольствие — разбираться, почему локально всё зелёное, а в CI падает ? Причиной может оказаться различие версий, нехватка ресурсов, сетевой доступ или неверное предположение о порядке запуска тестов или сервисов. Тут приходится выходить за пределы тестового кода и исследовать окружение. А это уже часть автоматизации, близкая к работе DevOps-инженеров. 

Требования и взаимодействие с командой

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

Что должен увидеть пользователь, если запрос завершился ошибкой? Допустимо ли промежуточное состояние? За какое время должен появиться результат? Что делать с повторным запросом? Хорошо, если эти вопросы возникают до реализации, а не после первого красного теста.

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

Какие инженерные задачи решает AQA

Скучная ли у нас работа? Хотелось бы написать «ни разу», но это было бы слишком удобно опровергнуть в комментариях. Скучные задачи бывают, куда без них. Но меня удерживает не их отсутствие, а то, что работа регулярно требует разбираться в новом и выбирать между несколькими решениями. Вот несколько типичных вопросов.

Почему тест проходит отдельно, но падает в общем запуске

Может быть, тесты используют общие данные. Может быть, один меняет глобальное состояние. А может, сервис не выдерживает параллельную нагрузку.

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

Как проверить асинхронный результат без фиксированного sleep

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

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

Что проверять через UI, а что через API

Один и тот же результат иногда можно проверить на нескольких уровнях. Но стоимость запуска, надёжность и диагностическая ценность у таких проверок будут разными. Не всегда стоит воспроизводить через браузер всё, что можно проверить ниже. При этом API-тест не докажет, что пользователь вообще может выполнить нужное действие в интерфейсе. Приходится выбирать подходящий уровень, а не автоматически писать ещё один end-to-end-сценарий.

Как сделать падение понятным

Красный тест должен не просто сообщить: «ожидали одно, получили другое». По его выводу хочется быстро понять, что сломалось: продукт, тестовые данные, сама проверка или окружение. Для этого нужны полезные сообщения, параметры запроса, ответы сервиса, логи, а для UI — иногда скриншоты и трассировка действий. Хорошая диагностика экономит время не только автору теста, но и всей команде.

Что вообще стоит автоматизировать

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

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

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

С чем предстоит работать

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

Это не список требований к AQA и утверждение, что всё перечисленное нужно знать одинаково глубоко. И учить всё это перед первой работой, конечно, не нужно. Но знать основы будет полезно.

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

Обратная сторона разнообразия

У такого формата работы есть и свои сложности. Обязанностей много и уровень ответственности разный — вместе с ними растёт и объём того, что нужно держать в голове.

Переключение контекста

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

Поддержка автоматизации

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

Flaky-тесты

Если тест иногда падает без понятной причины, команда начинает привыкать к красному пайплайну. «Перезапусти, должно пройти» становится обычной реакцией. Это опаснее, чем кажется: вместе с шумом можно пропустить реальную проблему. Поэтому flaky-тесты не просто неприятная особенность, с которой остаётся смириться. Это инженерная проблема, которую нужно исследовать и сокращать. Хотя поиск причины иногда занимает заметно больше времени, чем написание самого сценария.

Границы экспертности

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

И ещё важно помнить, что широта задач зависит от команды. Где-то AQA работает в узкой зоне, где-то отвечает за большой кусок тестовой инфраструктуры. Само название должности не гарантирует ни разнообразия, ни его отсутствия.

Почему я останусь в AQA

Поработав с разными сторонами продуктов и тестовой инфраструктуры, я понял, что мне подходит именно такое сочетание задач. Мне нравится, когда программирование соседствует с исследованием системы, работой с данными, настройкой окружения, а также тесным взаимодействием со всеми членами команды: от ручных QA до PM. Мне нравится, что результат этой работы нужен не только мне: проверками и диагностикой пользуются коллеги.

Возможно, прозвучит банально, но мне интересен весь цикл: развернуть проект, подготовить тестовые данные, спланировать проверки и написать тест. Увидеть, как он работает. Или не работает ? Разобрать результат и понять почему. Мне нравится сама задача: превратить знание о поведении системы в стабильную проверку, которой команда может доверять.

И на этом работа не заканчивается. Тестовый проект растёт, а вместе с ним появляются новые инженерные задачи: что-то пора отрефакторить, что-то — вынести в общую библиотеку, где-то — разобраться с изоляцией данных или ускорить параллельный запуск. Поэтому для меня AQA — не временная остановка перед разработкой, а самостоятельный выбор. Мне нравится не только писать тестовый код, но и решать всё, что необходимо для его полезной и надёжной работы.

Надеюсь, мне удалось показать ту часть профессии, которая не всегда видна со стороны.

Друзья-автоматизаторы, накидайте в комментарии интересные задачи/инструменты, о которых я не рассказал. А коллеги из других направлений — расскажите, на каких задачах вы чаще всего пересекаетесь с AQA.