Проект - RMS (Retail Management System), внутренняя система дилерской регистрации абонентов в Beeline Uzbekistan. Работаю с ней с апреля 2025 как QA-инженер, автотесты писал сам с нуля. Стек: Python, Pytest, Playwright, Allure, PostgreSQL, GitLab CI. Основное, что автоматизировал - сквозной сценарий регистрации абонента. Это довольно длинная цепочка: выбор свободной SIM (приходится перебирать, потому что часть уже занята - ловлю ответ API на резервацию и иду к следующей), подбор номера, тариф, ввод паспортных данных с проверкой на валидность, загрузка сканов, подпись клиента на canvas (рисую мышью, там требование по длине линии), активация SIM. Плюс отдельно сделал флоу замены SIM-карты и авторизацию в backoffice через ADFS. Собрано по Page Object Model - классы страниц, базовый класс, фикстуры для подготовки состояния. Конфиг через .env, секреты в репозиторий не попадают. Самое интересное было с проверкой результата. Регистрация упирается в биллинг, который закрывает ордера асинхронно и небыстро. Сначала проверял статус через UI, но он отставал - на экране всё ещё висело "Ожидает оплаты", хотя по факту всё прошло. Подключил PostgreSQL и стал проверять напрямую по статусам ордеров (REGISTER, ADD_ADDON, CHANGE_SIM), с фильтром по времени старта теста, чтобы не зацепить старые записи по тому же номеру. Тест сразу стал стабильным. Оттуда же беру тестовые данные - свободные SIM и подходящие номера, вместо хардкода. Ещё пришлось повозиться с краевыми случаями: подпись дилера иногда протухает и вылезает модалка, которая блокирует всё остальное; всплывающие алерты об ошибке резервации перекрывали список SIM и Playwright не мог по нему кликнуть. Такие вещи, кстати, вылезли только когда DevOps подняли pipeline и тесты поехали в headless-режиме в GitLab CI - локально они проскакивали. Ссылку дать не могу, репозиторий во внутреннем GitLab компании, но готов подробно разобрать любой кусок на собеседовании.