Что ждет ручное тестирование в 2023 году

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Автоматизация тестирование уже давно и прочно вошла в нашу жизнь. И это правильно, так как монотонную и часто повторяющуюся работу лучше всего поручить машине. Но сегодня речь пойдет о ручном тестировании. Есть ли оно или нет? И если есть, то в каком направлении. И вообще, чего стоит ждать в 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 клиент.

  • Бесплатный вебинар

Источник: https://habr.com/ru/company/otus/blog/714188/


Интересные статьи

Интересные статьи

Программное обеспечение развивается с течением времени, и автоматизированное тестирование является необходимым условием для непрерывной интеграции и непрерывной доставки. Разработчики пишут разли...
Привет! Меня зовут Александра, я работаю в отделе тестирования производительности Тинькофф. Мы продолжаем наш цикл статей, посвященных работе Gatling с различными протоколами. Ранее мы уже рассмотрели...
Недавно команда Google Project Zero опубликовала подробный отчет об обнаружении уязвимостей нулевого дня в 2021 году. Такие отчеты Project Zero готовит с 2014 года, пытаясь оценить эволюцию угроз нуле...
Статья представляет собой туториал для разработчиков на .NET и описывает способы, которыми можно упростить создание юнит-тестов для больших (и не очень) проектов с табличными данными или списками слож...
Привет, хабровчане!Меня зовут Нурыев Асхат, я ведущий инженер по автоматизации в DINS. За время работы в компании я участвовал в решении множества сложных задач. В этой статье я поделюсь историей улуч...