Каждый второй обыватель хочет зайти в “денежную” ИТ-отрасль через тестирование. И с развитием онлайн-образования появилось довольно много возможностей это сделать. Результат - QA, особенно уровня джуна, становится много. Как с ними конкурировать?
Очевидный путь - быстро повышать квалификацию, уходить в хардкор-автоматизацию. Но есть и вторая дорога - углубляться не так целенаправленно, частично сохраняя привычные ручные задачи. Сегодня хочется поговорить как раз про второй путь - о фулстеках QA.
Уже несколько лет никого не удивляют фулстеки в разработке, которые могут взаимодействовать и с бэкендом, и с фронтендом. А вот понятие фулстек QA появилось сравнительно недавно, так что единого понимания, кто это такие, пока не сформировалось.
Фулстеками зовут тех, кто способен решать разнообразные проблемы - эдаких универсальных бойцов. Разноплановость в контексте тестирования можно понимать по-разному. Кто-то имеет в виду десктоп / mobile / web. Но классическое понимание - это все-таки ручник и автоматизатор “в одном флаконе”, точнее специалист, который уже не просто ручник, но еще и не senior-автоматизатор - человек с достаточным опытом ручного тестирования и разнообразным бэкграундом автоматизации. Дополнительным преимуществом будет понимание основ работы системного аналитика и devops. Плюс софт-скиллы, поскольку придется очень много общаться внутри команды.
Почему все чаще ищут именно фулстеков?
На рынке довольно много специалистов, которые сильны в какой-то одной крайности - в ручном тестировании или в автоматизации. В другую крайность они обычно не суются, а если все-таки приходится переключаться, их производительность сильно падает.
Ручник может не знать каких-то нюансов кода и не разбираться, как вообще работает автоматизация. С повсеместным движением в сторону автоматизации тестирования таких задач ограниченное количество. А канонический автоматизатор должен получать задачи чисто под него - на перевод тест-кейса в код и больше ничего. Он также занимается архитектурными и хардкорными моментами. При этом на рынке полно автоматизаторов, которые и не представляют, как обращаться с ручным тестированием - у них просто нет такого опыта.
На фоне узких специалистов фулстек удобен компании, потому что для него работу не придется делить на этапы - передавать сначала одному узкопрофильному специалисту, а потом другому. Ему можно отдать ее целиком, например, полностью передать некое функциональное тестирование. И саму задачу ему можно поставить с точки зрения бизнеса, а не QA. Он посмотрит фичу, напишет тест-кейсы и все автоматизирует. На выходе фича будет проверена и покрыта автотестами.
Фулстек - это продвинутый ручник с навыками автоматизатора. Он может залезть в задачи для ручного тестирования, а иногда и понять пул-реквест разработчика.
На наш взгляд хороший автоматизатор - это в каком-то смысле фулстек. Потому что автоматизатор должен не просто переводить задачу в код, а смотреть в ручной тест и думать, как сделать его проще и оптимальнее - т.е. понимать, что там происходит. Это очень творческая задача. И если автоматизатор не проходил “курс молодого бойца” в ручном тестировании, а умеет лишь кодить, он ошибется на стадии тест-дизайна. Построит не те или избыточные тесты.
Гораздо лучше, если автоматизатор не забывает бэкграунд. Тестируя руками, он лучше узнает логику продукта, неизбежно общается с командой и погружается в функционал, развиваясь в проекте. Чистая автоматизация по готовым тест-кейсам (подготовленным кем-то другим) не дает такого погружения.
Далеко ли от QA-фулстека до разработчика?
При постепенном погружении специалиста по ручному тестированию в тонкости разработки ПО правильная последовательность выглядит примерно так:
ручной тестировщик;
фулстек;
автоматизатор;
и лишь потом (если повезет) разработчик.
Казалось бы, постепенно углубляясь в разработку, можно уйти в нее целиком. Наверное, в рекламе быстрых курсов так и рассказали бы. Но на практике, не меняя проект, этого сделать не получится.
Из ручника в автоматизаторы фулстеку не дадут уйти ежедневные обязанности. Как бы он не стремился отказаться от задач ручного тестирования, они все равно будут прилетать. Не получится сосредоточиться только на автоматизации. Бизнесу удобен специалист-многостаночник.
Кому-то покажется, что это тупик. Но никто не мешает развиваться за рамками рабочих задач. Правда, путь дальше еще сложнее. Разработка требует знаний не просто синтаксиса языка. Это совершенно другие инструменты и фреймворки, нежели в тестировании, поэтому уйти в этом направлении не просто.
Это легко на определенном жизненном этапе, когда от тебя не зависит семья и ипотека. В другое время это как любой другой переход между соседними отраслями - не только финансовые потери, но и умственные. В ИТ тебе и так, чтобы оставаться на своем месте, необходимо постоянно “бежать вперед” - чему-то учиться, что-то подтягивать. Каждый день ты живешь в режиме жесткой конкуренции. Пытаясь и свое место сохранить, и успешно куда-то перейти, ты вынужден будешь делать это в два раза быстрее. В свободное время придется выучить много новых фреймворков. Половина из них пригодится тебе на первом проекте, но не потребуется потом никогда. Не на любом этапе жизни у тебя будут ресурсы и мотивация, чтобы пройти этот путь.
Упорство поможет перешагнуть через все барьеры. Просто не надо думать, что все пойдет само собой.
За что хвататься, если хочется в фулстеки?
В первую очередь нужны желание и мотивация. Часто бывает, что человек хочет двигаться в каком-то направлении. Ему озвучивают конкретные шаги. Но проходят месяцы, а с мертвой точки ничего не двигается. В отсутствии прогресса тут виноваты не технологии или советчики, а тот, кто предпочитает не развиваться.
Теперь что касается технических навыков.
Чтобы претендовать на “звание” фулстека, надо хорошо владеть ручным тестированием - понимать как методы и инструменты самого тестирования, так и бизнес-процессы проекта. Нужно понимать в автоматизации - что это и в каких случаях она нужна. Мы на своих проектах предлагаем человеку сначала посмотреть синтаксис того языка, на котором пишутся автотесты. К примеру, Kotlin. Достаточно написать простейший калькулятор, поиграться с массивами, понять методы и классы, возможно, идеи ООП. Это большой шаг навстречу автоматизации. Этих простых вещей достаточно, чтобы начать.
В целом путь в фулстеки - для тех, кто хочет попробовать автоматизацию, но не планирует ею ограничиваться. Основная задача широкопрофильного специалиста - масштабировать кейсы конкретного проекта. А раз одинаковых проектов нет, не существует и универсальных требований. Это как с вакансиями автоматизатора - где-то достаточно базовой автоматизации, а где-то нужно, чтобы человек новые библиотеки писал. Где-то все это должно быть приправлено навыками devops, а для кого-то поиск фулстека - просто попытка нанять автоматизатора с бэкграундом ручника (о чем говорили выше).
P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.
