×Закрыть

Как развиваться тестировщику, если не привлекает автоматизация

Всем привет! Для многих людей начало года — хороший период, чтобы подумать о своем будущем, в том числе о карьере и профессиональном развитии. В этой статье я хотел бы поделиться своим видением того, какие возможные варианты роста есть у условного Middle QA, в особенности если он по каким-то причинам не рассматривает переход в автоматизацию.

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

Расскажу кратко о своем опыте. Уже год работаю в компании Adobe в США. В тестировании — 5 лет; ранее был техническим писателем и бизнес-аналитиком, так что общий стаж в IT у меня более 7 лет. Иногда пишу автотесты, но делаю это без особого энтузиазма. Не знаю почему, но лично мне это вообще не интересно; и я знаю многих умных и способных людей, которым тоже не нравится писать код. Они из года в год обещают себе прокачаться в автоматизации, но как-то не идет. Если кто-то встречал психологические исследования о причинах этого явления, буду рад почитать. Хотя, возможно, это банальная лень.

Почему стоит получать сертификации

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

Самое интересное, что сертификацию ведь не обязательно сдавать. И данный факт сразу нивелирует аргумент, что это только бизнес. Обычно перечень тем и краткие материалы для подготовки доступны всем. Ознакомившись с этой информацией, легко понять, что востребовано, а что нет практически в любой области. Базируясь на этой информации, можно легко написать себе план подготовки, даже если экзамен сдавать вы не планируете. Экзамен просто мотивирует лучше готовиться.

Разнообразие возможных направлений развития я решил разделить на 2 большие группы. Пытался подобрать названия, которые говорят сами за себя, но, думаю, будет нелишним объяснить, какой смысл я вкладываю в понятия «менеджеры» и «эксперты».

Менеджеры

К менеджерам я отношу должности, которые близки к вопросам управления качеством:

  • Delivery Manager.
  • Release Manager.
  • QA Manager.

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

Так как это направление больше о менеджменте, то для развития в нем меньшую роль играют технические навыки. Представители этой категории должны быть хорошо знакомы с принципами управления качеством (Total Quality Management, Six Sigma, CMMI). Также немаловажным будет глубокое знание продукта, архитектуры, взаимосвязи между компонентами и модулями. Есть определенные пересечения с областями знаний Product Manager и Project Manager:

  • работа с заинтересованными сторонами (качество — почти всегда компромисс между сроками, стоимостью и скоупом);
  • оценка задач (сложность или временные затраты);
  • управление рисками.

Хотелось бы отметить, что не везде в компаниях есть QA Manager. Например, сейчас у нас только один менеджер — менеджер команды. Хотя на предыдущем месте работы были QA Manager и Project Manager. Обычно это зависит от иерархии компании и степени вовлеченности тех или иных ролей в команду/проект. В одних компаниях тестирование — это отдельный департамент или отдел, в других — тестировщик является членом команды. Аналогичная ситуация с аналитиками, техническими писателями, админами и т. д.

В этом есть как плюсы, так и минусы. Преимущество наличия профильного менеджера, при условии, что менеджер толковый, в том, что он как раз может быть источником знаний, особенно для начинающих специалистов. То же справедливо для QA Lead. Развитие своих сотрудников — его прямая задача. Второй важный плюс — то, что кроме менеджера есть еще и команда тестировщиков. При таком подходе легче организовать knowledge sharing, появляется какая-то конкуренция, общие встречи. На своем текущем месте работы я с другими тестировщиками практически не взаимодействую, и этого немного не хватает. Недостатком же наличия второго менеджера является потенциальный конфликт интересов между тест-менеджером и менеджером команды, проекта или продукта. Особенно если проект не один.

Эксперты

Обычно статус эксперта подразумевает высшую степень квалификации, но в данном случае это просто параллельная ветка, которая обозначает развитие в какой-то узкой области. Если кто-то придумает название получше, буду рад.

Самыми большими группами являются:

  • Performance Specialist.
  • Usability Specialist.
  • Security Specialist.

Для развития в направлении Performance необходимо знать и понимать:

  • архитектуру приложения;
  • методологию и виды performance-тестирования (Performance Testing, Load Testing, Stress Testing, Scalability Testing);
  • инструменты для тестирования (JMeter, Gatling);
  • инструменты для мониторинга и логирования (New Relic, Datadog).

Направление UX/UI — тоже достаточно интересная тема. Востребованным является тестирование совместимости с разными браузерами, операционными системами или размерами экранов (Compatibility Testing), в том числе автоматизация этого процесса или техники оптимизации количества вариаций.

Для тестирования удобства использования также существуют специальные рекомендации по интерфейсу, которыми можно пользоваться как спецификациями, например SUMI (Software Usability Measurement Inventory) или WAMMI (Website Analysis and Measurement Inventory). Сюда же можно отнести A/B-тестирование.

Что касается Security, то здесь сертификации играют намного большую роль. Но большинство авторитетных сертификаций можно сдавать, только имея подтвержденный опыт работы в сфере безопасности (CISSP, CCSP, CEH). В то же время для подготовки к ним и для собственного развития можно сдать менее известные и требовательные к наличию опыта сертификации (ISC 2 Associate, CISA).

Направлений здесь тоже много:

  • Penetration Testing.
  • Security Auditing.
  • Compliance Testing.

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

Возможен также более радикальный вариант с переходом в начинающие специалисты в направлениях Security, Usability, Performance. Но не стоит сразу отбрасывать этот вариант только по причине изменения уровня зарплаты. Думаю, учитывая предыдущий бэкграунд в тестировании, вам, возможно, предложат больше, чем обычным джунам, и ценить как специалиста будут выше. Особенно если это переход в пределах компании.

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

