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

Тестирование и разработка

Кажется, что все изменения, о которых пойдет речь дальше, вызваны тем, что в целом подходы в ИТ меняются. Еще N лет назад мы тестировали руками по тест-кейсам, записанным в Excel, а сейчас стараемся применять нейронки для увеличения покрытия кода, а порой и вайб-кодим сами автотесты. Все чаще продукты построены не на монолитах, а на микросервисной архитектуре. Мы все больше внимания уделяем инфраструктуре и вкладываемся в автоматизацию во всех сферах.

Команды тестирования придерживаются принципа максимальной модульности. За счет этого тестов стало больше, ими стало сложнее управлять и поддерживать. Все жестче смотрят на неактуальные тесты и тест-кейсы.

Мы стали строже относиться к пирамиде тестирования и соблюдению ее иерархии (кстати, коллега у меня писал об изменениях в этой сфере: https://habr.com/ru/companies/maxilect/articles/824918/). Понятна доля каждого из типа тестов. Отслеживается покрытие и затраты ресурсов (в первую очередь времени) на каждый из этапов.

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

Приятно, что при этом и разработка идет навстречу тестированию. Давным-давно коллеги-разработчики как будто не понимали, зачем мы нужны. А сейчас прониклись и всячески помогают - добавляют отдельные удобные ручки, которые имеют значение только для теста (но не для прода), data-qa тэги для тестирования фронта и т.д.

Несмотря на такое сближение, в целом тестировщики стали самостоятельнее. Они могут сами изучить отчет о тестировании, выудить traceId, по нему посмотреть трассировку в логах, найти ошибки, сбегать в код, передеплоить какие-то сервисы и обратить внимание на алерты об инфраструктурных проблемах. Разработчикам уже не нужно держать тестировщиков за ручку.

Тестирование - уже не такой легкий путь в ИТ

Казалось бы, совсем недавно сформировался стереотип о том, что тестирование - это легкий способ “войти в ИТ”. Но спешу расстроить - мир снова изменился. Объем знаний, необходимый тестировщику автоматизатору для работы, растет. Все сложнее и сложнее быстро войти в курс дела. Да и через ручное тестирование попасть сюда уже не так просто. Некоторые компании полностью отказываются от ручников в пользу фуллстеков.

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

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

• Требуются базовые навыки DevOps и CI/CD, особенно если речь идет о фуллстеках. Им каждый день приходится деплоить из своих веток и веток разработчиков, взаимодействуя с разными инструментами. В крупных компаниях есть уже отдельное направление TestOps - это команды, которые настраивают инфраструктуру для тестирования. Но базовые знания основных инструментов требуют и от рядовых автоматизаторов. Нужны минимальные навыки работы с GitLab. При этом, работодатели ожидают умения не просто запустить процессы, но и посмотреть артефакты. Например, у нас есть некий пайплайн, который триггерится после деплоя. Он сначала собирает клиенты (под каждый - свой job с параметрами), а затем запускает автотесты. И кому-то из тестировщиков в команде необходимо уметь без помощи DevOps делать всю обвязку - писать те самые job и т.п.

• Kafka, Redis, RabbitMQ уже стали инструментами по умолчанию - они активно используются для создания и отслеживания движения тестовых данных. Нужно понимать, как и куда перетекают входные данные, через какие ручки и какими транспортами идут, через какие сервисы.

• А еще не забываем про специфичные инструменты под новые для тестирования задачи. Например, раньше при тестировании на бэке через API мы все прописывали вручную (какой адрес дернуть, какое тело запроса сформировать и с какими параметрами отправить). Теперь же все это делается автоматически, оперативно обновляясь, если разработчики вносят какие-то изменения в сервис. Для этого есть масса инструментов - тот же OpenApi Generator или Protobuf. Естественно, о них также спрашивают на собеседованиях.

Все очень быстро устаревает

Объем необходимых знаний растет, а старые познания в инструментах все быстрее устаревают. Ты что-нибудь учишь, но завтра оно уже не актуально.

Например, для фронта еще вчера мы все учили Selenium. Но его популярность постепенно падает, все чаще используется Playwright. Если раньше мы просто писали тесты и проверяли результаты в браузере, то теперь к обязанностям автоматизатора добавилась работа с DevTools самих браузеров. С их помощью можно эмулировать нестандартные режимы работы - тот же нестабильный интернет, перехватывать запросы, улетающие при нажатии на кнопку, или получить профиль загрузки страницы. Иными словами, теперь мы не просто функционально проверяем, что веб-приложение работает так, как задумано, но и смотрим, как быстро загружается страница и какие ресурсы при этом отрабатывают медленнее всего. Для всего этого нужны уже другие инструменты.

Точно также команды постепенно отказываются от TestNG. Мы на своем проекте все еще его используем, но нас периодически сподвигают переходить на JUnit 5. Он популярнее, многие пути в нем уже протоптаны, а боли пройдены.

Что остается неизменным - так это востребованность так называемой “базы”. Без нее далеко в автоматизации тестирования не уехать. 

Нужны глубокие знания, но на собеседованиях спрашивают “верха”

На постоянно растущий объем необходимых знаний накладывается привычный способ восприятия современного человека: хочется ухватить много всего и как можно быстрее. В итоге джун пробегает много разных инструментов и библиотек по верхам, не изучая глубинные вещи. В том же ключе работает развившееся в последнее время инфоцыганство. В итоге появляется чувство, что он чему-то научился и может решать задачи. Но чувство это обманчиво: как только нужен шаг вправо или шаг влево, знаний уже не хватает. Увы, но таких “специалистов” на рынке довольно много.

Юмор в том, что на такой нехватке знаний построить карьеру не получится. В отрасль полным ходом врываются нейросети. IDE для разработки и тестирования уже подключают ИИ-ассистентов, которые могут написать простой код тестов, тестовые шаги и некоторые обвязки. Пока не все ими пользуются - все-таки отрасль у нас довольно консервативная. Но на фоне развития таких инструментов человек остается востребован для решения именно нестандартных задач. 

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

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на нашу страницу в VK или на Telegram-канал, чтобы узнавать обо всех публикациях и других новостях компании Maxilect.