В области автоматического тестирования я работаю уже 15 лет. За это время я работал как в крупных компаниях, так и в небольших стартапах. Использовал различные языки программирования и технологии. Был частью разных команд — от специализированных групп разработчиков автоматического тестирования до смешанных команд, где вместе работали и разработчики, и тестировщики. За время карьеры занимал различные позиции и дорос до Senior Automation Engineer.

Что такое автоматическое тестирование?

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

Автоматическое тестирование на самом деле включает создание различных видов тестов — юнит, функциональных, интеграционных, нагрузочных и других — и настройку их автоматического запуска при каждом изменении кода продукта.

В индустрии разработки автоматическое тестирование часто воспринимают как часть QA — просто автоматизированную форму ручного тестирования. Из-за этого его считают менее серьёзной разработкой.

К тому же, многие разработчики не любят писать тесты. «Зачем проверять то, что и так работает? Скукота», — думают они.

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

В современной разработке автоматизация — неотъемлемая часть CI/CD процесса.

Кто такой инженер и почему он уже не девелопер?

В IT области все очень вольно в плане раздачи званий и специальностей. Я иногда встречал инженеров которые по уровню знаний были разработчиками. Нет определённого критерия присвоения звания инженера, часто инженера могут присвоить за выслугу лет(опыт), а не за навыки. К счастью, на интервью все встаёт на свои места и часто выясняется, кто чего заслуживает и что знает.

Находясь в таком плюрализме присвоения званий, я в какой-то момент задал вопрос себе, кто я по уровню знаний и опыта?

Помогла полезная книга, которую я прочитал «Code That Fits in Your Head: Heuristics for Software Engineering».

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

Какими же навыками должен обладать инженер автоматического тестирования?

Теоретические особенности инженера определили. Теперь, что же конкретно должен знать инженер? Ниже я привожу своё мнение основанное на моем личном опыте и наблюдениях.

Код

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

Люди без опыта разработки, а только прошедшие курс программирования на каком-нибудь языке не создадут вам автоматического тестирования. Они создадут вам головную боль.

Разработчики тестируемого продукта должны участвовать в код ревью кода автоматического тестирования. Таким образом вам помогут в понимании способов тестирования продукта и вы поможете привить навыки тестирования разработчикам, что может снизить вам нагрузку в работе. Именно, разработчики тоже должны писать тесты и не только юнит тесты.

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

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

Качество кода определяет качество создаваемого продукта. А если создаваемый продукт тестирует качество, то качество кода должно быть вдвое лучше.

Искусство тестирования

• стабильны

• не зависят от изменений в тестируемом продукте

• информативны

• лаконичны

• быстрые

• независимы от других тестов

• легко-изменяемы

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

Когда тесты это часть CI/CD процесса, никто не хочет ждать долго результатов и ни у кого нет терпения на часто падающие тесты с неясными причинами.

Такая способность создания и организации тестов появляется только с опытом.

DevOps

Как уже отмечалось, автоматическое тестирование сегодня это часть процесса CI/CD. Т.е. тесты должны бежать не только локально, но и в Докер. А тестовую среду нужно подготовить для CI/CD. И если что-то сломается в этапе тестирования в CI/CD, нужно знать как починить. В общем, инженер должен быть и DevOps не много. Знать как работать с Linux, Docker, Docker Compose, базовые знания и навыки работы с Kubernetes, GitHub Workflows и системы билдов в облачных сервисах, уметь писать скрипты на Bash.

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

Языки

Если вы заметили, в IT постоянно есть модные языки программирования. Например во фронтенде это JavaScript. В бэкенде более разнообразно, но часто тот же JavaScript, Python, Java, Go и прочие.

Инженер обязан знать несколько языков, желательно скриптовых и компилируемых. Чем больше вы знаете языков, тем легче вам выучить новый. Это как и с языками общения.

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

Очень важно, чтобы автоматические тесты были написаны на языке понятном для разработчиков тестируемого продукта. Люди должны понимать и помогать в том, что вы создаёте.

Фреймворки и Технологии

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

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

Есть технологии или методологии с которыми желательно познакомиться, например BDD. Но есть методология в которой нужно быть экспертом — это TDD. Инженер сам должен использовать TDD и если надо, обучать других разработчиков.

Участие в разработке тестируемого продукта

