Home

Оригинальная публикация

В последнее время все чаще слышу от коллег из других организаций о курсе на автоматизацию. Чаще всего это выражается в обучении за счет компании всех желающих мануальных тестировщиков автотестированию, т. е. стеку технологий для написания и поддержания автотестов. Помимо языка программирования (чаще Python или Java) изучают Git, Selenium или его аналоги, Jenkins и внутренние регламенты работы с автотестами. В нашей компании так же взяли курс на автоматизацию, в связи с чем возник вопрос — а что же будет с мануальными тестировщиками, откажутся ли от них совсем или будут стремиться сократить их количество?

На данный момент прямых ответов от руководств компаний нет, звучат стандартные фразы, вроде «Пока все остается как есть». Но есть ли профит от доучивания ручных тестировщиков до автотестера, и куда уведет мечта автоматизировать все процессы в тестировании? Расскажу на своем опыте.

Предыстория

Год назад мне предложили обучиться автоматизации, и за скромную прибавку к зп поддерживать автотесты на вверенном мне участке. Сразу скажу, что упавшие автотесты разбираем мы, ручные тестировщики, при этом локализуем ошибку и передаем информацию автоматизатору. Он (или она) в свою очередь правят автотест или подписывают его ошибкой, на чем работа заканчивается до следующего падения. Суть обучения — убрать из этой цепочки автотестировщика, предоставив ему лишь написание новых тестов. Вроде идея здравая — поддерживать автотест не самое сложное занятие, поправил селектор, изменил данные и все взлетело. Как бы не так!

Вернемся к моему обучению. Python’у получилось обучиться примерно за 5 месяцев с 0 до написания хороших таких автотестов с применением Selenium’а. Автотесты получались отличные, проверяющие как отдельно взятый контрол, так и длинную цепь бизнес процесса, по которой работают пользователи. Дело дошло до сдачи зачетов по программированию и автотестам, и тут начались первые проблемы.

Скажу сразу, трезво оценив все За и Против поддержки автотестов мною было принято решение отказаться от этой затеи, и вот почему:

1. Поддержка автотестов занимает просто колоссальное количество времени. Написать автотест гораздо проще и быстрее, чем искать неточность в уже написанном (и чаще всего не тобой). Времени тратилось так много, что проверкой ошибок приходилось заниматься после окончания рабочего дня

2. Переключаться с автотестов на другие задачи приходилось очень часто. За час рабочего времени могут дернуть все — ПМ, разработчик, аналитик и прочие. После консультаций приходилось заново вливаться в разработку автотеста, что так же крадет ценное время. При том автоматизаторы тестирования такими проблемами не страдают, все консультации по функционалу/визуалу выполняют ручные тестировщики

3. Скорость написания самих автотестов оставляла желать лучшего. Круг замкнулся — Из-за поддержки автотестов не хватало времени на прямые обязанности, от этого приходилось часто переключаться на другие задачи, поэтому на разработку автотестов оставалось все меньше и меньше времени. После 10-12 часового рабочего дня не всякий сможет сесть и что-то почитать про автотестирование что бы ускорить свою работу, поэтому скорость написания тестов не росла, а задачи копились

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

Однако, есть и успешные примеры, когда ручной тестировщик смог выделить 2 часа в день на разработку/поддержку автотестов. К сожалению, это исключение из правила, поскольку нагрузка у всех разная. Если вы чувствуете, что у вас есть 2-3 свободных часа в рабочем дне, которые нечем заполнить — то вам прямая дорога в автоматизацию

А теперь самое главное: Почему же ручные тестировщики не могут быть в полном объеме заменены автотестами?

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

Во-вторых, сложность ПО просто не поддается автотестам. Покрыть даже 10-15 шагов тест-кейса уже проблематично, могут возникать различные проблемы (от таймингов до проблем с окружением), ручной тестировщик таких проблем не имеет, проверяя зачастую бизнес процессы, состоящие из сотен шагов.

В-третьих, большинство ПО имеет свойство часто и кардинально меняться. Даже банальный редизайн, проверка которого у ручного тестировщика займет меньше 2-3 рабочих дней положит все автотесты, на поднятие которых потребуется время (хотя хорошие АТ в таких ситуациях поднимаются достаточно быстро).

Так же стоит сказать, что помимо самого тестирования, тестировщик (как это ни странно) занимается огромным количеством дел, будь то консультации по своему функционалу, выяснения сценариев по ошибкам с прода, написание документации, составления отчетов, решения по функционалу, при чем часто на уровне ПМ'а. Не стоит списывать со счетов эти задачи, зачастую они занимают львиную долю рабочего времени.

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

Обсудить в форуме