Middle QA Engineer / Tester

крупный розничный банк (Хоум Банк, с апреля 2025 — Совкомбанк).Внутренняя разработка системы «Кредитный Контур» — сквозной процесс оформления, скоринга, выдачи и сопровождения кредитных продуктов (потребительские кредиты, ипотека, рефинансирование) с интеграцией онлайн- и оффлайн-каналов, БКИ, Госуслуг и партнёрских сервисов. Микросервисная архитектура (4 микросервиса), команда 11 человек. Моя зона ответственности: полностью вёл эпик «Выдача и обслуживание кредитов» — от анализа требований до пост-релизного мониторинга. Ключевые задачи и достижения: - Разработал и поддерживал 160–180 ручных тест-кейсов для функционального, регрессионного и интеграционного тестирования. Полный регресс в моей зоне — 3–3,5 рабочих дня. - Протестировал более 40 API-эндпоинтов микросервисов (User Profile & Scoring, Loan Processing, Integration, Notification & Audit). Использовал Postman (коллекции с переменными окружений, data-файлы, pre-request-скрипты). - За время работы на проекте выявлял дефекты различной критичности, включая критические, связанные с финансовыми расчётами. Все критические дефекты закрывались до релиза. Благодаря раннему вовлечению (left-shift) предотвратил 17 логических ошибок на этапе анализа требований. - Проводил валидацию данных в PostgreSQL с использованием SQL-запросов (JOIN, CTE, оконные функции LEAD/LAG) — сверял графики платежей, пересчёты процентов и остатков с эталонными расчётами в Excel. - Работал с брокером сообщений Kafka (Kafka UI): мониторинг consumer lag, отправка тестовых событий в топики, проверка идемпотентности, разбор DLQ. - Анализировал логи в Kibana — фильтрация по сервисам, времени и уровню ошибок; Sentry — для быстрой локализации проблем. - Использовал Charles Proxy для проверки поведения UI (личный кабинет, админка) при разных ответах API: через Map Local подменял ответы бэкенда (ошибки, некорректные суммы в графике платежей), чтобы убедиться, что интерфейс корректно обрабатывает негативные сценарии. - Активно применял left-shift testing: ревью постановок аналитика в Confluence до начала разработки — предотвратил 17 логических ошибок, что сэкономило ~20 человеко-часов на переделках. - Отслеживал статус пайплайнов в GitLab CI, анализировал результаты автотестов (разработчики поддерживали ~600 API- автотестов), разбирал падения. - Проверял корректность данных и структуры после деплоев на тестовых стендах. - Участвовал в Quality Gates перед релизом: 100% прохождение ручного регресса, зелёные автотесты, consumer lag < 1000, отсутствие критических багов. - Проводил smoke-тестирование на production сразу после деплоя и участвовал в процедуре отката (rollback) при обнаружении критических проблем (регламент — 10–15 минут на откат). - Создал гайд по работе с Kafka UI для всей QA-команды, что ускорило онбординг новых тестировщиков на 40%. - Стал основным экспертом по банковской логике в команде — ко мне приходили за консультациями по расчётам графиков, процентов, досрочных погашений. Пастернак Владислав - Резюме обновлено 4 августа 2026 в 08:33 Ключевой кейс (реализованная фича): Тестирование автоматического пересчёта графика платежей при досрочном погашении (аннуитетный / дифференцированный). Составил матрицы эквивалентности (12 классов), написал 25 тест-кейсов, проверил округление через SQL (LEAD/LAG + CTE) и сверку с Excel-эталоном. Нашёл критический баг: в расчётах использовался неточный тип данных для денежных сумм (погрешность до нескольких рублей) — локализовал через SQL и логи в Kibana, предложил использовать точный числовой тип (DECIMAL). Исправлено до релиза. Результат: Обеспечил стабильность ключевого кредитного процесса. Снизил число регрессионных дефектов на 20% за счёт раннего вовлечения в анализ требований и оптимизации тест-кейсов (сократил время полного регресса на 0,5 дня за счёт приоритизации).

Краткосрочный проект: внутренняя система маршрутизации. Команда: 1 разработчик + я как единственный QA. Стек: REST API, PostgreSQL, Docker Compose. Удалённо. Ключевые задачи: - Чек-листы и функциональное тестирование API системы маршрутизации (расчёт маршрута, ограничения, пересчёт) - Тестирование REST API в Postman (коллекции, переменные окружений) - Проверка данных в PostgreSQL (SQL, сверка расчётных показателей) - Поиск и описание дефектов, взаимодействие с разработчиком - Стабильность после обновлений: критические дефекты закрывались до релиза Результат: за 3 месяца протестировал MVP, система вышла в тестовую эксплуатацию разработчиком.