Comments 14
Руслан, вы из своего сравнительно небольшого опыта работы в одной компании делаете категоричный вывод, что нет третьего пути, кроме как в менеджеры или автоматизаторы. Это всё равно что график по одной точке построить. «С вероятностью 99%» — как считали? Хороший тестировщик обычно умеет абстрагироваться от своего опыта и широко посмотреть на мир. В частности, далеко не все компании занимаются аутсорсом и разработкой ПО на заказ, как ваша, и работа тестировщика далеко не всегда сводится к проверке соответствия продукта заранее известным требованиям документации. В широком смысле QA-инженер — это именно специалист по качеству, он и аналитик, напрямую влияющий на то, как будет выглядеть новая фича, и представление об архитектуре своего продукта имеет, и сложную инфраструктуру развернуть может, и скрипт написать, чтобы какую-то свою рутину автоматизировать, и интересные кейсы от пользователей «раскурить» может, и на совещаниях с коллегами не скучает. На такой работе не выгораешь, я сам работаю в QA больше 4 лет, а некоторые коллеги — по 8-10, не спешат в менеджеры или автоматизаторы и прекрасно себя чувствуют.
Пользуясь случаем спрошу, а входит ли в круг интересов QA инженеров проверка задач в системе постановки и вычитка ТЗ?
Если работать QA инженером после 5 лет интересно, то никто конечно не мешает, но как указал автор статьи, зп на инеженерной позиции меньше, чем у автоматизатора. Отсюда и логичная вилка развития в автоматизаторы или менеджеры
При долгосрочной работе над проектом автотестирование, безусловно, эффективнее, т. к. снижается ручная рутина. Но уходить автотестеру на полную удалёнку, по-моему, невозможно из-за того, что при изменении тестируемого функционала будет меняться и ваша спецификация для генерации тест-кейсов, а для этого надо встречаться с командой разработчиков для различных уточнений.
Спасибо за статью, но все таки хотелось бы уточнить пару моментов.
Проблема неидеальности Вашего реального проекта решается выделением одного QA команде QAA. Таким образом сразу решаются еще и следующие проблемы, если при автоматизации применяется BDD:
Скажу честно, первым делом, когда прихожу в команду автоматизации, договариваемся, что если кейс непонятен, скидываем, либо выделенному 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, поскольку было пересечение проектной специфики и бакалаврской работы.
В идеальном мире эти навыки соответствуют задаче: функциональные тестировщики прорабатывают тест-кейсы и фактически формулируют задачи на автотесты. Автоматизатору остается описать то, что он видит. Но на реальных проектах автоматизатору приходится немного глубже погружаться в суть вопроса.
Проблема неидеальности Вашего реального проекта решается выделением одного 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, поскольку было пересечение проектной специфики и бакалаврской работы.
Третьего пути нет — только за пределы QA.
кажется вы забыли про перфоманс. скилов в нем нужно мн го больше, чем в том же автотестинге, чем не путь развития для QA?
правда большинство ручников этот путь просто не осилят
Добавлю ещё penetration tester. Пригодится опыт тестировщика, плюс знание скриптового языка не помешает, да и вообще подразумевает всестороннее развитие.
А вообще можно стремиться к fullstack-QA. И поавтоматизировать, и вручную хотфикс потестировать, и в команде держать приятную атмосферу, не давая закачикам борзеть и ездить на своих подопечных.
А вообще можно стремиться к fullstack-QA. И поавтоматизировать, и вручную хотфикс потестировать, и в команде держать приятную атмосферу, не давая закачикам борзеть и ездить на своих подопечных.
Почему считается идеальной ситуация, ручные тестировщики пишут тест-кейсы, а автоматизаторы пишут по ним автотесты? По-моему, это плохой паттерн :)
1. Дизайн ручных тест-кейсов и тест-кейсов для автоматизации различается. Сценарии для автотестов нужно нарезать иначе.
2. Ужасно долгий воркфлоу «тестировщик написал тест-кейс — создал задачу автоматизатору — автоматизатор написал тесты». Если в рабочих процессах можно обойтись без лишних рабочих центров и передачи задач между ними — нужно обходиться.
3. Путь развития автоматизатора мне кажется сомнительным. Ты все еще не настоящий разработчик, но и с ручными тестировщиками тебе не по пути. В итоге, ты остаешься один или с несколькими такими же, как ты. Тебе не у кого учиться и вместо best practices написания кода ты учишься странному.
Почему не стремиться к тому, чтобы тестировщики делали всё: писали сценарии и писали автотесты? Это даже не утопия, я видел такие команды.
1. Дизайн ручных тест-кейсов и тест-кейсов для автоматизации различается. Сценарии для автотестов нужно нарезать иначе.
2. Ужасно долгий воркфлоу «тестировщик написал тест-кейс — создал задачу автоматизатору — автоматизатор написал тесты». Если в рабочих процессах можно обойтись без лишних рабочих центров и передачи задач между ними — нужно обходиться.
3. Путь развития автоматизатора мне кажется сомнительным. Ты все еще не настоящий разработчик, но и с ручными тестировщиками тебе не по пути. В итоге, ты остаешься один или с несколькими такими же, как ты. Тебе не у кого учиться и вместо best practices написания кода ты учишься странному.
Почему не стремиться к тому, чтобы тестировщики делали всё: писали сценарии и писали автотесты? Это даже не утопия, я видел такие команды.
Почему считается идеальной ситуация, ручные тестировщики пишут тест-кейсы, а автоматизаторы пишут по ним автотесты? По-моему, это плохой паттерн :)
Паттерны решают проблему. Есть ситуации, в которых данный паттерн не применим — небольшие проекты в разработке, которых принимает участие не больше 3 команд(10 DEV, 6 QA). Если проект крупный с четким разделением зон ответственности(DEV, DevOps, ItOps, BA, QA,...), то выделение команды QAA логичный шаг.
Дизайн ручных тест-кейсов и тест-кейсов для автоматизации различается. Сценарии для автотестов нужно нарезать иначе.
В идеальной ситуации не различаются. Думаю уже есть команды, которые смогли реализовать Cucumber(любой BDD с Gherkin синтаксисом) first подход и наслаждаются жизнью.
Ужасно долгий воркфлоу «тестировщик написал тест-кейс — создал задачу автоматизатору — автоматизатор написал тесты». Если в рабочих процессах можно обойтись без лишних рабочих центров и передачи задач между ними — нужно обходиться.
Современный тенденции говорят об обратном. Из последнего разделение Dev на backend, frontend, database, devops. Разделение позволяет писать более качественный код.
Путь развития автоматизатора мне кажется сомнительным. Ты все еще не настоящий разработчик, но и с ручными тестировщиками тебе не по пути. В итоге, ты остаешься один или с несколькими такими же, как ты. Тебе не у кого учиться и вместо best practices написания кода ты учишься странному.
Все зависит от руководителя и от личностных качеств работника, но во большинстве случаев, как бы это грустно не звучало, все именно так. Исходя из личного опыта, можно подойти к DevTeam Lead любой команды и попросить, чтобы он проводил code review и составил план обучения. Чтобы быть отличным автоматизатором, ты должен быть хорошим разработчиком.
Почему не стремиться к тому, чтобы тестировщики делали всё: писали сценарии и писали автотесты? Это даже не утопия, я видел такие команды.
QAA должен обладать определенными знаниями, которыми QA не обладает:
- Знание принципов написание поддерживаемого кода (SOLID, DRY, KISS, ...) — иначе через два года можете прийти к выводу, что проще переписать с 0, чем это поддерживать
- Знание языка, на котором пишет, компилятора/ интерпретатора/ runtime среды ...
- Знание инструментов автоматизации.
Без этих навыков невозможно написать стабильную, масштабируемую систему исполнения тестов.
Почему не стремиться к тому, чтобы тестировщики делали всё: писали сценарии и писали автотесты? Это даже не утопия, я видел такие команды.
Да, к этому можно стремиться, но если тестировщик занимается ещё и пусконаладкой на объекте, то требовать от него ещё и быть специалистом в автотестировании сложно. На такое способны не все.
Sign up to leave a comment.
Путь тестировщика: из “ручников” в автоматизаторы