QA-онбординг: 12 вопросов, которые спасут ваш испытательный срок
Вы вышли на новый проект. Вокруг – незнакомые лица, десятки чатов в Slack, сотни задач в Jira и полное непонимание, за что хвататься. Часто QA-инженер совершает критическую ошибку: садится «тихонько изучать продукт», ожидая, что процессы объяснят сами собой.
Результат? Вы тестируете не ту версию, пропускаете баги из-за незнания требований и получаете репутацию пассивного сотрудника.
Ваша цель – за первый день не просто понять правила игры, а показать себя системным специалистом. В этом чек-листе – 12 вопросов тимлиду, которые закрывают три главные зоны риска: технологии, процессы и люди.
Ваша задача в первые дни – не просто получить доступы, а понять, как здесь принято работать (и где здесь минные поля). Ниже – чек-лист вопросов для вашего Тимлида или Ментора.
💡 Совет: Не превращайте это в допрос. Не вываливайте все 12 вопросов сразу. Разбейте их на 2–3 короткие беседы за чашкой чая или на встрече 1-on-1.
🔐 Нулевой этап: база (Access & Environment)
Без этого вы даже не начнете работать. Спросите это в первый час.
1. Где взять «ключи от всех дверей»?
Что спрашивать? Есть ли список доступов для новичка (VPN, тестовые стенды, БД, админки, Figma)?
2. Где мы тестируем? (Окружения)
Суть вопроса: есть ли у нас разделение на Dev, Staging и Production среды? Насколько Staging-окружение (предпрод) соответствует боевому? Так как если вы тестируете на локальной машине разработчика, ваши проверки могут быть бессмысленны. Баг может не воспроизвестись там, но «выстрелить» на проде из-за разницы в настройках серверов.
⚙️Блок 1: техническая реальность
Самые важные вопросы, чтобы не «тестировать воздух».
3. Как код попадает на стенд? (Deploy Process) Суть вопроса: настроен ли у нас автоматический деплой (GitLab CI, Jenkins) или сборка и выкладка происходят вручную? Важно помнить, что «ручной» деплой – главный источник хаоса. Вам нужно точно знать момент, когда версия обновилась, чтобы не тратить время на тестирование старого билда.
4. Есть ли автотесты и кто за них отвечает? Суть вопроса: покрыт ли бэкенд unit-тестами? Есть ли UI-автотесты? Почему это важно? Вы должны понимать зону своего покрытия. Нет смысла вручную проверять то, что уже проверяется роботом при каждой сборке.
5. Где лежат требования и как мы их проверяем? Суть вопроса: есть ли ТЗ, макеты в Figma, User Stories? Нюанс (Shift Left): помните, чтение документации – это уже тестирование (статическое). Ваша задача – найти логические дыры и противоречия еще до того, как разработчик напишет первую строчку кода. Это экономит компании огромные деньги.
🔄Блок 2: Правила игры (Workflow)
Как встроиться в поток и не стать «узким горлышком».
6. Какой жизненный цикл у задачи?
Суть вопроса: попросите показать путь тикета в Jira: To Do → In Progress → Code Review → Ready for QA → Done. Если нет статуса Ready for QA, вам придется постоянно дергать разработчиков: «Ну что, готово? А сейчас?».
7. Что такое Definition of Done (DoD)?
Суть вопроса: в какой момент задача считается полностью закрытой? Когда код на проде? Когда тесты прошли? Или когда заказчик кивнул? Единый стандарт «Сделано» спасает от споров в конце спринта.
8. Какую методологию используем?
Суть вопроса: мы бежим спринтами (Scrum) или работаем в непрерывном потоке (Kanban)? В Scrum готовьтесь к высокой нагрузке в последние дни перед релизом. В Kanban следите за тем, чтобы задачи не скапливались в одной колонке.
🤝Блок 3: Люди и Коммуникация (Soft Skills)
QA –это не только поиск ошибок, это связующее звено команды.
9. Карта ответственности: к кому идти?
Суть вопроса: узнайте не просто имена, а зоны влияния. Кто отвечает за архитектуру бэкенда? Кто даст доступы к базе данных? Кто утверждает дизайн-макеты? Запишите имена и контакты. Не дерга��те тимлида по мелочам, если есть профильный специалист.
10. Как заводить баги?
Суть вопроса: есть ли утвержденный шаблон? Что обязательно прикладывать? Нужны ли логи сервера, запись экрана, curl-запросы? Договоритесь «на берегу». Качественный баг-репорт, понятный разработчику с первого раза – ваш главный инструмент авторитета.
11. Часы доступности и ритм встреч
Суть вопроса: во сколько Daily? Есть ли коллеги в других часовых поясах? Если разработчик просыпается, когда вы уходите домой, баг-репорт нужно писать с удвоенной точностью –возможности переспросить не будет до следующего дня.
12. Формат общения с заказчиком
Суть вопроса: презентует ли QA результаты работы на Демо? Общаемся ли мы с клиентом напрямую в чатах или все идет через PM?
Резюме: Что делать с ответами?
Рай (Процессы есть): следуйте правилам, вникайте в суть и первые пару спринтов не пытайтесь ломать устои. Ищите точечные улучшения.
Дикий Запад (Процессов нет): если на вопрос про CI/CD вам говорят «Ну, Вася там что-то копирует», а про требования – «Спроси у Лены» – поздравляю. Вы попали в идеальную среду для роста.
1 Не критикуйте всё сразу («Как вы так живете ?").2 Зафиксируйте текущий хаос.
3 Предложите прозрачный Workflow.
4 Начните внедрять культуру качества.
Задавая эти вопросы, вы не кажетесь назойливым новичком. Вы позиционируете себя как инженера, которому не всё равно.
Чтобы вам не забыть все э��и вопросы я подготовил специальную шпаргалку-файл в отличном разрешении, которой вы можете забрать в моем ТГ- канале QA❤️4Life по данной ссылке
И в качестве дополнительного бонуса приложу ссылку на ПОДБОРКУ ЛУЧШИХ ШПАРГАЛОК для QA
Искренне желаю всем успехов и легкого онбординга!
Евгений Гусинец
QA Engineer в Бизнес-Инфо (Минск)
