Путь тестировщика: из “ручников” в автоматизаторы

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

Дисклэймер: своей статьей я ни в коем случае не хочу задеть кого-то из тестировщиков. Я очень уважаю “ручников” и сам начинал свой путь с ручного тестирования.

Я работаю руководителем отдела тестирования около двух лет. В последнее время ко мне на собеседования приходит много автоматизаторов, не имеющих базы в тестировании. У них есть опыт автоматизации как таковой. Но в своей работе они всегда полагаются на чужой тест-дизайн (выполненный “ручниками”).
В идеальном мире эти навыки соответствуют задаче: функциональные тестировщики прорабатывают тест-кейсы и фактически формулируют задачи на автотесты. Автоматизатору остается описать то, что он видит. Но на реальных проектах автоматизатору приходится немного глубже погружаться в суть вопроса. Если задача требует каких-то собственных навыков дизайна, автоматизатор без базы в тестировании предпочтет сделать все по наитию, просто потому что ему так кажется правильным. Зачастую это приводит к тому, что одни кейсы проверяются дважды, другие не проверяются вовсе.
Повторюсь, я не хочу никого обидеть. Но обилие подобных кандидатов заставило лишний раз взвесить, какие же факторы важны в работе QA. И тут напрашиваются три вывода:

• на реальных проектах автоматизатору нужны навыки “ручника”;
• “ручник”, который развивается, рано или поздно уйдет из ручного тестирования, возможно, в автоматизацию;
• путь от “ручника” к автоматизатору — это путь к большей самостоятельности, которая хорошо коррелирует с удаленным форматом работы.

Остановлюсь немного подробнее на каждом из них.

Зачем автоматизатору опыт “ручника”?

Как я уже отметил в самом начале, автоматизатору нужна некоторая теоретическая база. Но я не говорю о каком-то определенном образовании. Нужен опыт практического анализа реальных приложений.
Чтобы проверить очередную фичу, которая готовится на продакшн, функциональные тестировщики анализируют спецификацию в попытках закрыть большую часть кейсов. Они учатся тому, чтобы покрыть максимальное количество кейсов и возможных проблем с минимальными затратами времени (как своего, так и, условно говоря, процессорного). В тестировании это один из базовых навыков — как ходьба. А как говорится, если ты не умеешь ходить, ты не сможешь и в футбол играть (автоматизировать).
Автоматизатор, который миновал стадию ручного тестирования, зачастую умеет просто писать код. Но этого мало. И в двух словах всю недостающую базу не объяснишь. Чтобы ее получить, нужно обратиться в сторону функционального тестирования, как бы странно это ни звучало. Мы же в первую очередь тестировщики, а уже потом автоматизаторы.

Стоит ли “ручнику” идти в автоматизаторы?

В свое время автоматизация привлекла меня тем, что в отличие от ручного тестирования, задачи в ней не столь однообразны. В роли ручника мне было скучно. Всегда хотелось что-то сделать, чтобы сократить рутину. А от автоматизации я получал кайф.
Еще будучи ручником, я начал использовать Selenium IDE (по-моему, он до сих пор жив), позволяющий записывать производимые вручную действия. Он автоматически формировал из них своего рода скрипт с автоматически найденными локаторами. Когда я с ним экспериментировал, все выглядело довольно топорно, иногда падало, но именно Selenium IDE натолкнул меня на мысль: а почему бы не написать что-то самостоятельно? Идею я реализовал в магистерской работе, а потом уже пошел работать автоматизатором.

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

Третьего пути нет — только за пределы QA. Если ты продолжаешь развиваться, в ручном тестировании ты не останешься — упрешься в потолок задач. Да, ты можешь прокачаться, допустим, как специалист по тестированию “white box”. Но с вероятностью 99% в определенный момент тебе станет интереснее творить что-то за рамками тестовой документации. И либо ты выберешь один из двух путей, упомянутых выше, либо вообще уйдешь из тестирования. Например, увлечешься какими-то инфраструктурными задачами, в итоге будешь развиваться уже как devops. А те, кто не замечают или игнорируют в себе это желание идти дальше, по моему опыту, довольно быстро “подтухают”.
Кстати, и зарплаты, что у автоматизаторов, что у менеджеров — повыше (это если вспоминать о материальной стороне вопроса).

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

Из “ручников” в автоматизаторы — путь к удаленке

Раз уж мне довелось работать в разных секторах тестирования полностью удаленно, хочу и здесь поделиться своим опытом. У “ручника” и автоматизатора немного разный пул задач, от этого они ощущают себя в формате удаленной работы по-разному.

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

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

Доводилось ли вам переходить между ИТ-направлениями? Как вы выбирали свой путь?

Автор статьи: Руслан Абдулин

Эта статья — третья часть нашего цикла публикаций о карьере ИТ-шника.
Первая часть здесь.
Вторая часть здесь.

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.

Помогите нам сделать статьи в блоге более интересными: Ответьте, пожалуйста, на три вопроса.