Меня зовут Ирина, и я специалист по качеству в продуктовой команде iSpring. Шесть лет назад я ушла в декретный отпуск с должности экономиста банка. Год назад прошла все этапы найма и онбординга и стала тестировщиком. Вот только оказалось, что попасть на работу — это даже не половина дела. Дальше новичка ждёт онбординг, первые рабочие задачи, вливание в коллектив, взлёты и падения. Поэтому в статье я расскажу, какие этапы проходит стажёр в процессе найма и онбординга, с какими сложностями сталкивается, и как их можно решить.

Цель моей статьи — вдохновить тех, кто собирается сменить профессию и перейти в IT, и добавить решимости в прохождении этого пути.

Начало пути

IT не была сферой, в которой я мечтала работать. Почему? В нашем маленьком городе не так-то много крупных фирм, и каждый житель осведомлён, что примерно происходит в каждой из них. Про IT компании города есть предубеждение, что работать в них тяжело, и чтобы попасть туда, нужно быть супер-мега-нечеловечески крутым, других не берут. Только герои, только сверхлюди. Куда уж мне с образованием, далёким от айтишного. 

Хотя образование у меня экономическое, но по призванию я вполне себе тестировщик. Когда‑то давно я заметила странную закономерность: стоит мне взять в руки технику, будь то телефон, ноутбук или даже простая мышка, через какое‑то время она начинает барахлить. Сначала я думала, что это невезение. Всегда старалась быть аккуратной, но техника словно чувствовала мой пытливый ум, подставляя свои самые хрупкие части.

Однажды на работе, где всё должно было идти гладко, вдруг у клавиатуры начали залипать клавиши. Потом присоединился компьютер: он начал встречать меня по утрам синим экраном BIOS. Коллеги недоумевали, ведь до этого ничего подобного не происходило. А я только улыбалась, понимая, что это снова проявился «мой талант». В конце концов, я решила принять это как должное. Родные уверяли, что эту особенность можно направить в нужное русло. Так я и поняла — пора пробовать себя в новом направлении — тестировании. Вместо того, чтобы бороться с техникой, — помогать находить её слабые места и делать её лучше.

Золотая идея лёгкого вхождения в IT до сих пор струится из каждого утюга социальных сетей, и да, я попалась. Мне подвернулась возможность принять участие в федеральном проекте «Содействие занятости» и обучиться на тестировщика в Томском государственном университете, и я сразу же подала заявку. Только потом я узнала, насколько действительно перегрет рынок. Прикинув, что конкурс на должность мануального тестировщика без опыта эдак человек 10–15 на место, у меня появилось много сомнений. К счастью, мой муж, уже работавший в iSpring, остановил меня, сказав, что в компании появилась вакансия. Любая вероятность, не стремящаяся к нулю — это надежда. Поэтому я продолжила усердно учиться, а время поджимало. 

Все дело в том, что iSpring проводит свои курсы, на которых преподают действующие тестировщики и лид команды, а особо успешных выпускников приглашают на работу. Жаль, что училась я не на местных курсах, а моё обучение завершалось через неделю после выпуска айспринговского потока. Я быстро составила портфолио из своей выпускной работы, и по реферальной программе подала резюме через мужа в службу HR.

В iSpring действует реферальная программа «Приведи друга», когда действующие сотрудники берут на себя часть работы HR, привлекая проверенных кадров. На самом деле практика уже показала, что работники, пришедшие по этой программе, чаще успешно проходят испытательный срок и легче приживаются в команде.

Совет № 1: если есть компания, в которую вы хотите попасть, узнайте, не проводит ли она обучение, потому что это рабочий вариант, где выигрывают обе стороны.

Совет № 2: если у вас есть знакомые, работающие в IT, узнайте у них про реферальные программы — этот путь сильно облегчит продвижение к цели — трудоустройству.

Я очень волновалась, что моё резюме будет не таким впечатляющим, как у лучших выпускников с курсов iSpring. Кроме того, с ними тимлид была уже знакома и знала, кто на что способен, а я была «тёмной лошадкой».

Моё резюме просмотрели, и уже через 2 дня со мной связался HR‑менеджер, задал несколько уточняющих вопросов и предложил пройти тестовое задание. «Если ничего не выгорит — будет плюс к портфолио,» — подумала я в тот момент. 

