Моя история в IT: как я стала автотестером

Привет! Меня зовут Юля, я работаю QA Automation Engineer в компании MobileUp. А это история моего пути в IT для тех, кто тоже не сразу понял, кем хочет стать, когда вырастет. Я поделюсь, с чего начинала, как выбирала направление и почему в какой-то момент захотела перейти из ручного тестирования в автоматизированное. А ещё расскажу, как устроена работа автоматизатором и что нужно знать, чтобы стартовать в профессии.

2010 год. Я учусь в международном банковском институте на специальности «Банковское дело, финансы и кредит». Мечтаю в будущем работать в банке, считать деньги и решать, одобрят конкретному клиенту кредит или нет. Важная ремарка: в 2010-х получить специальность экономиста или юриста было так же круто, как сейчас войти в IT.

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

Спустя пять лет я стала экономистом. Работала в бухгалтерии и каждый день, приходя в офис, считала, сколько дней до пенсии мне осталось. Выбранная профессия оказалась не «моей». И сильнее всего это ощущалось при общении с друзьями, которые на тот момент уже «вошли в IT». Я видела, как горят их глаза всякий раз, когда они говорят о работе, и не понимала, почему у меня не так. А ещё я чувствовала себя абсолютно не в контексте. Пуш, релиз, бэклог, спринт были просто непонятными словами, значение которых приходилось гуглить. Как-то я наткнулась на картинку, которая рассказывала, что такое бэкенд и фронтенд. Это стало первым толчком к тому, чтобы разобраться в отличиях этих направлений.

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

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

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

Я начала с изучения базовой литературы (все ссылки оставлю в конце статьи) и прохождения курса по основам тестирования. А после прошла собеседование на позицию QA в свою же компанию. Спойлер — меня приняли.

И вот я junior QA, который набирается опыта. Скорость работы была невысокой, так как помимо погружения в проект я параллельно углублялась в теоретическую область. Но первый год всё равно выдался сложным. Приходилось изучать многое самостоятельно, а параллельно бороться с синдромом самозванца. Конечно, не всё получалось сразу, но очень помогала обратная связь. Это, пожалуй, главный совет, который я могу дать новичкам: не бойтесь критики. Наоборот, прекрасно, если она есть. Анализ комментариев и работа над ошибками сильно помогают в росте и развитии.

За год я обрела уверенность в том, что делаю, но параллельно поняла, что продукт мне не особо интересен. Компания занималась разработкой ПО для складов — я видела только develop-часть и «потрогать» её не могла. Я приняла решение двигаться дальше. Из направлений меня больше всего привлекала мобильная разработка, так как её продуктами мы пользуемся каждый день.

Я начала искать подходящие вакансии и увидела объявление MobileUp. Ещё до собеседования прочла всё, что есть о компании в свободном доступе, и поняла, что это именно то, место куда я хочу. Интересные проекты, современные технологии, активная жизнь — о чём ещё можно мечтать? Спойлер — меня снова приняли.

На performance review (это обязательный чекап сотрудника, где проставляются цели на ближайшие полгода) я сказала, что хочу войти в автотестирование. В MobileUp на тот момент не было специалистов-автоматизаторов. Но компания увидела потенциал этого направления и пошла на встречу.

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

Выбор пал на Python, так как это универсальный язык для покрытия автотестами сразу обеих платформ — iOS и Android.

Также подходят Java или JS. Или если у вас нет цели покрывать автотестами обе платформы — можно использовать нативные языки типа Swift и Kotlin.

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

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

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

***

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

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

И, как обещала, делюсь полезными ресурсами для самообучения:

Большой учебник по тестированию — https://testengineer.ru/bolshoj-uchebnik-po-testirovaniyu/

Курс на Stepik «Мобильное тестирование(Android\IOS) Middle\Senior» — https://stepik.org/course/124936/promo

Курс на Stepik «Автоматизация тестирования с помощью Selenium и Python» — https://stepik.org/course/575/promo

Курс на Stepik «Введение в тестирование на Python (Unittest, Pytest)» — https://stepik.org/course/180532/promo

Ютуб-канал QA Артема Русова — https://www.youtube.com/@rusau

Телеграм-канал «Тестировщик от бога» — https://t.me/godoftesting