Pull to refresh

Comments 3

«Опытные» здесь наверное имеются ввиду джуны с годом опыта. Давать сеньору тестить логин под присмотром, боясь что он баги оформит без скриншотов, и на все это отдавать 3 месяца, выглядит неоправданно расходным.

В новый проект нужно время влиться, и это стресс, и нужно присматривать, но не как за новоиспеченным специалистом, это будет только раздражать

После первого касания вы сразу даёте задачу в работу? Не требуется ли предварительное погружение в проект?

У нас есть практика первых трех недель работы с постановками: ознакомление, ответы на подготовленные по фичам вопросы. Так мы знакомим нового сотрудника с проектом.

Но нет уверенности, что это достаточно эффективно, может и не стоит сразу вываливать кучу логики, а давать погружаться с помощью задач? Поделитесь опытом, пожалуйста.

После первого касания мы знакомим с внутренними инструментами, чтобы сотрудник понял все бизнес-процессы. Сначала мы не даем задачи на проекте, а даем потренироваться на альтернативе. 

Например, заводим в Джире фичу (тестовую) и там описываем какой-нибудь пример экрана, даём скрин и его требования. Тестировщик берёт фичу в задачу, меняет статусы, создает подзадачи, правильно создаёт баги. Получается мини-эксперимент, который показывает, насколько тестировщик понял все процессы. Когда становится ясно, что он все делает правильно, уже втягиваем его в проект на базовые какие-то баги, постепенно начинаем доверять задачки посложнее. Все это время он погружается в проект, что-то узнает.

У нас нет практики 3 недель или как-то сроков, все индивидуально. Если человек опытный и быстро втягивается, то стараемся его отправить на проект как можно раньше, чтобы разгрузить команду.

Sign up to leave a comment.

Articles