Совет №3: тестовое задание — это возможность для соискателя и работодателя познакомиться, понять требования и адекватность сторон. Не стоит пренебрегать выполнением тестового задания.

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

Пребординг‑курсы призваны помочь понять, насколько соискателю отзывается всё то, что происходит в компании, заочно познакомиться с СЕО благодаря записанным видеоинтервью, и оценить атмосферу и уровень корпоративной культуры ещё до финального этапа собеседования.

Компания iSpring хорошо известна в нашем городе, и через рассказы знакомых многое о ней я уже знала. Несмотря на это, мне было интересно послушать о компании с точки зрения основателя о том, какие люди здесь нужны. Говорят, после ввода этого этапа снизился процент ухода кандидатов на этапе испытательного срока.

Я смотрела видео без особых ожиданий, но меня сильно впечатлила приведенная в интервью цитата Христофора Колумба: «Ты никогда не пересечёшь океан, если не наберёшься смелости потерять из виду берег». Действительно, у меня были сомнения, стоит ли пускаться в это «плаванье». Пугало ощущение неизвестности, непредсказуемости IT‑отрасли. И тогда я подумала, что если я хочу что‑то изменить в своей жизни — надо действовать решительнее. Эта фраза до сих пор придает мне энергии и смелости двигаться дальше. 

Прохождение отбора — собеседование

И вот подготовительно-ознакомительные шаги пройдены, тестовое задание проверено, впереди собеседование с тимлидом. Наверное, каждый соискатель хочет показаться на встрече с потенциальным работодателем с лучшей стороны. Что я могу сказать точно — следует держать в голове три основные идеи:

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

• Какова твоя цель — здесь потребуется максимально чётко сформулировать для себя личную мотивацию, которая будет твоим стержнем и двигателем всё интервью и останется с тобой в рабочем процессе. Мотив «хочу деняк» — слабоват для получения действительно хороших результатов, ведь то, что ты делаешь должно драйвить.

• Зачем ты компании, то есть какую пользу ты сможешь принести, а для этого хорошо бы понимать, в чём нуждается и чего ждёт работодатель. Об этом нужно либо прочитать в вакансии, либо спросить напрямую у рекрутера при первом же касании. У меня не было перед глазами вакансии, её вообще нигде не публиковали, но были развернутые welcome‑курсы, где я поняла, чем могу быть полезна.

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

В начале испытательного срока мне был назначен наставник, и я ознакомилась с планом онбординга Далее по части этапов вливания в общий темп работы всё было стандартно: первые 2 недели — ежедневные встречи с наставником. Разбор учебных задач. Потом первые боевые задачи под присмотром опытного сотрудника. Еженедельные встречи с лидом тестировщиков, чтобы обсудить, что получается, как идёт процесс обучения и знакомства с командой.

В конце первого месяца у меня уже была мелкая, но полноценная фича на тестирование — первое боевое крещение, потом самостоятельный релиз, и понеслось… с каждой новой фичёй набор колоссального опыта в части знакомства с продуктом, разными командами и освоения требуемого инструментария, защита прохождения испытательного срока и вручение долгожданной фирменной толстовки.

Начало работы и первые ошибки

А теперь о граблях. Я делала кучу ошибок, пока была на испытательном сроке. Причём это были не только ошибки, связанные с тестированием продукта, но и ошибки по отношению к себе и к коллегам. Честно говоря, я до сих пор (а прошел уже год) спотыкаюсь о свой темперамент, не всегда влезающий в ожидаемые рамки стандартного тестировщика. Но именно это помогло мне посмотреть оценивающим взглядом на процесс вливания в IT-сферу, адаптацию. Проживая все стадии принятия, мне захотелось поделиться с читателями своими открытиями, или, как сейчас модно говорить, лайфхаками. 

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

Ошибка 1

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

Мой путь — не исключение. Я потратила невероятное количество сил, эмоций и времени, чтобы каждая задача была проверена от и до. А к сегодняшнему дню я закрыла уже более тысячи задач. С одной стороны, желание закономерное. Тестировщик должен обеспечить высокое качество продукта, и хочется показать свою эффективность. Однако, как оказалось, это не самая лучшая тактика.

