Автоматизация тестирование уже давно и прочно вошла в нашу жизнь. И это правильно, так как монотонную и часто повторяющуюся работу лучше всего поручить машине. Но сегодня речь пойдет о ручном тестировании. Есть ли оно или нет? И если есть, то в каком направлении. И вообще, чего стоит ждать в 2023 году, тем кто тестирует в ручную. Да и тем кто собирается стать тестером, я думаю тоже будет интересно узнать какие перспективы у тестирования без применения автоматизации.
Рынок труда
Я думаю что выскажу достаточно простую и понятную мысль, сказав что требования к чему либо растут из года в год. Допустим, если лет 25 назад игру можно было запустить с дискетки 1,44 МБ, то сейчас нужен более емкий носитель информации. Требования к компьютерному железу так же растут в геометрической прогрессии. Жизнь не стоит на месте. Безусловно это касается и тестирования. Я бы даже сказал, что к тестированию это относится в большей степени, чем к чему либо, например к программированию. И объясню почему. Все достаточно просто. Если молодой человек захочет получить профессию программиста, он пойдет в университет, где все давным давно регламентировано и упорядочено. Что же происходит с тестированием? В университетах нет такой специальности как тестер программного обеспечения. Конечно вы можете закончить курсы, либо выучиться самостоятельно. Но ведь именно это и порождает некий хаос в требованиях к этой профессии при найме.
Допустим вы увидели вакансию ручного тестирования. На сегодняшний день, в 90 процентов случаев, заглянув внутрь в описания, вы увидите требования по автоматизации. Вакансия на ручное, а требуется автоматизация? Дело в том, что описание вакансии составляется с прицелом на будущее. То есть прямо сейчас, возможно и не требуется писать автоматизированные тесты, но в будущем есть большая вероятность, что такая необходимость появится. Да и не солидно как-то составлять требования к кандидату состоящие из пары строк по знаниям тест-кейсов и баг-репортов. Отсюда можно сделать вывод, что требования зачастую завышены и можно смело подаваться на вакансию, обладая только частью этих знаний. Ведь вы, как и компании публикующие такие вакансии, возможно в будущем будете писать код для автоматизации своих тестов на регрессию. Я уверен, что в каждом человеке заложен безграничный потенциал к саморазвитию. Нужна только сильная, дружная команда и интересные проекты, чтобы этот потенциал раскрыть.
Таким образом, при повышающейся планке вхождения в новую профессию, спрос на ручных тестеров до сих пор остается. И в процентном соотношении он не только не уменьшается, а я бы даже сказал увеличивается. Дело в том, что хороших специалистов автоматизаторов не бывает не пристроенных. Нельзя просто так сказать, нам в команду нужен крутой автоматизатор и в течение месяца он у вас появился. Это из разряда фантастики. Есть только один способ сделать это быстро, а именно переманить его из другой компании. Но для этого необходимы достаточно большие ресурсы, которые не всякая компания захочет выделять. Но выход все же есть. Выращивать своих специалистов. И вот тут-то мы и подходим к самому главному, а из кого выращивать? Конечно же из ручных тестеров, которые уже в этой профессии.
Ручное тестирование будет жить всегда
Еще один очень важный момент, который позволяет судить о том что ручное тестирование не умрет никогда. Автоматизируются уже созданные тестовые сценарии, а не наоборот. Эти сценарии должен кто-то создать и подготовить. И для этого как нельзя лучше подходит ручной тестер. Ведь именно он лучше всех знает трестируемый сервис изнутри. Вы можете сказать, что это может сделать и тестер, который автоматизирует. И да и нет. Для компании это получается слишком дорогое удовольствие. Во-первых, тогда он должен досконально изучить наш сервис. Что не всегда возможно. Во-вторых, его ресурс обходится банально дороже, для компании. Так как все мы знаем, что зарплата автоматизатора выше зарплаты ручного тестера. И тратить его время на создание тестовых сценариев просто нецелесообразно.
К тому же, автоматизировать тесты не всегда целесообразно. Возможно это небольшой проект и затраты на автоматизацию буду несоизмеримо выше. Бывают ситуации, когда автоматизировать просто не представляется возможным из-за большого количества предусловий. В интернете вещей тоже достаточно сложно и трудоемко проходит автоматизация, ввиду специфики тестирования.
Сами автотесты тоже могут содержать ошибки. Так что теперь, писать тесты на автотесты? Так можно попасть в бесконечный цикл. Да и эффект пестицида никто не отменял. Получается нельзя заавтоматизировать все тестовые сценарии и на этом успокоиться. Необходимо постоянно придумывать новые и корректировать уже имеющиеся. А для этого мы опять возвращаемся к ручному тестированию.
Тестирование юзабилити не возможно автоматизировать в принципе. Это должен выполнять человек. И ручной тестер подходит для этого как нельзя лучше. Вы можете сказать, что появились нейросети и машинное обучение. Но это создано и натренировано в первую очередь человеком, на основе тех или иных сценариев. Поэтому применить это в тестировании юзабилити практически невозможно.
Итоги
К чему же мы с вами в итоге пришли? Вы можете сказать, что я обрисовал слишком радужную картинку ручного тестирования, но на самом деле такова реальность. Уже в течение многих лет идут постоянные разговоры, что ручное тестирование умрет и вся работа уйдет в автоматизацию. Но оно живее всех живых. Да требования к нему значительно выросли, но это таковы издержки нашей жизни. Жизнь не стоит на месте. Нет ничего вечного. Отсидеться не получится. Нужно постоянно развиваться в профессии и стремится узнавать что-то новое. В этом залог нашего с вами успеха.
В заключение хочу пригласить вас на бесплатный вебинар курса Java QA Engineer. Professional, где мы разберемся с технологией docker-compose. Так же рассмотрим инфраструктуру CI/CD на основе Jenkins и поднимем Jenkins как docker-compose сервис. Разберем как подключить Jenkins сборщики в docker контейнерах и в чем их преимущество перед сборщиками запущенными как Java процессы. Ну и конечно же возьмем написанные функциональные API тесты, подключим к ним allure reporter и напишем шаблон сборки для jenkins и pipeline на groovy, где определим этапы сборки и запуска API тестов и напишем нотификацию в telegram через HTTP клиент.
Комментарии (8)
DmitryKoterov
04.02.2023 21:44+1«А прежде чем выкатывать, ты эту фичу протестировал»?
«Пользователи протестируют!»
(C)
funca
04.02.2023 23:29Вакансия на ручное, а требуется автоматизация? Дело в том, что описание вакансии составляется с прицелом на будущее. То есть прямо сейчас, возможно и не требуется писать автоматизированные тесты, но в будущем есть большая вероятность, что такая необходимость появится.
Нужны тестировщики, которые умеют автоматизировать свою работу уже прямо сейчас, пользуетесь готовыми решениями. Там нет задачи автоматизировать все подряд. Чаще это какая-то рутина, связанная с прогоном стабильных регрессионных сценариев, которые они выполняют из раза в раз. Для тестирования Web приложений есть no-code/low-code инструменты, где достаточно понимать программирование буквально на уровне школьной программы.
yapaxi
На мой взгляд, разделение тестировщиков на автоматизиторов и ручных очень условное. Ручные тестировщики тоже пишут много "кода", только этот код выглядит как текстовые сценарии интерпретируемые человеком. При наличии навыков автоматизации, такие сценарии можно заменить реальным кодом; особенно удобно, если авто-тесты пишут в том числе и разработчики: это позволяет обучать тестировщиков навыкам рефакторинга, или как минимум поддерживать сценарии в актульном состоянии.
Покрытие - сложный вопрос. Лучше меньше покрывать и чаще запускать, чем покрывать всё и запускать только по праздниками или выборочно. Избыточное покрытие приводит к медлительности тестирования, которое приводит к желанию запускать меньше или выборочно, что, в свою очередь, сводит на нет пользу от полного покрытия.
Был случай, когда мы наняли тестировщика, который, мягко говоря, преувеличил свои навыки автоматизации. Через пару месяцев работы бок о бок с разработчиками его навык уже позволял работать самостоятельно. В изоляции он бы не выжил.
Высокая скорость разработки и короткие итерации позволяют фокусироваться на самых важных для бизнеса вещах. Разработка должна отговаривать тестирование впадать в крайности и тестировать всё, до чего руки дотянутся. Это всё из той же оперы, что и "проектирование наперёд" и "абстрактные фабрики абстрактых фабрик" в разработке: приводит только к увеличению стоимости изменений и рефакторинга, а ощущать "рефакторинг" как что-то болезненное нельзя ни в коем случае.
Понятно, что чем меньше покрытие, тем больше вероятность пропустить баг, но разработчики со стажем знают в каких сценариях они часто ошибаются и могут направлять тестирование на самые злачные кейсы.
В конце концов, нужно больше общаться и меньше впадать в крайности.
SergeiShaikin Автор
Спасибо огромное за такой развернутый комментарий. Очень много холиварных вопросов затронуто. Последнее утверждение поддерживаю обеими руками.