Главное правило: Не пытайся узнать всё сразу. Действуй по слоям, от общего к частному.

Ниже дам план пошаговых действий и список «правильных» вопросов для каждого этапа.

Этап 1: Контекст и Бизнес-логика (Первые 1-3 дня)

Не лезь сразу в тестовые случаи и код. Пойми, зачем это вообще сделано.

Что делать:

1. Найти презентацию продукта или описание в Confluence. 2. Посмотреть, кто основные пользователи (роли). 3. Попросить провести для тебя 15-минутную демонстрацию самого важного пользовательского сценария (Critical Path).

Примеры правильных вопросов:

· ❌ «Где лежат тест-кейсы?» (Рановато) · ✅ «Какую основную проблему пользователя решает этот продукт?» (Понимание ценности) · ✅ «Кто наши пользователи? Есть ли разница между действиями Админа и обычного юзера?» (Ролевая модель) · ✅ «Какой сценарий использования самый частый (Happy Path), с которого мне стоит начать изучение?» (Точка входа)

Этап 2: Тестовая документация и артефакты (3-5 день)

Теперь нужно понять, как здесь принято работать и что уже наработано.

Что делать:

1. Изучить, какая документация ведется: TestRail/Allure TestOps, чек-листы в Miro, баги в Jira. 2. Посмотреть последний закрытый спринт/релиз: какие были задачи и какие баги находили.

Примеры правильных вопросов:

· ❌ «Почему этот баг еще не починили?» (Претензия) · ✅ «Какие области продукта самые “хрупкие” (legacy code) и ломаются чаще всего при изменениях?» (Фокус на риск) · ✅ «Какие баги недавно уехали в прод (были пропущены)? В чем была причина?» (Понимание слабых мест процесса) · ✅ «Где у вас хранятся требования/спецификации? Как часто они обновляются?» (Понимание надежности источника истины)

Этап 3: Окружение и инфраструктура (5-7 день)

Пора понять техническую сторону.

Что делать:

1. Настроить локально проект или получить доступ к тестовым стендам. 2. Понять, как работает БД, какие есть логи, как смотреть запросы фронтенда к бэкенду (DevTools). 3. Узнать, как проходит CI/CD (деплой).

Примеры правильных вопросов:

· ❌ «Дай доступ к продy». (Стоп-сигнал) · ✅ «Какие у нас есть стенды? Какие данные на них лучше использовать (чистые/замусоренные)? Есть ли инструкция по подготовке тестовых данных?» · ✅ «Где смотреть логи и графики (Kibana, Sentry, Grafana)? Есть ли доступ?» · ✅ «Как я могу развернуть последнюю версию на тестовом стенде, если это необходимо?»

Этап 4: Процессы и коммуникация (Первая неделя)

Тебе нужно понять правила игры в команде.

Что делать:

1. Посмотреть, как оформляются баг-репорты в этом проекте (свои стандарты). 2. Узнать расписание дейликов, ретро, грумингов. 3. Понять, кто за что отвечает (кто главный разработчик этого модуля?).

Примеры правильных вопросов:

· ❌ «Почему вы делаете регресс руками, а не автоматами?» (Критика) · ✅ «Как у вас выглядит идеальный баг-репорт? Можете показать пример?» (Адаптация под стандарты команды) · ✅ «Кто основной “заказчик” (PO/BA) и кто главный эксперт по этой фиче из разработчиков?» · ✅ «Какие шаги в процессе регрессионного тестирования я должен сделать перед релизом в первую очередь?» (Проверка гипотез)

Совет бывалого (Личная эффективность)

Когда я захожу в новый проект, я создаю себе документ “Onboarding Checklist” и веду его первую неделю. Это помогает не забыть спросить то, о чем все забывают, но что бесит больше всего:

1. Данные: Где брать валидные тестовые данные (паспорта, номера карт, логины)? Есть ли генератор? 2. Доступы: Ко всем ли сервисам (Jira, Figma, стенды, БД) у меня есть доступ? (Часто забывают про Figma для верстки). 3. Комьюнити: Есть ли у вас “ритуалы” или принятые сокращения в чатах?

Главный признак успешного онбординга: Ты перестаешь спрашивать «Где это лежит?» и начинаешь задавать вопросы по существу фич.