Все мы знаем, что исчерпывающее тестирование невозможно, но между заученным принципом тестирования и его истинным пониманием стоит целый этап эволюции новичка. Всё потому, что с ходу очень трудно определить границы, где стоимость ресурсов на поиск и правку новых багов уже превышает эффект от их исправления. Кстати, тут и спрятан главный секрет нахождения баланса.

А тем временем отвлечение команды на верификацию и исправление дефектов низкого приоритета может дорого стоить компании — сроки релиза съезжают, стоимость разработки выходит за планируемую, фокус‑фактор разработчиков размыт между созданием новой фичи и правками почти готовой.

Десятки переоткрытых задач — и мотивация всей команды заметно снижается из‑за растянутых сроков и ощущения незавершённости.

Поэтому в погоне за совершенством стоит останавливаться и спрашивать себя, какова критичность бага: с чем можно жить, а что обязательно нужно поправить. 

Ошибка 2

Один из приятных бонусов работы тестировщиком — ты отчасти можешь повлиять на то, как будет выглядеть или работать продукт. Например, предложить своё видение, если запроектированное решение оказалось неоптимальным. Однако новички из‑за недостатка опыта часто проявляют полёт фантазии и не учитывают имеющиеся ограничения. Это негативно влияет на работу тестировщика, ведь он тратит энергию на отстаивание своей правоты и отвлекается от самого важного.

Я попалась на этом, предлагая идеи и искренне веря, что забочусь о пользователях. В моей истории улучшение касалось не столько основной функции, сколько «круто было бы прикрутить дополнительный сложный отчёт для пользователя». Я не осознавала, что своими действиями обесцениваю труд продуктового дизайнера и проджект‑менеджера. Всё же продумывать фичу и прорабатывать позиционирование на рынке — их задача, а тестировщику лучше предлагать идеи по развитию продукта на демонстрациях и обсуждениях предстоящих фичей, а не тех, которые уже спроектированы и написаны. 

Ошибка 3

Ещё один «грешок» новичков не так часто встречается, но всё же имеет смысл его упомянуть. Это желание как можно скорее завести, оформить баги и передать их разработчику. Скорость нахождения дефектов (особенно критичных) в фиче — это здорово, но иногда не эффективно.

Быстрослепленные багрепорты имеют все шансыбыть невоспроизводимыми или вообще вести по ложному следу. Недостаточная проработанность и локализованность бага может стоить команде нескольких часов бесполезной работы. Не раз попадалась на этом, отвлекая внимание команды. Потом было стыдно, когда обнаруживалось, что причина «бага» — моя невнимательность. По ходу накопления опыта я составила для себя следующий чек‑лист, по которому я иду перед отправкой баг-репорта:

1. Удостовериться, что это баг: поведение идёт вразрез с документацией или ожиданиями пользователей. Здесь нужно не забывать про здравый смысл.

2. Перепроверить, что баг воспроизводится по описанным шагам.

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

4. Проверить, как работает эта функциональность на проде или на другом тестовом стенде. Возможно, это не баг, а фича. Может быть проблема в самом тестовом стенде. Либо так работает на проде, и мы будем решать эту проблему за рамками текущей фичи.

5. Почистить кеш браузера/сменить браузер. Включить инкогнито/сменить пользователя и попробовать воспроизвести баг. Иногда из-за переполненного кеша могут возникнуть проблемы со скоростью работы и стабильностью веб-приложений. А смена пользователя может помочь сузить кейсы воспроизведения бага. Однажды в одном из тестовых аккаунтов начало падать очень много ошибок, проверять фичу стало невозможно. Успешно проверив кейс в другом аккаунте, я поняла, что дело было в зациклившемся событии, а не в дефекте кода.

От рабочих процессов к личностным качествам

С рабочими требованиями к новенькому тестировщику всё более-менее понятно и ожидаемо. Лично для меня большим открытием была важность софт-скиллов при устройстве на работу и прохождении испытательного срока. По сравнению с другими отраслями, IT очень чувствительна к умению людей находить общий язык в команде. 

Но прежде чем искать подходы к членам команды, в первую очередь стоит освоиться и почувствовать себя в своей тарелке. 

