Home

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

Я уже говорил об этом, многие высказались еще до меня, и я надеюсь, что множество людей будет вновь и вновь говорить об этом в будущем:

«Тест-автоматизация – это разработка ПО».

По сути это правда, но мне кажется, что в отрыве от контекста эта фраза ничего не значит. Она хорошо смотрится в качестве твита или поста в LinkedIn, но на этом и все. Это, конечно, верно для большей части содержимого социальных сетей в целом, но я не хочу нападать на социальные сети и качество (или его отсутствие) контента там. Возможно, поговорим об этом в другой раз.

Я хочу поговорить о том, что мало кто действительно глубоко разбирается в последствиях того, что тест-автоматизация – «это разработка ПО». Я немного затрагивал эту тему ранее – в основном рассуждая о том, почему было бы неплохо изучить базовые принципы программирования.

Сегодня я хочу развить ёмкую фразу «тест-автоматизация – это разработка ПО» далее; если конкретно, поговорить об одном следствии из нее. Если тест-автоматизация – это разработка ПО, то вы, работая над созданием автоматизированных тестов, становитесь разработчиком.

Да-да, вы всё верно прочитали. Вы. Разработчик. ПО.

Прежде чем вы рванете обновлять свои профили в LinkedIn, подумайте, что значит быть разработчиком ПО.

Это значит, что вы должны уметь легко пользоваться широким спектром инструментов и библиотек, зная, когда что из этого применять. Вы же не наймете разработчика, чьим универсальным решением всех проблем будет создание еще одного Spring-микросервиса, правда? Иногда вам просто нужен другой инструмент или библиотека. То же самое верно для автоматизации: не у каждой проблемы наилучшее решение – это Cypress (Selenium, Playwright, давайте не будем спорить об этом снова).

Это значит, что вы должны иметь практический опыт работы с инструментами, переносящими код из ноутбука на прод. Сразу приходит в голову контроль версий, CI/CD, технологии контейнеризации. Я бы не стал нанимать разработчика, который пишет блестящий код, а затем замирает, как олень в свете фар, когда просишь его сделать этот код рабочей частью релиза. То же верно и для автоматизации: вне зависимости от гениальности ваших тестов они не имеют смысла, пока не прогоняются при любой необходимости на чужой машине. Сможете ли вы заставить свои тесты так работать?

Это значит, что вам нужно научиться делать все, чего вы ожидаете от разработчиков. Заниматься парным программированием. Участвовать в обсуждениях проектирования и архитектуры (включая тестируемость и наблюдаемость, да?) Тестировать код перед коммитом. Да, вы все правильно прочитали. Код ваших тестов – это код, и, следовательно, его тоже нужно тестировать. Мы первые бежим жаловаться на разработчиков, которые недостаточно тестируют, но многие ли из нас могут честно сказать, что правильно тестируют код своих собственных тестов?

Да, и, прежде чем вы спросите: все это применимо и к тем, кто использует малокодовые инструменты для автоматизации. Использование таких инструментов не делает автоматизацию менее похожей на разработку – вы просто добавляете еще один уровень абстракции. Это все еще код. И в конечном счете все это ПО, и обращаться с ним нужно соответственно.

Список можно продолжать. Я, к примеру, уже вкратце упоминал о фундаментальных (объектно-ориентированных) навыках программирования. Но список на этом не заканчивается.

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

Фраза «тест-автоматизация – это разработка ПО» также имеет последствия для команд и организаций, нанимающих тест-автоматизаторов. Разговаривая с компаниями, которые стремятся расширить свой набор навыков, я спрашиваю, знают ли они, что конкретно ищут. Как правило, они отвечают «мы ищем кого-то с 3-5-летним опытом работы с Selenium (Cypress, Playwright, боже, как это утомительно) и Java». Зачастую они не сознают, что знание этих инструментов и языков еще не делает человека хорошим автоматизатором. Как я пытаюсь подчеркнуть в этой статье, ему необходимо множество фундаментальных навыков разработки. Подумайте об этом, нанимая автоматизатора!

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

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