Сегодня расскажу про то, как проходил мой онбординг в компании. Разберем плюсы и минусы. И в конце расскажу, как бы я сама проводила бы онбординг.
Напомню, что работаю удаленно, офис компании находится в другом городе и я в нем ни разу не была. Даже рабочее оборудование мне отправляли СДЭКом. В первый рабочий день тимлид добавил меня во все нужные телеграмм-чаты, выдал список ссылок на корпоративные ресурсы, выдал доступы к ним, либо написал, куда обратиться за доступом. Также утром со мной связался сисадмин и помог мне настроить ВПН. Далее тимлид прислал мне пошаговый план по знакомству с командой и проектом. Еще мне выслали инструкцию, как поднять и настроить тестовый стенд локально. У нас на проекте тестировщики разворачивают тестовые стенды локально у себя на компьютерах под конкретно тестируемую ветку.
Оставшийся день я пыталась поднять тестовый стенд, что оказалось не так легко, так как требовалось прописать определенные переменные в окружении винды. В итоге у меня получилось это только на второй день не без помощи коллег, естественно.
На следующий день у меня был короткий созвон с тимлидом, где она рассказывала некие правила и процессы на проекте. Что меня поразило: регламент по работе отдела тестирования был в гугл доке и вообще все тестовая документация ведется там же.
После того как я помучилась с настройкой тестового стенда, мне предстояло почитать документацию о проекте и выполнить несколько юзер-кейсов в приложении для того, чтобы потрогать продукт уже как пользователь.
Документации оказалось очень мало и где-то она была немного устаревшая. Юзер-кейсы оказались не очень близки к реальным пользовательским сценариям, как я потом это узнала. По ходу их выполнения у меня возникали вопросы, но тимлид не всегда могла мне на них ответить и иногда отправляла меня в общий чат команды тестирования. Позже я поняла, что она сама проект знала не очень хорошо.
Через пару дней я прошла все предложенные мне сценарии, у меня накопились вопросы и вообще мне хотелось побольше узнать о продукте, о пользователях, об их наиболее частых действиях в приложении. Напомню, что наш продукт - это crm-система, в которой работают сотрудники компании. Она оказалась гигантской монолитной системой, в которую 2 раза в неделю релизят доработки. В таких условиях проводить полноценный ручной регресс перед релизом нет возможности (написанных тестов в одном каком-то месте, кстати, тоже нет), а так как автотесты покрывают далеко не все, важно на этапе тестирования новой фичи уметь проводить точечный регресс, для этого важно знать, что вообще в приложении делают пользователи и как оно работает внутри.
Пару дней я ждала созвона с тимлидом, но она оказалась очень занята и поручила созвониться со мной тестировщику из нашей команды. Мы созвонились, я задала свои вопросы, она ответила, но рассказать как-то комплексно о продукте не смогла.
Либо она торопилась, либо просто не знала, что конкретно мне нужно рассказать.
Через неделю мне дали уже реальную задачу на ретест исправленного бага. Баг был пустяковый на фронте, я быстро его протестила, и после этого мой онбординг по сути завершился. И хотя изначально мой чек-лист кто-то должен был ревьюить, по факту этого никто не делал.
В итоге я получила очень поверхностное понимание о продукте и о процессах в компании. Далее в течение нескольких месяцев это мне сильно аукнулось: я выпустила пару серьезных багов в прод. Только по прошествии 5-6 месяцев я стала себя чувствовать более уверенно в продукте. Перед новым годом в команде появились 2 новых тестировщика, и, к сожалению, у них онбординг прошел еще хуже, так как тимлид поменялся и новенькими он уже не занимался, но при этом никакого ментора им так и не назначили. Ребята просто, как слепые котята, изучали проект и мало понимали, что происходит в нем... По-человечески, мне стало их очень жалко, я активно предлагала им свою помощь, мы устраивали созвоны и я рассказывала им о продукте и о процессах. В итоге у меня сформировалось понимание, каким должен быть хороший онбординг. Вот как я выстроила бы его, если бы меня назначили ментором:
1. Как и было у меня, первые дни - это предоставление доступов к корпоративным ресурсам и поднятие тестового стенда локально (здесь я бы сделала подробнее инструкцию по настройке окружения в винде).
2. Созвон с общим обзором команды и процессов в команде.
Разъяснение внутренних правил в компании и в команде. Короткий обзор тестовых стендов, баз данных, систем сбора логов и прочих мониторингов. У новичка должно сложиться общее понимание нашей архитектуры и процесса разработки. Этот пункт может идти параллельно первому.
3. Созвон с кратким обзором основных функций в продукте.
4. Прохождение базовых сценариев в продукте. По сути то же, что и делала я, но сценарии нужно обновлять и расширять. Я бы сказала, что эти сценарии могут быть даже основой регресса.
4. Созвон с обзором бэкенда продукта. Более подробное погужение в архитектуру.
5. Прохождение базовых сценариев по тестированию бэкенда, а также некоторых интеграций с другими сервисами. Изучение таблиц в базе данных.
6. Белоящечное тестирование. У нас на проекте практикуется белоящечное тестирование. Так как тестировщик запускает тестовый стенд локально в ИДЕ в режиме дебага, он видит все, что происходит в продукте на стороне бэка и бд. Поэтому важно новенькому тестировщику посмотреть это на каком-нибудь пользовательском сценарии.
7. Подключение и разбор вопросов, приходящих из поддержки.
8. Подключение к реальным задачам, начиная с ретостов багов после фикса.
Все это время, я считаю, с новичком работает ментор, который и будет делать созвоны и рассказывать о продукте. Это может делать сам тимлид или поочередно тимлид и ментор. Ментор и/или тимлид должны быть все время на связи с новичком и при необходимости организовывать дополнительные созвоны. Важно иметь какие-то написанные материалы для онбординга, ибо запомнить все на словах новичок сразу явно не сможет и первое время ему нужны будут шпаргалки.
Таким образом, новенький будет чувствовать себя более уверенно, далее сможет самостоятельно углублятся в изучения продукта, будет понимать, работая даже полностью удаленно, что работает в команде, и знать, к кому можно обращаться за помощью.