Если вы, как и я, выбрали путь смены направления в своей работе и стали тестировщиком без особой подготовки (имею ввиду академическое, высшее образование), то надо быть готовым к невероятному потоку информации. Иногда кажется невообразимым всё освоить, особенно, когда все вокруг говорят на непонятном языке. Однако немного терпения и повторения, и информация послушно расходится по полочкам в голове, закладкам в браузере и строчкам в блокноте-шпаргалке. 

Небольшой лайфхак: собирайте список всех вопросов, что возникли за день, даже самых глупых. Как правило к концу дня удаётся найти ответы на многие из них. И даже самые глупые вопросы оказываются вполне хорошими и полезными. Ну и собирайте полезные лайфхаки в одном месте, однажды это точно пригодится. Я поначалу записывала полезные подсказки на листочках для заметок, а потом в самый ответственный момент они терялись.

Кстати о вопросах. Большая сложность была в том, чтобы научиться задавать их правильно и вовремя, чтобы твоя работа не простаивала и чтобы сильно не отвлекать другого сотрудника. 

Выделила для себя следующие правила задавания вопросов: 

а) ответ на этот вопрос приблизит меня к цели? 

Иногда хочется что-то узнать просто из любопытства или ради общего кругозора. Если же этот вопрос не продвинет тебя к цели – например, успешно завершить тестирование фичи – то можно записать его отдельно. А как появится возможность, поискать ответ самостоятельно, либо спросить на встрече с наставником.

б) если это вопрос, стОящий разъяснений здесь и сейчас, то надо сначала попробовать исследовать его своими силами в Гугле, нейросети, на Хабре, или в базе знаний вашей компании. 

в) если не удалось найти ответ за 15–30 минут, остановитесь и задайте вопрос коллегам в личном или командном чате.

И ещё один момент — учитесь у лучших. Мне очень хотелось поделиться своим опытом вхождения в ряды тестировщиков, и перед написанием статьи я много анализировала, что объединяет моих самых успешных коллег. 

И вот к каким открытиям это привело: опуская опыт и насмотренность, этим тестировщикам присуща невероятная стрессоустойчивость. Она проявляется в способности не драматизировать. Они умеют конкретизировать ситуацию, отложив эмоции, и выдавая цепочку причинно-следственных связей:

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

Ещё одна особенность – они умеют справляться с неопределенностью. Спокойно относятся к тому, что чего-то не знают, до конца не понимают. Они терпеливо изучают, исследуют, пробуют и не боятся ошибиться. 

Ну а с точки зрения новичка добавлю, что отличным советом является не торопить события. В самом начале мне очень хотелось поскорее во всё вникнуть, набраться опыта, начать приносить реальную пользу. Из-за этого нарастало напряжение и не появлялось удовлетворения от проделанной работы. Это чуть было не переросло в выгорание, поставив под угрозу весь мой путь. Помогло лишь осознание, что всему своё время.

Многое впереди покрыто дымкой неизвестности. А неизвестность рождает тревогу. Тревога – рассеянность внимания и так далее. Чувствовать себя как «невывожук» нормально. Надо поверить в себя. Набравшись смелости потерять из виду берег, вы вскоре пересечёте океан неопределенности. Так что, если вы готовы трудиться над собой, осваивать новое и применять эти знания в интересной области, доверьтесь себе – и успех будет на вашей стороне.

Резюме

Обобщая выводы, которые я сделала по итогам первого года работы, как адаптироваться в мире IT после смены профессии:

1. Если выбрали компанию, в которой мечтаете работать — ищите, проводят ли они курсы подготовки, берут ли на стажировку, и есть ли у вас варианты пройти по реферальной программе.

2. Проходя собеседование, концентрируйтесь на том, какую пользу можете принести компании и что сами хотите получить от запрашиваемой должности.

3. В работе не стремитесь найти все баги, старайтесь сохранять баланс полезности от исправления бага и затраченных на это ресурсов.

4. Не увлекайтесь, предлагая улучшения.

5. Не спешите «отгрузить» баги разработчикам. Хорошая проработанность баг‑репорта существенно облегчит взаимодействие с командой.

6. Найдите золотую середину, задавая действительно критичные для достижения цели вопросы, делая это не слишком часто, и после попыток самостоятельно найти ответ.

7. Учитесь у старших коллег справляться с неопределённостью и не торопить события.