Привет, я Сергей Казаков — Senior AQA в СБЕР. Уже больше десяти лет занимаюсь обеспечением качества программного обеспечения: от ручной проверки веб-продуктов до проектирования автоматизированных наборов и встраивания тестов в CI/CD. Сегодня мой основной стек — Python: на нём я пишу API- и UI-автотесты, собираю фреймворки и поддерживаю инфраструктуру прогонов в пайплайнах.

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

Чем занимаюсь сейчас

Как Senior AQA я совмещаю hands-on разработку автотестов с инженерными задачами уровня команды: выбираю инструменты, задаю стандарты кода тестов, настраиваю прогоны на стендах и помогаю коллегам поднимать качество без лишней бюрократии. Моя зона ответственности — чтобы критичные пользовательские сценарии и контракты API проверялись автоматически после каждой значимой сборки, а ручное тестирование оставалось там, где оно действительно даёт ценность: исследовательские сессии, приёмка, нестандартные кейсы.

Навыки в тестировании

Функциональное и системное тестирование

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

E2E-автоматизация (UI)

Пишу сквозные автотесты для веб-интерфейсов: регистрация, авторизация, оформление заказов, личный кабинет — всё, что влияет на бизнес-метрики. В работе использую Playwright и Selenium, опираюсь на Page Object, фикстуры pytest и переиспользуемые хелперы. Слежу за стабильностью локаторов, явными ожиданиями и изоляцией данных между прогонами, чтобы набор не «сыпался» в CI из-за флакинга.

API-автоматизация

REST-сервисы проверяю на Python с requests и pytest: статусы ответов, схема и содержимое тела, заголовки, негативные сценарии (невалидные токены, пустые поля, граничные значения). API-тесты часто запускаю раньше UI — они быстрее и точнее ловят регресс на контракте. Там, где уместно, комбинирую UI и API в одном сценарии: подготовка данных через API, проверка отображения в браузере.

Архитектура тестовых фреймворков

Проектирую структуру репозитория с автотестами: слои page objects, клиенты API, фабрики тестовых данных, конфигурация окружений, единые ассерты и логирование. Настраиваю параллельный запуск, ретраи только там, где это оправдано, и отчёты (Allure и аналоги), по которым разработчик за минуты понимает причину падения. Хороший фреймворк для меня — тот, в который новый инженер может добавить кейс за полдня, не ломая соседние тесты.

CI/CD и инженерная культура качества

Встраиваю автотесты в Git и пайплайны: smoke после деплоя на стенд, регресс по расписанию или перед релизом, блокировка мержа при падении критичного набора. Согласовываю с командой, что именно должно быть gate, а что — информативным сигналом. Участвую в разборе flaky-тестов, поддерживаю тестовые стенды и договариваюсь о тестируемости фич ещё на этапе проектирования.

Стек и инструменты

  • Язык: Python (pytest, typing, виртуальные окружения, линтеры)
  • UI: Playwright, Selenium WebDriver
  • API: requests, работа с JSON и OpenAPI/Swagger
  • Инфраструктура: Git, CI/CD (Jenkins, GitLab CI и аналоги), Docker при необходимости
  • Отчётность: Allure, артефакты прогона (скриншоты, trace, HAR)
  • Документация: тест-кейсы, чек-листы, тест-планы, баг-репорты в Jira/аналогах

Достижения за годы в профессии

За десять лет в тестировании накопился опыт и в продуктовых командах, и в крупных корпоративных контурах. Ниже — то, чем я по праву горжусь; формулировки обобщённые, без привязки к внутренним кодам проектов.

  • Выстроил и развил автоматизацию с нуля — в нескольких командах переводил проверки с «раз в спринт вручную» на регулярные прогоны в CI: сначала smoke, затем расширенный регресс. Время обратной связи после сборки сократилось с часов до десятков минут.
  • Стабилизировал наборы в пайплайне — снизил долю ложных падений за счёт рефакторинга локаторов, явных ожиданий и отказа от хрупких sleep. Команда снова начала доверять результатам прогона, а не отключать упавшие job «чтобы не мешали».
  • Спроектировал переиспользуемый фреймворк на Python — единые page objects, API-клиенты и фикстуры, которые подхватили другие тестировщики и разработчики. Онбординг нового человека в автотесты сократился с недель до нескольких дней.
  • Закрыл риски на критичных пользовательских потоках — регистрация, платежи, выпуск продуктовых операций: автотесты поймали регрессы до выкладки на прод, что неоднократно экономило команде горячие исправления и репутационные потери.
  • Менторил коллег — помогал manual QA переходить в автоматизацию: code review тестов, парное написание первых кейсов, разбор падений в CI. Несколько специалистов уверенно пишут свои сценарии на pytest без постоянной поддержки.
  • Влиял на качество на этапе требований — участвовал в ревью спецификаций и макетов, задавал вопросы про граничные случаи и тестируемость API. Меньше дефектов уходило в разработку «по умолчанию», потому что неясности всплывали до кода.

Как я подхожу к работе

Считаю, что тестирование — это не «найти баги в конце», а часть инженерного цикла. Автотесты должны быть читаемыми, как продакшен-код: понятные имена, минимум дублирования, осмысленные сообщения при падении. Ручные проверки — не конкурент автоматизации, а дополнение: там, где сложно формализовать ожидание или нужен живой взгляд на UX.

На этом сайте я собираю практикумы и статьи — чтобы делиться опытом и давать площадку для отработки навыков: от оформления тест-кейсов до написания E2E на формах регистрации. Если вам близок такой подход к качеству — буду рад связаться: kazakov.testing@gmail.com, Telegram.