Как развиваться тестировщику, если не привлекает автоматизация
Всем привет! Для многих людей начало года — хороший период, чтобы подумать о своем будущем, в том числе о карьере и профессиональном развитии. В этой статье я хотел бы поделиться своим видением того, какие возможные варианты роста есть у условного 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 требования на эту конкретную вакансию еще выше. Но это случайно выбранные вакансии. В разные команды нужны специалисты разного уровня. Также очевидно, что формальное соответствие требованиям не гарантирует приглашения, но работа в таких компаниях, думаю, стоит усилий, затраченных на подготовку. Я бы, например, сделал это чисто из интереса. Кто знает, возможно, это когда-то даже станет темой еще одной статьи.
