Компания 2ГИС стабильно попадает в список лучших работодателей России согласно рейтингам Forbes, рейтингам РБК и Хабр. Поэтому идея устроиться туда на работу (стать тестировщиком в 2ГИС) кажется разумной и посещает головы многих тестировщиков, в том числе в какой-то момент посетила и мою.
В этой статье расскажу свой путь, постараюсь не приукрашивать, а расскажу как было на самом деле. Почему в моем случае большую роль сыграла удача и что нужно делать тем кто тоже хочет стать тестировщиком в 2ГИС.
Тестирование - легкий способ войти в АйТи?
Многие наверняка слышали тезис "тестирование - это легкий способ войти в IT" (в основном его распространяют многочисленные IT курсы). Еще лет 7-10 назад он был достаточно правдив. Действительно, в то время, зная только теорию тестирования, DevTools и какой-нибудь инструмент для работы с АПИ (например Postman) можно было залететь на свою первую джуниорскую позицию тестировщика.
Мою первую работу в IT-финтех-стартапе я практически так и получил.
Но вернемся к тезису. Сейчас он некорректен с какой стороны на него ни посмотреть.
Во-первых тестировщиком сейчас устроиться сложно.
Во-вторых работая тестировщиком очень сложно (а без потери в доходе практически не возможно) перейти на другую IT-шную профессию.
Более того, крайне редки случаи перехода из одного раздела тестирования в другой. Я бы выделил 3 больших блока:
1) тестирование безопасности
2) нагрузочное тестирование и
3) функциональное тестирование
каждый из которых еще разделяется на несколько разделов. Так вот переходы между разделами тестирования - редки (например из тестирования мобил - в тестирование сервисов работающих с данными (это внутри блока функционального тестирования)), а между этими блоками такие переходы вообще практически не встречаются.
И на это есть причины. Компании (а в особенности гиганты IT индустрии, такие как VK, Яндекс, Озон, 2ГИС, Т-банк, Сбер) все чаще ищут "узко-специализированного" специалиста, который к тому же еще и "попадает в стек" команды.
Для тех, кто пока ещё не работает в IT, а только планирует, думаю, стоит пояснить: в компаниях (если это не небольшой стартап) «IT-отдел» чаще всего разделён на команды. Каждая из них отвечает за свою часть «большого продукта», использует свой стек инструментов (языки программирования, фреймворки, технологии), имеет свою архитектуру, командные соглашения и т. д. При этом команды нередко почти не пересекаются друг с другом.
Так вот, лёгкого перехода из тестирования в разработку или аналитику не существует. И дело не только в том, что для этого нужно самостоятельно освоить (и не просто «прочитать», а ещё и набрать практический опыт) инструменты, технологии и всё остальное, что используется в новой роли. Проблема ещё и в том, что к моменту, когда ты «готов переходить», ты, как правило, уже не новичок в тестировании — а при смене направления можешь потерять в доходе примерно 50% от текущего уровня. На такое решение действительно непросто пойти.
Но мы, кажется, отвлеклись.
Мысль, которую я хотел передать в этой части статьи - в тестирование сейчас попасть нелегко. Без опыта - очень сложно, почти невозможно. Стать тестировщиком в 2ГИС без реального опыта - не возможно. Поправка. Сложно, но возможно.
Уже после публикации статьи получил обратную связь от коллег из других команд, что джунов берут. Так что спешу исправить свое категоричное заявление.
Так что следите за вакансиями. Бывают и для новичков в тестировании ;)
Но если вы уже работаете тестировщиком? Что тогда?
Так сложно или нет?
Рассмотрим на моем примере.
На момент трудоустройства в 2ГИС я имел опыт работы тестировщиком в трех компаниях - Шурэтли, I'way и Brandmaker и еще небольшой опыт работы аналитиком в LC Group, а также пару лет опыта инди-разработки мобильных игр (как ни странно - это был возможно один из решающих факторов, позволивший мне устроиться в 2ГИС).
Команда, на вакансию которой я откликнулся, занимается написанием приложений, предназначенных для обработки данных. Это продукты для "внутреннего" потребителя (доступные только сотрудникам 2ГИС) и как следствие требования к "Фронту" скромные, к "Бэкенду" высокие.
Язык разработки, помимо SQL и MDX(язык запросов к Олап кубам) был (и остается) С#. Автотесты на проекте также писались на C#. Связь между различными системами и базами данных - шина интеграции, Kafka, SSIS-пакеты, хранимые процедуры, и старое доброе REST и SOAP API. Контроль версий - SVN и GIT, CI-CD - Gitlab CI и TeamCity.
Зачем я описал здесь стек? А вот зачем. Из вышеперечисленного я НЕ БЫЛ ЗНАКОМ со следующим:
1. Автотесты на C# - на момент собеседования я никогда не писал автотесты на C#. Писал на Java и немного на JS, но не на C#.
2. MDX - вообще не знал про его существование, как и про олап кубы.
3. Шина интеграции
4. SSIS-пакеты
5. Хранимые процедуры
6. SVN
7. TeamCity (в Брендмейкере мы работали с Jenkins, в I'way с Gitlab CI (хотя бы тут смэтчилось)).
С различными SQL я слава богу работал, но опять же это было по большей мере в I'way (в Брендмейкере (а это было последнее рабочее место перед 2ГИС)- очень мало).
Как видно по стеку мэтч не особо то и складывался.
Собеседование?
Тех собес я тоже прошел не идеально - хотя с теорией тестирования и вопросами по АПИ я справился достаточно хорошо (с большинством вопросов), блок кодинга (слава богу на Java) - там нужно было решить задачку, тоже норм. А вот блок SQL я можно сказать завалил. Одну задачу решил, а вот с другой справиться уже не смог.
Я уже рассчитывал на результат в стиле "Не смотря на ваш ум и красоту, ну или что там обычно пишут..." (лайк на коммент тому кто угадает к какому фильму отсылка), но меня все же пригласили на еще один этап - знакомство с командой, ну а потом и на работу.
До сих пор гадаю, что "заставило" команду выписать мне кредит доверия, который кстати было не так просто оправдать. Первые задачи давались мне ой как не легко.
Теперь, по прошествии нескольких лет я могу предположить, что в итоге склонило чашу весов в мою пользу:
1) неумение писать автотесты на C# компенсировалось навыком на писания игр (на этом же языке - хоть это и не равнозначно),
2) ошибки в секции SQL на собеседовании - софт скилами (кажется я хорошо подготовился к блоку вопросов про то, что я достиг на моих предыдущих работах). Да, если вы сможете убедить интервьюера в вашей проактивной позиции - это точно добавит балов к вашему резюме.
Если ты тоже хочешь стать тестировщиком в 2ГИС — что делать (по шагам)
Я специально пишу не “список опций”, а прям дорожную карту.
Шаг 1. Определи, куда ты целишься:
- мобильное тестирование,
- веб/фронт,
- сервисы,
- данные/интеграции/ETL,
- безопасность,
- нагрузка.
Потому что “просто тестировщик” — это уже редкость, и подбор обычно идёт под конкретный профиль.
Вот актуальный список вакансий тестировщиков на момент написания статьи.
Шаг 2. Подтяни базу, которая почти везде решает:
- SQL на уровне джойнов, агрегаций, оконных функций (хотя бы основы),
- API (HTTP, коды, идемпотентность, ретраи, версии),
- понимание CI/CD хотя бы концептуально,
- умение нормально оформлять баг-репорты и “доказывать” проблему.
Шаг 3. Собери “истории”, а не навыки.
На собеседовании редко побеждает человек, который говорит “я знаю Postman”.
Побеждает тот, кто говорит:
- “вот проблема, вот как я её нашёл, вот как локализовал, вот как помог команде исправить, вот эффект”.
Это и есть та самая проактивность, про которую я писал выше.
Шаг 4. Готовься к стеку команды, а не к абстрактной теории.
Если вакансия про C#-автотесты — не надо становиться архитектором .NET, но:
- прочитать про NUnit/xUnit,
- понять Page Object/AAA,
- уметь читать тесты,
- один маленький проект руками сделать
— это решает. Команда видит: “он не ноль”.
Шаг 5. На собесе не бойся сказать “не знаю”, но добавь “как бы я узнал”.
Например:
- “MDX не писал, но знаю SQL и понимаю идею OLAP: меры/измерения/агрегации; могу быстро поднять базу и закрыть пробел”.
Это сильно лучше, чем пытаться выкрутиться и выглядеть сомнительно.
Финал: вывод, который я хотел бы услышать сам раньше
Стать тестировщиком в 2ГИС реально.
Но это не история “выучи теорию → залети”. Это история “у тебя есть опыт → ты умеешь думать → ты умеешь доводить до результата → ты совпал по команде”.
И да: иногда тебе действительно нужен кредит доверия.
Но его не “дают за красивые глаза”. Его дают, когда интервьюеры видят, что ты:
- учишься быстро,
- не разваливаешь процессы,
- умеешь общаться,
- и уже умеешь приносить пользу.
И еще один лайф хак.., хотя опытные тестировщики конечно про него уже знают - если ты хочешь попасть в конкретную компанию, до собеседования с ними пройди несколько собеседований в другие компании/команды. А только потом заявляйся в желаемую. Ведь прохождение собеседований - это тоже навык, и он забывается если ты его не практиковал продолжительное время.
Пишите в комментариях если хотите поделиться своей историей или может не согласны со мной в каких-то тезисах, ну или вообще не согласны.
— Если вам было интересно — ставьте 👍 и делитесь с друзьями!
До встречи в следующей статье 👋
