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

Всем привет, на связи Антон Кривицкий, тимлид QA-отдела в KODE. Мы проводим стажировки для начинающих тестировщиков с 2019 года. Наши стажировки всегда были популярны, но весной 2022 я заметил, что приток желающих «войти в айти» через тестирование заметно вырос. Это само по себе не новость: плюшки работы в IT-компаниях привлекают всё больше желающих сменить профессию.

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

Чем на самом деле занимаются в отделах тестирования

Сначала разберёмся, что такое тестирование и почему оно не такое уж и простое.

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

Расшифрую, что означает эта картинка, которая в разных вариациях давно гуляет по интернету. Мы в компании так разделяем уровни обеспечения качества:

1. Test engineer — инженер по тестированию или тестировщик. Как правило, это человек без коммерческого опыта — вчерашний выпускник курсов или только завершивший стажировку. Такой специалист в основном занимается самыми простыми задачами: пишет и выполняет тест-кейсы, проверяет исправленные баги и заводит новые.

2. QC (Quality Control) engineer — инженер по контролю за качеством. Он не просто проходит проверки, а может проанализировать результат и оценить качество продукта: сделать выводы о стабильности функционала, решить, можно ли выпускать продукт в релиз и подсветить возможные риски менеджеру.

3. QA (Quality Assurance) engineer — инженер по обеспечению качества. Человек, который видит процесс разработки от начала до конца: от первых макетов и требований до постпродакшена и развития продукта. Он может предотвратить возникновение багов и предвидеть возможные риски на ранних этапах разработки проекта. Способен заметить недостатки в процессах, которые потом скажутся на разработке: недостаточное внимание процессам ревью требований и дизайна, нарушенные коммуникации в команде и так далее. 

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

Между Test engineer и Quality Assurance есть ещё одно, ключевое отличие: инженер по тестированию выполняет задачи, которые ему ставит ментор или другой более опытный коллега, от QA-инженера мы всегда ожидаем максимальную самостоятельность и проактивность. 

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

Что происходит на рынке

Чтобы убедиться, что ситуация в нашей компании соответствует рынку, я изучил количество вакансий в тестировании. 

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

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

В нашей компании в 2022 году мы провели более 60 собеседований в отдел QA и наняли 11 человек. Из них только на две позиции мы искали джунов, все остальные места — для специалистов уровня мидл и выше. 

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

Ожидания vs реальность

Ожидания от работы в IT многие формируют из статей в медиа, обещаний курсов, рассказов друзей, которые уже работают в IT. А потом оказывается, что слова не соответствуют реальности. Вот в чём чаще всего разочаровываются начинающие тестировщики↓

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

Уровень минимальных знаний на позицию джуна сейчас может сильно отличаться в зависимости от компании. Одни ждут от кандидатов на позицию junior знания и опыт работ с DevTools, Postman, Charles/Fiddler, Android Studio, SQL, с различными языками программирования и даже JMeter. У других — самый минимум: знать теорию тестирования, техники тест-дизайна, уметь писать тест-кейсы и багрепорты. Но так как конкуренция на такие позиции очень большая, то преимущество получают кандидаты, которые хотя бы поверхностно знакомым с релевантными компании инструментами. Кандидат с хорошими знаниями теории и DevTools чаще проиграет конкуренцию такому же кандидату, но с опытом работы в Postman (при прочих равных естественно).

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

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

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

Не те деньги. Будущим тестировщикам на курсах обещают зарплату 100 тысяч после нескольких месяцев обучения. Многие уверены, что для этого достаточно уметь нажимать кнопки. Это явно завышенные ожидания. 

Зарабатывать хорошие деньги — реально, но не на старте карьеры с минимумом знаний. Для этого нужно обладать определёнными компетенциями: получить достаточное количество реального опыта разработки ПО, хорошо понимать клиент-серверную архитектуру, освоить на уверенном уровне инструменты для работы QA, при необходимости уметь писать автотесты.

Зарплаты специалистов по качеству. Хабр Карьера
Зарплаты специалистов по качеству. Хабр Карьера

Не тот график. Сейчас, конечно, очень распространена удалёнка, но чаще люди работают по стандартному офисному графику с 9 до 18, иногда с гибким началом рабочего дня. У нас именно так — не важно, приходишь ты на работу в 8 утра или в 11, главное, чтобы работа была продуктивной, и это не было в ущерб проекту. За продолжительностью рабочего дня сотрудники следят сами. Мы даём совам выспаться, а жаворонки могут освободиться пораньше. 

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

Если идти в тестирование, нужно чётко понимать, что фиксированный график не всегда возможен.

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

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

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

Что делать тем, кого я не убедил

Если вы всё ещё намерены изучать тестирование, то вот что я могу посоветовать.

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

Если выбираете курс, смотрите программу. Иногда можно найти обучение, которое длится 6 или 9 месяцев, при этом в программе указано всё подряд: от теории по управлению проектами до нескольких языков программирования и администрирования Линукс. Моё мнение — программа у этих курсов избыточная и слишком растянутая. Если вам важнее результат, а не процесс обучения, то лучше посмотреть в сторону курсов с более конкретным набором технологий и большим количеством практики.

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

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

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

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

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

Комментарии (4)