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

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

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

А кто я вообще такая?

Сейчас я работаю тестировщиком в Яндекс.Деньгах. Мне 23 года, и по специальности я «Информатик-экономист» (и это не «информатик» минус «экономист»).

Работать начала с первых курсов университета, хотя это скорее была подработка: репетитор по математике, оператор в отделе бронирований паромной компании. А перед последним курсом университета попала инженером Service Desk в крупную японскую туристическую корпорацию.

Это была не обычная «первая линия поддержки», которая в общих случаях регистрирует обращения и направляет их ответственным инженерам. Мы администрировали внутреннюю систему документооборота, настраивали рабочие станции, систему безопасности, разбирались в сетевых проблемах, заявках связанных с офисными продуктами, VPN и т.п.

В общем, в народе таких специалистов называют «шивами».

Как попасть в хелпдеск после иллюзорной универской практики

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

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

Одно лето я работала и проходила практику в отделе бронирований паромной компании. Там только что завершилось внедрение новой ИС, которая на тот момент вела себя нестабильно. Было удивительно, что всех устраивало то, что система вылетает по нескольку раз за день, а при попытке что-то сохранить вылезают ошибки, ведь работа усложнялась. Я старалась описать условия, при которых у меня появлялись ошибки, и относила это в ИТ-отдел. На тот момент мне и в голову не приходило, что этим занимаются тестировщики.

Через год я попала на практику в банк. Тогда мне казалось это чем-то невероятным, потому что отбор был серьезный. Несколько собеседований, тесты, много кандидатов. Перед началом работы сотрудники банка (рекрутеры, будущие руководители, специалисты ИБ) спрашивали подробный план и цели практики. Помню, как тогда рассказывала им что-то про «описание ключевых бизнес-процессов в модных нотациях, описание архитектуры ИТ, как рекомендует TOGAF».

В первый день практики нас (практикантов) посадили в кабинет руководителя резать ножницами устаревшие рекламные буклеты. Мы справились. В последующие дни нам дали более ответственную работу… Раскладывать по алфавиту юридические дела клиентов. Задание, конечно, сложное, долгое, но я забила фамилии всех клиентов в Excel, отсортировала (прикладная информатика же), а потом просто раскладывала стопки папок по списку.

Никто не ожидал, что мы так быстро справимся, поэтому надо было придумывать еще какое-то задание. В конце концов меня посадили работать в БИС (банковская информационная система), опыт взаимодействия с такими системами у меня был в университете, было интересно. В банке внедряли новый модуль анализа, а я находила ошибки, которые потом уходили в качестве пожеланий к разработке.

Тогда я еще ничего не знала о тестировании в целом и существовании такой специальности в частности, но уже всем этим занималась.

Что бывает, если делать «как логичнее»

Приближался последний курс университета, времени было много, а опыта мало, поэтому я и пошла работать инженером Service Desk.

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

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

Помимо таких задач, я часто делала выгрузки и анализ инцидентов. Хотелось понять, где в эксплуатации самое узкое место, каких знаний не хватает, каких специалистов. Так сложилось, что в ИТ-департаменте все привыкли «тушить пожары» вместо того, чтобы их предотвращать. Попутно я рассказывала коллегам про ITIL и ITSM, всем очень нравилось на словах, но поддерживать изменения горели желанием немногие.

Так прошло чуть больше года, из-за работы на энтузиазме задач прилетало все больше, на свои мини-проекты времени не оставалось совсем. Из-за некорректно выстроенных процессов количество задач не убывало совсем. Складывалось ощущение бурной, но бесполезной деятельности.

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

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

Долгое топтание на месте, отсутствие результатов деятельности, привело к мыслям о том, что ИТ — не мое. Совсем.

Иногда просто нужно взять и бросить

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

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

Стать разработчиком в короткие сроки показалось невозможным, хотя я и писала код на разных языках, но в основном для решения прикладных задач — без использования фреймворков, конвенций. С работы хотелось уйти быстрее, а всякие курсы «Стань Java Junior Developer за 9 часов» не внушали доверия. Разработчик должен знать алгоритмы, фреймворки, паттерны, особенности языков. Если ты разработчик в Agile команде, то часто выступаешь еще и архитектором системы, а для этого нужен опыт.

Мой друг посоветовал мне пойти в тестирование, и я решила попробовать. Прочитала пару книг по тестированию, посмотрела известных QA инженеров, а также курсы Яндекс.Денег и Mail.ru. Меня впечатлили два совершенно разных подхода: одни учат тебя администрированию, техническим особенностям того, с чем тебе придется работать, базовому языку ИТ, другие — общим концепциям, анализу, тест-дизайну, планированию, покрытиям, оптимизации.

Все это было на словах, а хотелось больше практики тестирования веб-сервисов. Поэтому для подготовки я решила написать свое небольшое веб-приложение на Java (спасибо ресурсу StackOverFlow), с несколькими «ручками» и БД, а потом тестировать это приложение по «правилам». Такой опыт помог мне больше узнать об особенностях архитектуры веб-сервисов и инфраструктуры, а еще о рабочих инструментах. Эти знания я использую каждый день при тестировании или подготовке тестовых сред.

Теперь я тестировщик

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

Я проверяю внутренний инструмент для сотрудников поддержки — «Контакт-Центр». Как Тимур уже писал в предыдущей статье ^[1], тестировщик в команде занимается как задачами бэкенда, так и фронтенда. Помимо этого я пишу автотесты, помогаю пользователям инструмента с возникающими вопросами и сложностями, участвую в создании технических решений.

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

• тестировщики первые настраивают новые фичи на тестовых средах (кстати, тут очень помогают навыки администрирования);

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

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

Непрошенные советы

Если говорить о советах, которые, исходя из своего опыта, я могу дать молодым специалистам, то я бы выделила следующее:

1. Если кажется, что работа вам не подходит — скорее всего, так и есть. Не надо бояться менять род деятельности, лучше попробовать рано, чем осознать, что вы занимались «не вашим» делом много лет. За вас жизнь никто лучше не сделает.

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

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

Кстати, хочу поделиться небольшим списком литературы, который в свое время мне очень помог быстро втянуться в работу тестировщика:

• «A Practitioner's Guide to Software Test Design», Lee Copeland;

• «Foundation Level Syllabus», ISTQB;

• «Java For Testers», Alan Richardson.

Автор: ekaterinans

Источник ^[2]