Ручных тестировщиков часто подталкивают в автоматизаторы, и я считаю этот путь вполне закономерным. Именно так получаются лучшие автоматизаторы. Они в первую очередь неплохие ручники, а уже во вторую — немного разработчики.
В этой статье я поделюсь своим мнением, почему стоит идти именно по этому пути и что будет, если в автоматизацию прийти иначе.
Дисклэймер: своей статьей я ни в коем случае не хочу задеть кого-то из тестировщиков. Я очень уважаю “ручников” и сам начинал свой путь с ручного тестирования.
Я работаю руководителем отдела тестирования около двух лет. В последнее время ко мне на собеседования приходит много автоматизаторов, не имеющих базы в тестировании. У них есть опыт автоматизации как таковой. Но в своей работе они всегда полагаются на чужой тест-дизайн (выполненный “ручниками”).
В идеальном мире эти навыки соответствуют задаче: функциональные тестировщики прорабатывают тест-кейсы и фактически формулируют задачи на автотесты. Автоматизатору остается описать то, что он видит. Но на реальных проектах автоматизатору приходится немного глубже погружаться в суть вопроса. Если задача требует каких-то собственных навыков дизайна, автоматизатор без базы в тестировании предпочтет сделать все по наитию, просто потому что ему так кажется правильным. Зачастую это приводит к тому, что одни кейсы проверяются дважды, другие не проверяются вовсе.
Повторюсь, я не хочу никого обидеть. Но обилие подобных кандидатов заставило лишний раз взвесить, какие же факторы важны в работе QA. И тут напрашиваются три вывода:
Остановлюсь немного подробнее на каждом из них.
Как я уже отметил в самом начале, автоматизатору нужна некоторая теоретическая база. Но я не говорю о каком-то определенном образовании. Нужен опыт практического анализа реальных приложений.
Чтобы проверить очередную фичу, которая готовится на продакшн, функциональные тестировщики анализируют спецификацию в попытках закрыть большую часть кейсов. Они учатся тому, чтобы покрыть максимальное количество кейсов и возможных проблем с минимальными затратами времени (как своего, так и, условно говоря, процессорного). В тестировании это один из базовых навыков — как ходьба. А как говорится, если ты не умеешь ходить, ты не сможешь и в футбол играть (автоматизировать).
Автоматизатор, который миновал стадию ручного тестирования, зачастую умеет просто писать код. Но этого мало. И в двух словах всю недостающую базу не объяснишь. Чтобы ее получить, нужно обратиться в сторону функционального тестирования, как бы странно это ни звучало. Мы же в первую очередь тестировщики, а уже потом автоматизаторы.
В свое время автоматизация привлекла меня тем, что в отличие от ручного тестирования, задачи в ней не столь однообразны. В роли ручника мне было скучно. Всегда хотелось что-то сделать, чтобы сократить рутину. А от автоматизации я получал кайф.
Еще будучи ручником, я начал использовать Selenium IDE (по-моему, он до сих пор жив), позволяющий записывать производимые вручную действия. Он автоматически формировал из них своего рода скрипт с автоматически найденными локаторами. Когда я с ним экспериментировал, все выглядело довольно топорно, иногда падало, но именно Selenium IDE натолкнул меня на мысль: а почему бы не написать что-то самостоятельно? Идею я реализовал в магистерской работе, а потом уже пошел работать автоматизатором.
Путь из “ручников” в автоматизаторы — один из двух возможных. Это развитие по технологической ветке. По мере прокачки навыков ты становишься ближе к разработке. Точно так же ты лезешь в код, только, на мой взгляд, это даже интереснее, чем разработка.
Второй путь — идти по менеджерской линии: стать QA-лидом, потом идти руководить проектом и т.п. Здесь надо прокачивать уже бизнес-скиллы, учиться по-другому смотреть на проекты и тестирование в целом.
Третьего пути нет — только за пределы QA. Если ты продолжаешь развиваться, в ручном тестировании ты не останешься — упрешься в потолок задач. Да, ты можешь прокачаться, допустим, как специалист по тестированию “white box”. Но с вероятностью 99% в определенный момент тебе станет интереснее творить что-то за рамками тестовой документации. И либо ты выберешь один из двух путей, упомянутых выше, либо вообще уйдешь из тестирования. Например, увлечешься какими-то инфраструктурными задачами, в итоге будешь развиваться уже как devops. А те, кто не замечают или игнорируют в себе это желание идти дальше, по моему опыту, довольно быстро “подтухают”.
Кстати, и зарплаты, что у автоматизаторов, что у менеджеров — повыше (это если вспоминать о материальной стороне вопроса).
При этом никто не говорит, что из ручного тестирования надо уходить раз и навсегда. Мне и самому иногда нравится что-то потыкать руками: почитать спецификации, позаниматься старым-добрым тест-дизайном — помочь ребятам из моего отдела. Как я говорил выше, в первую очередь мы — тестировщики.
Раз уж мне довелось работать в разных секторах тестирования полностью удаленно, хочу и здесь поделиться своим опытом. У “ручника” и автоматизатора немного разный пул задач, от этого они ощущают себя в формате удаленной работы по-разному.
“Ручникам”, наверное, немного сложнее найти удаленную работу. Вакансий довольно много, но и конкуренция за них немаленькая — хороших ручных тестировщиков больше, чем хороших автоматизаторов. Но даже если искомая работа получена, ручное тестирование предполагает постоянное общение с коллегами. В процессе написания тестовой документации по чьей-то спецификации возникает масса вопросов: к аналитику, к разработчикам и т.п. Ручному тестировщику приходится выискивать людей и спрашивать их о том, как это будет реализовано. При этом проще работать где-то недалеко, чтобы иметь возможности прийти и пообщаться лично.
Ручник может работать удаленно, если на проекте хорошо выстроены коммуникации или команда полностью распределенная, когда ни у кого нет преимущества в общении. Иначе достучаться до кого-то в офисе будет сложно. Офисные коллеги могут просто уйти в переговорку и вернуться через 2 часа. Ты же все это время будешь пытаться до них достучаться. Вживую-то забыть о человеке гораздо сложнее.
Автоматизатору в этом смысле проще. Его задачи декомпозированы: сиди да пили код. Фактически он может работать обособленно от команды, особенно если это тот самый идеальный проект, где ему предоставляются тест-кейсы от функциональных тестировщиков.
Таким образом, путь из ручников в автоматизаторы — это дорога не только к большим заработкам, но и к удаленке, если в этом есть потребность.
Доводилось ли вам переходить между ИТ-направлениями? Как вы выбирали свой путь?
Автор статьи: Руслан Абдулин
Эта статья — третья часть нашего цикла публикаций о карьере ИТ-шника.
Первая часть здесь.
Вторая часть здесь.
P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.
Помогите нам сделать статьи в блоге более интересными: Ответьте, пожалуйста, на три вопроса.
В этой статье я поделюсь своим мнением, почему стоит идти именно по этому пути и что будет, если в автоматизацию прийти иначе.
Дисклэймер: своей статьей я ни в коем случае не хочу задеть кого-то из тестировщиков. Я очень уважаю “ручников” и сам начинал свой путь с ручного тестирования.
Я работаю руководителем отдела тестирования около двух лет. В последнее время ко мне на собеседования приходит много автоматизаторов, не имеющих базы в тестировании. У них есть опыт автоматизации как таковой. Но в своей работе они всегда полагаются на чужой тест-дизайн (выполненный “ручниками”).
В идеальном мире эти навыки соответствуют задаче: функциональные тестировщики прорабатывают тест-кейсы и фактически формулируют задачи на автотесты. Автоматизатору остается описать то, что он видит. Но на реальных проектах автоматизатору приходится немного глубже погружаться в суть вопроса. Если задача требует каких-то собственных навыков дизайна, автоматизатор без базы в тестировании предпочтет сделать все по наитию, просто потому что ему так кажется правильным. Зачастую это приводит к тому, что одни кейсы проверяются дважды, другие не проверяются вовсе.
Повторюсь, я не хочу никого обидеть. Но обилие подобных кандидатов заставило лишний раз взвесить, какие же факторы важны в работе QA. И тут напрашиваются три вывода:
- на реальных проектах автоматизатору нужны навыки “ручника”;
- “ручник”, который развивается, рано или поздно уйдет из ручного тестирования, возможно, в автоматизацию;
- путь от “ручника” к автоматизатору — это путь к большей самостоятельности, которая хорошо коррелирует с удаленным форматом работы.
Остановлюсь немного подробнее на каждом из них.
Зачем автоматизатору опыт “ручника”?
Как я уже отметил в самом начале, автоматизатору нужна некоторая теоретическая база. Но я не говорю о каком-то определенном образовании. Нужен опыт практического анализа реальных приложений.
Чтобы проверить очередную фичу, которая готовится на продакшн, функциональные тестировщики анализируют спецификацию в попытках закрыть большую часть кейсов. Они учатся тому, чтобы покрыть максимальное количество кейсов и возможных проблем с минимальными затратами времени (как своего, так и, условно говоря, процессорного). В тестировании это один из базовых навыков — как ходьба. А как говорится, если ты не умеешь ходить, ты не сможешь и в футбол играть (автоматизировать).
Автоматизатор, который миновал стадию ручного тестирования, зачастую умеет просто писать код. Но этого мало. И в двух словах всю недостающую базу не объяснишь. Чтобы ее получить, нужно обратиться в сторону функционального тестирования, как бы странно это ни звучало. Мы же в первую очередь тестировщики, а уже потом автоматизаторы.
Стоит ли “ручнику” идти в автоматизаторы?
В свое время автоматизация привлекла меня тем, что в отличие от ручного тестирования, задачи в ней не столь однообразны. В роли ручника мне было скучно. Всегда хотелось что-то сделать, чтобы сократить рутину. А от автоматизации я получал кайф.
Еще будучи ручником, я начал использовать Selenium IDE (по-моему, он до сих пор жив), позволяющий записывать производимые вручную действия. Он автоматически формировал из них своего рода скрипт с автоматически найденными локаторами. Когда я с ним экспериментировал, все выглядело довольно топорно, иногда падало, но именно Selenium IDE натолкнул меня на мысль: а почему бы не написать что-то самостоятельно? Идею я реализовал в магистерской работе, а потом уже пошел работать автоматизатором.
Путь из “ручников” в автоматизаторы — один из двух возможных. Это развитие по технологической ветке. По мере прокачки навыков ты становишься ближе к разработке. Точно так же ты лезешь в код, только, на мой взгляд, это даже интереснее, чем разработка.
Второй путь — идти по менеджерской линии: стать QA-лидом, потом идти руководить проектом и т.п. Здесь надо прокачивать уже бизнес-скиллы, учиться по-другому смотреть на проекты и тестирование в целом.
Третьего пути нет — только за пределы QA. Если ты продолжаешь развиваться, в ручном тестировании ты не останешься — упрешься в потолок задач. Да, ты можешь прокачаться, допустим, как специалист по тестированию “white box”. Но с вероятностью 99% в определенный момент тебе станет интереснее творить что-то за рамками тестовой документации. И либо ты выберешь один из двух путей, упомянутых выше, либо вообще уйдешь из тестирования. Например, увлечешься какими-то инфраструктурными задачами, в итоге будешь развиваться уже как devops. А те, кто не замечают или игнорируют в себе это желание идти дальше, по моему опыту, довольно быстро “подтухают”.
Кстати, и зарплаты, что у автоматизаторов, что у менеджеров — повыше (это если вспоминать о материальной стороне вопроса).
При этом никто не говорит, что из ручного тестирования надо уходить раз и навсегда. Мне и самому иногда нравится что-то потыкать руками: почитать спецификации, позаниматься старым-добрым тест-дизайном — помочь ребятам из моего отдела. Как я говорил выше, в первую очередь мы — тестировщики.
Из “ручников” в автоматизаторы — путь к удаленке
Раз уж мне довелось работать в разных секторах тестирования полностью удаленно, хочу и здесь поделиться своим опытом. У “ручника” и автоматизатора немного разный пул задач, от этого они ощущают себя в формате удаленной работы по-разному.
“Ручникам”, наверное, немного сложнее найти удаленную работу. Вакансий довольно много, но и конкуренция за них немаленькая — хороших ручных тестировщиков больше, чем хороших автоматизаторов. Но даже если искомая работа получена, ручное тестирование предполагает постоянное общение с коллегами. В процессе написания тестовой документации по чьей-то спецификации возникает масса вопросов: к аналитику, к разработчикам и т.п. Ручному тестировщику приходится выискивать людей и спрашивать их о том, как это будет реализовано. При этом проще работать где-то недалеко, чтобы иметь возможности прийти и пообщаться лично.
Ручник может работать удаленно, если на проекте хорошо выстроены коммуникации или команда полностью распределенная, когда ни у кого нет преимущества в общении. Иначе достучаться до кого-то в офисе будет сложно. Офисные коллеги могут просто уйти в переговорку и вернуться через 2 часа. Ты же все это время будешь пытаться до них достучаться. Вживую-то забыть о человеке гораздо сложнее.
Автоматизатору в этом смысле проще. Его задачи декомпозированы: сиди да пили код. Фактически он может работать обособленно от команды, особенно если это тот самый идеальный проект, где ему предоставляются тест-кейсы от функциональных тестировщиков.
Таким образом, путь из ручников в автоматизаторы — это дорога не только к большим заработкам, но и к удаленке, если в этом есть потребность.
Доводилось ли вам переходить между ИТ-направлениями? Как вы выбирали свой путь?
Автор статьи: Руслан Абдулин
Эта статья — третья часть нашего цикла публикаций о карьере ИТ-шника.
Первая часть здесь.
Вторая часть здесь.
P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.
Помогите нам сделать статьи в блоге более интересными: Ответьте, пожалуйста, на три вопроса.
Комментарии (12)
interlocker
28.11.2019 09:36При долгосрочной работе над проектом автотестирование, безусловно, эффективнее, т. к. снижается ручная рутина. Но уходить автотестеру на полную удалёнку, по-моему, невозможно из-за того, что при изменении тестируемого функционала будет меняться и ваша спецификация для генерации тест-кейсов, а для этого надо встречаться с командой разработчиков для различных уточнений.
vrnvorona
28.11.2019 13:34А еще есть вариант тестирования мобилок, там вообще удаленно никак ибо девайсы, а все делать через сим это чушь.
k_valiev
28.11.2019 09:36Спасибо за статью, но все таки хотелось бы уточнить пару моментов.
В идеальном мире эти навыки соответствуют задаче: функциональные тестировщики прорабатывают тест-кейсы и фактически формулируют задачи на автотесты. Автоматизатору остается описать то, что он видит. Но на реальных проектах автоматизатору приходится немного глубже погружаться в суть вопроса.
Проблема неидеальности Вашего реального проекта решается выделением одного QA команде QAA. Таким образом сразу решаются еще и следующие проблемы, если при автоматизации применяется BDD:
- ревью сценариев;
- соответствие сценриев автоматизации и test suite «ручных» тестировщиков;
Скажу честно, первым делом, когда прихожу в команду автоматизации, договариваемся, что если кейс непонятен, скидываем, либо выделенному QA, либо автору. Это минимизирует время потраченное на автоматизацию, так же помогает решить проблему с подбором пересонала, с которой Вы столкнулись:
В последнее время ко мне на собеседования приходит много автоматизаторов, не имеющих базы в тестировании. У них есть опыт автоматизации как таковой. Но в своей работе они всегда полагаются на чужой тест-дизайн (выполненный “ручниками”).
…
Автоматизатор, который миновал стадию ручного тестирования, зачастую умеет просто писать код. Но этого мало. И в двух словах всю недостающую базу не объяснишь. Чтобы ее получить, нужно обратиться в сторону функционального тестирования, как бы странно это ни звучало. Мы же в первую очередь тестировщики, а уже потом автоматизаторы.
Это несправедливо по отношению к разработчикам и DevOps. У меня был опыт, когда Solution Architector захотел поробовать «новенькое» и выстроил архитектуру приложения для e2e тестов и это был однозначно очень ценный опыт. Наличие людей с оптытом в DevOps и/или разработки очень положительно сказывается на системе для автоматизированного тестирования, особенно, если система большая (>5000 сценариев), а запускаться тесты должны часто. Нужны ли в команду автоматизации люди с опытом «ручного» тестирования — нужны, но как мне кажется их количество может составлять (25-30% от команды). Задачи в командах автоматизации очень разные:
1. донастройка тестовых environment(octopus, puppet);
2. подготовка образов(docker);
3. CI;
4. Оптимизация времени прогонов;
5. Уменьшение времени, затрачиваемого на поддержку системы;
6. Тестовая инраструктура далека от идеала, для всего нужны плагины, форки;
7. Ведение документации в wiki;
8. Нагрузочное тестирование;
9. Интеграция со сторонними системами (Allure, Kibana, Jira, ...);
Был опыт, когда один человек писал формулировки сценариев, другой писал реализации, сделало ли это второго плохим автоматизатором? Я считаю нет, он делал все, что я перечислил выше и при этом писал очень качественный код. Я бы все таки предложил разделять зоны ответственности. Regression test suite — лицо «ручных» тестировщиков, все должно быть в идеальном состоянии, чтобы это мог воспроизвести человек без опыта, если это не так, тест кейс должен быть переписан. В этом случае автоматизатору становится необязательно иметь опыт в «ручном» тестировании, а можно сконцентрироваться на своей зоне ответственности. И это не должно быть утопией, как преподнесено в статье(по крайней мере мне так показалось), это должно быть правилом.
Что касается ответа на вопрос статьиДоводилось ли вам переходить между ИТ-направлениями? Как вы выбирали свой путь?
:
Я начинал на позиции jun BA, после закрытия проекта предложили заняться тест дизайном, так я попал в QA отдел, параллельно взял удаленный проект в веб-разработке. Потом перешел в автоматизацию. Там решил развиваться не в менеджерскую позицию, а в техническую, в итоге осуществлял экспетризу в нескольких командах и за полтора года автоматизировал всего 6 кейсов(базовый набор тестов в новой системе). Недавно понял, что настал тот момент, когда накладно мониторить изменения в автоматизации и разработке и перешел в разработчики. Начинал свой путь в BA, поскольку было пересечение проектной специфики и бакалаврской работы.
Brain_Overload
28.11.2019 10:14Третьего пути нет — только за пределы QA.
кажется вы забыли про перфоманс. скилов в нем нужно мн го больше, чем в том же автотестинге, чем не путь развития для QA?
правда большинство ручников этот путь просто не осилятKiryushah
28.11.2019 21:55Добавлю ещё penetration tester. Пригодится опыт тестировщика, плюс знание скриптового языка не помешает, да и вообще подразумевает всестороннее развитие.
А вообще можно стремиться к fullstack-QA. И поавтоматизировать, и вручную хотфикс потестировать, и в команде держать приятную атмосферу, не давая закачикам борзеть и ездить на своих подопечных.
24twelve
01.12.2019 06:21Почему считается идеальной ситуация, ручные тестировщики пишут тест-кейсы, а автоматизаторы пишут по ним автотесты? По-моему, это плохой паттерн :)
1. Дизайн ручных тест-кейсов и тест-кейсов для автоматизации различается. Сценарии для автотестов нужно нарезать иначе.
2. Ужасно долгий воркфлоу «тестировщик написал тест-кейс — создал задачу автоматизатору — автоматизатор написал тесты». Если в рабочих процессах можно обойтись без лишних рабочих центров и передачи задач между ними — нужно обходиться.
3. Путь развития автоматизатора мне кажется сомнительным. Ты все еще не настоящий разработчик, но и с ручными тестировщиками тебе не по пути. В итоге, ты остаешься один или с несколькими такими же, как ты. Тебе не у кого учиться и вместо best practices написания кода ты учишься странному.
Почему не стремиться к тому, чтобы тестировщики делали всё: писали сценарии и писали автотесты? Это даже не утопия, я видел такие команды.
lyapkost
Руслан, вы из своего сравнительно небольшого опыта работы в одной компании делаете категоричный вывод, что нет третьего пути, кроме как в менеджеры или автоматизаторы. Это всё равно что график по одной точке построить. «С вероятностью 99%» — как считали? Хороший тестировщик обычно умеет абстрагироваться от своего опыта и широко посмотреть на мир. В частности, далеко не все компании занимаются аутсорсом и разработкой ПО на заказ, как ваша, и работа тестировщика далеко не всегда сводится к проверке соответствия продукта заранее известным требованиям документации. В широком смысле QA-инженер — это именно специалист по качеству, он и аналитик, напрямую влияющий на то, как будет выглядеть новая фича, и представление об архитектуре своего продукта имеет, и сложную инфраструктуру развернуть может, и скрипт написать, чтобы какую-то свою рутину автоматизировать, и интересные кейсы от пользователей «раскурить» может, и на совещаниях с коллегами не скучает. На такой работе не выгораешь, я сам работаю в QA больше 4 лет, а некоторые коллеги — по 8-10, не спешат в менеджеры или автоматизаторы и прекрасно себя чувствуют.
imater
Пользуясь случаем спрошу, а входит ли в круг интересов QA инженеров проверка задач в системе постановки и вычитка ТЗ?
adictive_max
По-хорошему, должна, т.к. ТЗ часто составляются без оглядки на реальный мир с его глючащим железом, недостоверной документацией и глупыми но сильными пользователями.
ramierl
Если работать QA инженером после 5 лет интересно, то никто конечно не мешает, но как указал автор статьи, зп на инеженерной позиции меньше, чем у автоматизатора. Отсюда и логичная вилка развития в автоматизаторы или менеджеры