9 стереотипов о тестировщиках
И что про них думают эксперты Яндекс Практикума.
Эта профессия популярна — особенно среди тех, кто хочет начать работать в IT-сфере и планирует стать тестировщиком с нуля. Интернет переполнен информацией, но как понять, чему верить? Правда ли, что для этой работы не нужны специальные навыки? Или что профессию QA-инженера выбирают те, у кого не получилось стать разработчиком?
Эксперты курса «Инженер по тестированию» собрали популярные мифы и прокомментировали их, опираясь на свой профессиональный и преподавательский опыт. Надеемся, что этот материал поможет вам принять взвешенное и объективное решение, стоит ли погружаться в мир тестирования. Но для начала немного расскажем о профессии в целом — основных функциях и задачах тестировщика.
преподаватель на курсе «Инженер по тестированию»
Job Description инженера по тестированию
Job Description — требования к должности, описание навыков и обязанностей специалиста. Главная задача инженера по тестированию — проверить качество продукта и донести до команды информацию о его состоянии.
QA-инженер проверяет работу сервиса, выявляет несоответствия или ошибки — то есть ищет любые отклонения, которые могут помешать пользователю полноценно использовать продукт. Если говорить простыми словами, тестировщики проверяют то, что сделали другие члены команды: разработчики, дизайнеры, менеджеры, аналитики.
Тестировщик максимально погружается в продукт: его функциональность, внутреннюю структуру, рутинные и нестандартные пользовательские сценарии. Он изучает каждую строчку в требованиях, каждый пиксель на макетах, оценивает работоспособность каждого решения.
Конечно, если бы тестировщик наугад проходился по функционалу приложения — нажимал на кнопки, совершал какие-то действия, — вероятность наткнуться на баг была бы очень низкой, а значит, проверка сильно растягивалась бы по времени и была некачественной. Поэтому необходимо знать теорию тестирования: разбираться в его видах и знать техники тест-дизайна.
Тестирование бывает двух видов:
● Ручное (или мануальное). Специалисты проверяют всё самостоятельно: нажимают на кнопки, переходят между окнами, заполняют поля и формы, как обычные пользователи. Кроме этого, они используют базы данных, инструменты для тестирования API и перехвата трафика (Charles), инструменты разработчика (Devtools).
● Автоматизированное. Флоу проверки схож с ручным тестированием, но в этом случае проверяет функционал приложения и ищет ошибки специальная программа — специалист должен уметь писать код для неё.
Теперь, когда вы больше погружены в контекст профессии QA-инженера, предлагаем перейти к распространённым стереотипам и разобраться, насколько они соответствуют действительности.
Просто, быстро и дёшево всё сломать? Это точно не про тестировщика
Задачи QA-инженера более комплексные и сложные, чем принято думать. Это не «ассистент программиста», а полноценная профессия со своими плюсами и минусами. Не стоит безоговорочно верить рассказам об исключительной лёгкости и простоте работы — так же как не нужно полагаться на «страшилки» о невозможности найти работу или ответственности за все найденные ошибки.
Миф 1. Тестирование — самый простой способ старта в IT
Говорят, что тестировщик — самая простая IT-профессия. Она не требует специальных знаний — достаточно действовать по инструкции. Нет необходимости в длительном обучении — освоить скилсет можно за короткий срок. Так как выучиться на тестировщика легко — можно очень быстро выходить на рынок труда и искать первую работу. В общем, сплошные плюсы. Но всё ли так просто на самом деле?
Возможно, в каком-то смысле тестирование действительно хорошее направление для начинающих. Но это совсем не обязательно. QA часто выбирают, потому что всем более или менее понятно, чем занимается тестировщик.
А я бы посоветовал, выбирая профессию, опираться на свои сильные стороны. С аналитическим складом ума, возможно, будет логичнее заняться аналитикой. Многие специалисты начинали в поддержке — это хороший способ изучить пользовательские боли с возможностями роста в самых разных направлениях. Ещё есть, например, математики — люди, которые обладают склонностью к техническим наукам, но не хотят много взаимодействовать с пользователями или коллегами: вести переговоры, организовывать процессы. Для них актуальнее будет разработка, как более самоходная профессия.
Профессий в IT много, главное определиться, чем хочется заниматься, а не выбирать путь «наименьшего сопротивления». Я сам пришёл в тестирование с такой мыслью, но быстро понял, что ошибался: учесть все сценарии, погружаться в документацию не так-то просто. Мне повезло, что нашёл себя в этой профессии.
Я бы тоже сказала, что это не так. На своем опыте я поняла, что легкого пути в любую профессию в принципе не существует. Возможно, тестировщику не придётся учить языки программирования, зато придётся знать больше инструментов, чем в среднем требуется программисту. Когда я смотрю вакансии для QA-инженеров, редко встречаю стек, на 100% совпадающий с моим, — почти всегда в описании вакансии есть что-то, чего я пока не знаю.
Миф 2. Тестировщику нужно иметь технический бэкграунд
Безусловно, работа QA-инженера — техническая, придётся погружаться в аналитику, документацию, разбираться в терминах и системах. Но даже если вам никогда прежде не приходилось работать за компьютером, всему можно научиться.
Я так или иначе связал свою жизнь с компьютерами: лет с 8–10 уже делал сайты, развивал их, администрировал. Ещё я давно веду YouTube-канал по 3D-моделированию, записываю обучающие видео. То есть бэкграунд есть, но непрофильный. Когда я на собеседованиях перечислял всё, чем занимался до тестирования, меня часто спрашивали: «Почему тогда, например, не разработчик?» Это, кстати, вопрос, на который надо ещё правильно ответить — например, «ради денег» или «потому что это самая простая IT-профессия» точно не прибавит вам очков в глазах рекрутёра.
У меня всё было просто: тестирование «зашло», почти случайно попробовал, и захотелось продолжать. Многие рассказывают, что с детства любили разбираться, чинить, ломать и прочее (это, кстати, наоборот, хорошо работает на собеседованиях). Но мне до начала изучения профессии тестировщика никогда не было интересно разбираться в технических штуках.
И я часто вижу студентов, которые приходят вообще без какого-либо опыта работы с техникой — скажем, даже не знают, как сделать скриншот. Они в итоге преуспевают и своим примером доказывают, что всему можно научиться, найти работу, сделать карьеру. Кстати, софтскилы здесь играют не последнюю роль. Одна из моих студенток, врач по образованию, благодаря навыкам коммуникации и умению задавать вопросы не только успешно окончила курс, но и была лидом группы на протяжении обучения — хотя вместе с ней учились «технари».
Более того, что-то не понимать — постоянная история в нашей профессии, даже если есть опыт. Регулярно встречаются задачи, в которых ничего не понимаешь: перечитываешь десятки раз, гуглишь, спрашиваешь у коллег, читаешь документацию. Но если проявить усердие, спустя N часов (а может быть, дней, недель или даже месяцев) всё проясняется. Я всегда говорю, что главное в этой сфере — уметь адаптироваться, держать руку на пульсе.
Соглашусь — иметь технический бэкграунд желательно, но необязательно. Реальность такова, что большинству востребованных сегодня IT-профессий в вузах не учат. В лучшем случае это программисты или специалисты по информационной безопасности. Поэтому среди тестировщиков, аналитиков много людей, которые пришли из других профессий.
У меня, например, высшее гуманитарное образование. Хотя мне со школы были интересны компьютеры и технологии, я не занималась этим всерьез. Мое личное мнение — научиться можно всему, было бы желание, силы и время.
Миф 3. Пропущенный баг — вина тестировщика
Жизненный цикл продукта — то есть его разработка, релиз и поддержка — состоит из множества этапов. Тестирование — лишь один из них, хотя, безусловно, очень важный. Пропущенная ошибка может негативно сказаться на пользовательском опыте, но действительно ли ответственность за это лежит только на инженере по тестированию?
Этот стереотип, как мне кажется, основан на «законе джунглей», когда главное — найти виноватого. В IT-сфере такой подход — обвинить, оштрафовать или даже уволить — не очень популярен.
В командах, где мне довелось работать, обычно следующий порядок: если мы пропустили важный баг, то ответственность на всей команде. Это мотивирует, даёт уверенность, что мы — коллектив, объединённый желанием создать качественный продукт, а не просто кучка отдельно взятых индивидов, работающих «за зарплату».
Да, тестировщик не заметил баг, но если начать распутывать этот «клубок», получится, что ошибку допустил разработчик, который не до конца понял требования, составленные менеджером. Менеджер, в свою очередь, неверно истолковал данные, полученные от аналитика, аналитик не убедился, что корректно донёс информацию, — и так далее. Эти рассуждения не несут пользы — лучше вместе подумать, как избежать повторения ситуации. Например, создать тест-кейс и в будущем проверять этот функционал тщательнее.
Миф 4. Тестировщики всё ломают
Ещё одно популярное представление основано на том, что тестировщики ищут ошибки, а значит — намеренно «ломают» систему. На самом деле в этом утверждении неверно расставлены акценты: задача QA-инженера заключается не в том, чтобы найти ошибку, а в том, чтобы проверить работу продукта.
Конечно, есть такое понятие, как стресс-тест — проверка отказоустойчивости системы в условиях, когда что-то сломано. Но на практике почти половина тестов, которые мы проводим, — позитивные. То есть мы проверяем «правильное» поведение пользователя.
Например, в системе при регистрации логин должен содержать не менее пяти и не более двадцати символов — при позитивном тестировании мы вводим восемь символов. В рамках негативного теста мы бы попробовали создать логин, скажем, из тридцати символов. Или другая ситуация — тестируем API. Тогда для позитивного теста посылаем системе верный запрос, а для негативного — пропустим ключевые данные или вообще нарушим структуру.
В работе, составляя чек-листы или наборы тестов, я специально разделяю позитивные и негативные проверки. По ощущениям получается примерно поровну — а иногда даже, наоборот, позитивных больше.
Миф 5. Тестировщики радуются, когда находят баг
Кажется, что если суть работы QA-инженера — проверять работу системы, то выявить как можно больше багов — главное достижение. На самом деле любое несоответствие означает доработку продукта — то есть трату ресурсов и задержку релиза. Даже если тестирование заложено в сроки, дополнительная итерация правок вряд ли порадует команду и самого тестировщика.
Сложно сказать, испытываю ли я положительные эмоции, когда что-то работает не так, как задумано. Особенно если это выясняется уже в продакшне, когда ошибку нашёл пользователь. В первую очередь это удар по репутации — где-то вы с коллегами недосмотрели. Это скажется и на стоимости проекта, и на сроках работы.
И вообще было бы здорово получать сразу готовые фичи — это не только освобождает разработчиков от переделки, но и специалиста от проведения повторного тестирования (ретеста). Но я понимаю, что QA-инженер на раннем этапе фильтрует моменты, которые могут сформировать негативное впечатление у пользователя. Если мы вовремя «поймаем» ошибку, избежим шквала отзывов в духе: «Это приложение полный отстой, никак не получается зайти!» Так что если баг отслеживают специалисты, а не раздражённый клиент, — это точно повод для радости. И кстати, во многих командах есть KPI, завязанный на критичном функционале: например, что система должна работать для пользователей в 98% случаев, что бы ни происходило «внутри».
Миф 6. Тестировщик не обязан разбираться в коде
Считается, что тестировщик работает скорее с готовым продуктом, чем с его внутренним устройством, поэтому знать, что «под капотом», необязательно. Мнения на этот счет расходятся даже у специалистов, но в одном они точно согласны — чтобы развиваться в профессии, нужно расширять свои знания, в том числе технические.
Я считаю, что технические знания тестировщика демонстрируют уровень его профессионализма. Начинающему QA-инженеру необязательно вникать в код. И даже опытному специалисту, пришедшему на новый проект, может быть сложно с ходу разобраться, как всё устроено. Но хороший специалист ценен тем, что может найти не только саму ошибку, но и локализовать её, выявить причину. Да, вначале он будет действовать как рядовой пользователь, проверит тот или иной сценарий. А потом заглянет «внутрь», проверит, правильно ли идут запросы, протестирует архитектуру и коды ответов.
Работать без этого навыка можно, но развиваться в профессии вряд ли получится. Необязательность глубоких технических знаний — своеобразная «наживка» для новичков, которая может оказаться неприятным сюрпризом при столкновении с реальностью.
Разбираться в коде QA-инженер не обязан, конечно. В одном из проектов, над которыми я работала, я понятия не имела, что представляет собой, например, код бэкенда. Самое информативное, что у меня было, — API-документация. Но и тестировать тогда нужно было обработку запросов, а не сам процесс. На другом проекте, когда я проводила исследовательское тестирование, — не было даже требований к продукту. Разумеется, будь под рукой нужная документация, тестирование было бы более исчерпывающим.
Справиться с задачей можно, даже имея минимум информации. Но если есть возможность копнуть чуть глубже — обязательно стоит ею воспользоваться. Чем больше QA-инженер знает о том, что он тестирует, тем более качественно он сделает свою работу и тем лучше будет конечный продукт.
Миф 7. У тестировщика мало возможностей карьерного развития
Пожалуй, один из главных мифов о работе QA-инженера. Также встречается мнение, что развиваться в этой профессии получится только в направлении автоматизации. Но путей развития больше — главное, чтобы у специалиста был интерес к работе и стремление к росту.
На самом деле вариантов много, и гораздо менее очевидных, чем автоматизированное тестирование. Например, можно стать аналитиком. Спектр задач этих специалистов близок тестировщикам: они работают с требованиями — умеют писать, анализировать, иногда и тестировать их. Знают, как работает система, погружаются во всю «внутрянку» проекта. Также, если есть склонность к аналитике, можно заниматься исследовательским тестированием.
Ещё один путь развития — нагрузочное тестирование. То есть когда мы единовременно проверяем мощности системы. Например, как отреагирует сервис, если столкнётся с автоматизацией нескольких тысяч пользователей? Как с этим справится база данных?
Можно вообще сместить фокус внимания на управление командой или работу с людьми: развиваться как менеджер и работать с метриками, стать ментором, заниматься онбордингом стажёров или джунов, проводить собеседования. И конечно, тестировщику при желании открыт путь в разработку — в этом случае роль автоматизатора может быть промежуточным этапом. Векторов роста достаточно, чтобы найти себе подходящий.
Миф 8. Время тестировщиков дешевле, пусть они и тестируют
Внутри продуктовых команд встречается убеждение, что даже в самые загруженные периоды задачи тестировщиков не стоит перераспределять. Рабочее время QA-инженеров дешевле, чем, например, разработчиков, а значит, команда сэкономит на стоимости внедрения изменения.
Не согласен с таким подходом. Ключевой фактор в этой ситуации — скорость доставки обновления пользователю, именно она влияет на стоимость работы команды. Поэтому в случае сжатых сроков или высокой загруженности задачи могут распределяться между разными ролями. То есть аналитик вполне может взять на себя какие-то функции тестировщика.
Причём это работает и в обратную сторону: где-то тестировщик может сделать дополнительные задачи — проанализировать, уточнить, дополнить требования. Вот заменить разработчика QA-инженер вряд ли сможет, это правда.
Но вообще при работе над продуктом или проектом используются методологии управления — например, SCRUM. Во-первых, это помогает оценить задачи, спланировать время и нагрузку команды. А во-вторых, если что-то идёт не по плану, наглядные, четко сформулированные зоны ответственности и порядок работы помогают лучше определить, как «закрыть» слабые места. Главное — ставить в приоритет доставку фичи до пользователя, а не стоимость работы того или иного специалиста.
Миф 9. «Тестировщику сложно найти работу» или «Тестировщику легко найти работу»
Оба утверждения встречаются одинаково часто, и посмотреть на этот миф можно с разных сторон. Инженер по тестированию — популярная профессия, в том числе среди тех, кто только начинает свою карьеру в IT, поэтому конкуренция на рынке труда весьма высока. Но и предложений немало. Поэтому лучше сделать упор на качественное обучение и подготовку к тестовым заданиям и интервью, чем полагаться на удачу или заведомо опускать руки.
Джуну найти работу правда сложно — нужно сидеть и упорно, одно за другим рассылать резюме, десятки в день. Поиск работы может длиться месяц, два месяца, полгода. Даже год бывает — у кого как. Но это касается любой профессии, вряд ли есть область, в которой легко стартовать без опыта.
При этом, когда удастся попасть на первую работу, уже спустя полгода-год вы станете востребованным специалистом — рекрутёры сами будут звать на собеседования, увидев, что в резюме есть реальный опыт.
У меня банковское образование. Я работал в автосалоне специалистом по страхованию и кредитованию и в какой-то момент решил, что хочу сменить деятельность. Проучившись несколько месяцев на курсе, переехал в Москву — не сомневался, что готов «покорять столицу». Но всё оказалось не так радужно: каждый мой день был похож на предыдущий. Открывал HeadHunter, рассылал 10–20–30 откликов, делал тестовые в пустоту, еле-еле доходил до собеседований, после которых со мной никогда не связывались. На этом этапе всё решает упорство — если не сдаться, обязательно «пробьёшься».
У моих знакомых аналогичный опыт — главное, преодолеть психологический барьер и добиться первого оффера и поработать в профессии хотя бы полгода (а лучше год). Потом рекрутёры сами будут «хантить» вас. Когда, проработав год в первой компании, я снова опубликовал резюме, очень удивился. На протяжении двух недель с 11 до 19 часов я постоянно был на интервью. Не знаю, может быть, я попал в какие-то ключевые слова?
Подводя итог, я думаю, что сложности с поиском работы ждут только на первом этапе — и это не новость. А в целом рынок труда в профессии тестировщика динамичный, специалист не останется без работы.
Выбирая профессию, доверяйте себе, а не стереотипам
Любой миф — вопрос восприятия. Преимущество можно превратить в недостаток и наоборот. Если вашей мотивацией будет «легкий заработок» или «простой вход в IT», вы столкнётесь с выгоранием быстрее, чем с успехом. Если поверить мифу об отсутствии карьерного развития, вы лишите себя возможности даже попробовать и не узнаете, что в реальности ситуация совсем не так печальна.
Мы разобрали лишь часть мифов о профессии тестировщика. И увидели, что большинство из них не соответствует действительности. Какие-то сложности действительно присутствуют, но они преодолимы для любого, кому интересно тестирование.
Начинать знакомство с профессией лучше через проверенные учебные материалы или интервью с действующими специалистами — так вы сосредоточитесь на сути работы тестировщика, а не на выборочном перечислении фактов без контекста.
Комментарий недоступен
Работы не найти
Эх, а ведь из янд могла получиться хорошая школа. Увы, но всё просрали. Типичный отмыв бабосиков.