Создание автоматического тестирования продукта должно происходить параллельно созданию самого продукта. Либо продукт можно сделать пригодным к последующему автоматическому тестированию. Все это осуществимо если инженер участвует в обсуждении проектирования и разработке продукта на ряду с другими разработчиками и менеджерами продукта. Любые изменения вносимые в продукт могут повлиять на работу автоматического тестирования, поэтому инженеру важно знать об этих изменениях и быть к ним готовым.

Также важно знать, как продукт будет развиваться, что соответственно проектировать будущие дополнения в автоматическом тестировании.

Короче говоря — проектируйте тестирование продукта на этапе его проектирования.

Саморазвитие и Самосовершенствование

Нельзя знать язык или технологию без опыта их использования. Т.е. курсы или книга не даст вам знания языка. Языком овладевают опытным путём. Рабочее время не всегда предоставляет такую возможность. Поэтому полезно заниматься иногда pet projects. Это помогает опробовать новые технологии, языки или просто получить полезный опыт, который может в будущем пригодиться. Это также позволяет держать себя в креативной форме.

Важно также иметь представления о вещах не связанных с автоматическим тестированием, но активно использующиеся в IT области. Например, виды и принципы архитектуры, различные методологии разработки.

Это помогает глубже понимать тестируемый продукт и эффективно планировать его автоматическое тестирование.

Примеры из личного опыта:

• благодаря постоянному личному использованию Linux я узнал, что такое checksum и часто использовал в тестировании вместо визуальных проверок.

• знакомство с Си и системным программированием позволило мне написать небольшую программу тестирующую использование памяти веб аппликации в процессах браузера.

Эксперт всегда должен знать больше чем нужно.

Все эти технические навыки очень важны и помогают в работе и построении карьеры.

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

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

Ответственность

Вы инженер — вы планируете, создаёте, продумываете. За это вас уважают и ценят. Но с вас и спрашивают и вы несёте ответственность за все, что вы создали. В том числе и за ошибки и просчёты. Будьте готовы к этому или подумайте — надо ли оно вам?

Коммуникабельность

Автоматическое тестирование связано со многими отраслями разработки, как вы уже поняли из статьи. Т.е. вы должны быть знакомы со многими людьми из этих областей на вашей работе. Это похоже на политику или дипломатию, но знакомство и хорошие связи могут вам очень сильно помочь и сэкономить время. Реальность такова, что даже если вы талантливый программист и во всем, что связано с разработкой, кодом, дизайном, инжинирингом вас боженька в темечко поцеловал, но вы не коммуникабельный человек — вам будет очень сложно. Естественно, не везде. Но IT это работа коллективная и тут коммуникабельность часто выше тех. способностей.

Как пример, использование data-testid в автомации фронт-енда. Добавлять data-testid в тестируемый продукт могут только разработчики этого продукта. Или тестировщик, но только если ему доверяют и контролируют разработчики. Получается, что данный пример завязан на лично общении и взаимодействии.

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

Помощь другим

Способность накапливать опыт и передавать его другим это ключевая способность в развитии человечества.

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

Иногда разработчики хотят тоже создавать свои тесты и вы им можете очень помочь в этом.

Вообще говоря, тесты должен писать тот, кто создает продукт, потому что только он или она знают как именно его тестировать.

Короче говоря — научился сам, научи другого.

Смена места работы

Роль ИИ в работе инженера автоматического тестирования

ИИ сегодня используется везде и широко и даже иногда шире чем нужно.

Сможетли ИИ заменить инженера автоматического тестирования? Если будет обладать всеми выше перечисленными навыками, то — да. Но не сегодня, это точно.

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

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

Сегодня один интеллект — хорошо, а два — лучше!

Заключение

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

Поэтому, учится нужно постоянно. Это прибыльно и говорят, даже полезно для мозга.

Самое главное, это любить то, что ты делаешь, совершенствоваться и быть в ладу с теми, с кем работаешь.

Литература которая на меня повлияла:

• Growing Object‑Oriented Software Guided by Tests

• “Clean Architecture. A Craftsman's Guide to Software Structure and Design” by Robert C. Martin

• “Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin

• “The Pragmatic Programmer: From Journeyman to Master” by Andrew Hunt, David Thomas

• “Code That Fits in Your Head: Heuristics for Software Engineering” by Mark Seemann