Итог

В качестве завершения хотелось бы отметить, что вопреки расхожему мнению тестирование как профессия не умерло. Даже такие продвинутые компании, как Facebook, Google, Microsoft, Apple и Amazon, набирают на работу специалистов по качеству. Например, Amazon вообще ищет Manual QA, и требования не выглядят заоблачными. А вот вакансия от Microsoft для специалиста с опытом от 5 лет, из них всего 1+ опыта в автоматизации (это не очень сильный автоматизатор, и фокус работы будет, скорее всего, не на автоматизации). Также требуются хорошие знания Linux, методологий и тестовой документации. Вакансия не сильно отличается от обычных вакансий на Djinni. Похожая ситуация в Apple. Но тут нужно будет чуть лучше разбираться в программной части (писать фреймворки, дебажить код). В Google требования на эту конкретную вакансию еще выше. Но это случайно выбранные вакансии. В разные команды нужны специалисты разного уровня. Также очевидно, что формальное соответствие требованиям не гарантирует приглашения, но работа в таких компаниях, думаю, стоит усилий, затраченных на подготовку. Я бы, например, сделал это чисто из интереса. Кто знает, возможно, это когда-то даже станет темой еще одной статьи.

LinkedIn

14 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

По линкедину распространяется вот это
www.linkedin.com/...​ivity:6623545579882496000

Активно распространяется, местами уже с потерей указания первоисточника. И чувак говорит правильные вещи: тестирование — это задавать, блеать, вопросы, а не ранить тесты руками, ногами или роботами.

Как развиваться тестировщику, если не привлекает автоматизация

Об стену?
Мне вообще кажется дикой концепция нелюбви профессионала к автоматизации какого-либо процесса в своей работе. Если только это не профессионал в порноиндустрии, где сам процесс приносит удовольствие.

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

Благородному мануальщику об код руки марать не пристало.

Вы не упомянули другое огромное заблуждение: тест-дизайн, который одолевают на ±30% и даже не знают о том, что там дальше находится. То есть, развиваться по ветке функионального тестирования можно десятилетиями, и финиша всë не видно.

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

Спасибо за статью.
Действительно — если не хочется в автоматизацию (разработку) то есть варианты.
Но для грамотного performance / security тестирования нужно знание на уровне разработчика, а то и выше (плюс технический бекграунд).
Тестирование безопасности — это не просто «запустил анализатор — получил автоматически отчет — отправил менеджеру». Это знание веб — технологий, как входные параметры обрабатываются на сервере; как работает внутри приложение для мобильных девайсов и где что может пойти не так. Для вирусного аналитика — умение читать дизассемблированный код — дабы понять — что делает тот или иной вирус.
Тестирование производительности — в любом случае надо будет писать скрипты для нагрузки, профилировать приложения — и тут без знаний как работает код не обойдешься.
Вывод: в большей половине экспертной ветки для тестировщика — так или иначе писать и понимать код — это крайне важно. Просто знания кода нужны специфические.

P.S. Везде на вакансии этих самых FAANG — тестировщика сначала погоняют по алгоритмам, структурам данных и прочему. А потом — написать тесты и обьяснить — где потенциально может быть проблемы. На чем нужно их писать — на каком-то языке программирования.
А то что там написали Manual QA — совершенно ни о чем не говорит.
Вот требования на тест инженера в Гугле:
— Lead/collaborate on improving developer and engineering team’s test coverage, release velocity and production health
— Work closely with development teams in instrumenting their workflow to build a comprehensive picture of velocity, coverage and quality
— Hands-on ability to automate repeated tasks and build test coverage through existing or new infrastructure
— Write moderately complex code/scripts to test systems, implementing test harnesses and infrastructure as necessary

Кроме FAANG есть много отличных компаний в LA. Да и в том же гугле, у меня друг там работает, есть проекты где 99% мануальной работы и 1% автоматизации

как с этим:

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

можно разобраться в этом?

Также немаловажным будет глубокое знание продукта, архитектуры, взаимосвязи между компонентами и модулями.

яснопонятно...

Как развиваться примату, если не привлекает эволюция? ©

Что-то я не понял. Если человеку не хочется сильно углубляться в техническую часть, заниматься автоматизацией, писать код и т.д., то что ему делать, например, в Performance Testing или Penetration Testing?

Можливо, автор під автоматизацією мав на увазі тільки Е2Е-тести, тоді все виглядає ± логічно, хоча по статті цього не скажеш, це чисто мої догадки.

А что не так с E2E тестами?

З ними все прекрасно (принаймі в мене). Можливо автору не подобається/нудно/etc написання Е2Е, тому і навіяло на написання статті про performance, security, usability.

для собственного развития можно сдать менее известные и требовательные к наличию опыта сертификации

В одном предложении «собственное развитие» и «менее требовательные» — это, конечно, сильно.

Спасибо за статью, тема очень близка. Как про мне, определиться с выбором проще, если ты либо гуманитарий(тогда в менеджмент), либо технарь (тогда в автоматизацию). Проблема возникает, когда ты частично и гуманитарий и технарь(в моём случае) из-за чего определиться сложнее, + давит аспект того, что автоматизация более востребовательна.
По поводу направлений:
Penetration Testing.
Security Auditing.
Compliance Testing.
В США, возможно, есть такие направления, но в Украине сложно встретить.

Направление UX/UI — тоже достаточно интересная тема. Востребованным является тестирование совместимости с разными браузерами, операционными системами или размерами экранов (Compatibility Testing)

— эммм? 0о

Подписаться на комментарии