Первые две недели

Updated Jul 2026

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

Разведка системы

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

Структура кодовой базы — Определите основные сервисы, их языки и фреймворки, способы коммуникации (REST, gRPC, очереди сообщений) и расположение тестового кода. ИИ-ассистенты для написания кода могут ускорить этот процесс: передайте репозиторий в LLM и попросите описать архитектуру, перечислить API-эндпоинты и обобщить тестовую инфраструктуру.

CI/CD-пайплайн — Найдите конфигурации пайплайна. Поймите, какие тесты запускаются на PR, при слиянии и при деплое. Обратите внимание на время выполнения пайплайна — 45-минутный пайплайн рассказывает совсем другую историю, чем 5-минутный.

Культура нестабильных тестов — Проверьте дашборд тестов (если он существует). Какой процент нестабильности? Нестабильные тесты изолируются или игнорируются? То, как команда обращается с нестабильностью, говорит о культуре качества больше, чем любой документ по адаптации.

История багов и инцидентов — Прочитайте последние 20 баг-репортов и последние 5 постмортемов инцидентов. Они показывают, где система действительно ломается, а не где люди думают, что она может сломаться.

Картирование социальной архитектуры

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

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

Культурные сигналы — Празднует ли команда обнаружение багов до продакшена или только реагирует на продакшен-инциденты? Тесты считаются полноценным кодом или второстепенным делом? «У меня на машине работает» — это приемлемый ответ на баг-репорт?

Неписаные правила — В каждой команде они есть. Какие тесты можно пропустить в спешке? Какие сервисы считаются стабильными (а какие действительно стабильны)? К кому обратиться, когда что-то непонятно?

30-дневный оценочный документ

Паттерн: В течение первых 30 дней подготовьте письменную оценку системы качества — что работает, что нет и что вы рекомендуете. Этот документ формирует авторитет быстрее, чем месяцы тихой компетентности.

Документ охватывает шесть областей:

1. Текущее покрытие тестами — Что тестируется, что нет и где пробелы наиболее рискованны
2. Здоровье тестовой инфраструктуры — Скорость пайплайна, процент нестабильности, надёжность окружений
3. Наблюдения о процессах — Как регистрируются, приоритизируются и исправляются баги; как контролируются релизы
4. Быстрые победы — Два-три улучшения, достижимых в следующем спринте
5. Среднесрочные рекомендации — Структурные улучшения на следующий квартал
6. Вопросы — Области, где вам нужно больше контекста для формирования рекомендаций

Ключевые выводы

• Первые две недели — для активной разведки, а не пассивного наблюдения
• Картируйте как техническую систему (кодовая база, пайплайн, тестовая инфраструктура), так и социальную систему (лица, принимающие решения, культура, неписаные правила)
• Используйте ИИ-инструменты для ускорения изучения кодовой базы — передавайте репозитории в LLM для обзоров архитектуры
• Подготовьте 30-дневный оценочный документ по качеству для раннего формирования авторитета
• Читайте баг-репорты и постмортемы инцидентов, чтобы узнать, где система действительно ломается