Как перейти из ручного тестирования в автоматизированное
Процесс погружения в автоматизацию волнует и начинающих специалистов, и опытных инженеров по тестированию. Одни считают, что автоматизация не их конёк, другие — что это трудозатратный процесс, который стоит отложить. В этой статье расскажем, как погрузиться в автоматизацию новичку, а также дадим совет, как начать автоматизировать на проекте.
Отправные точки
Рассмотрим две отправные точки погружения в автоматизацию:
когда начинающий специалист задумался о переходе на этапе обучения или выбрал путь автоматизатора изначально;
опытный инженер в роли Manual QA на проекте.
Изучаем автоматизацию с нуля
Автоматизация тестирования (QA Automation) — это не только про кодирование, но также она охватывает широкий спектр обязанностей, включая разработку тест-кейсов, составление тест-планов, заведение баг-репортов и выполнение других задач, которые традиционно выполняет Manual QA.
На практике роль QA Automation Engineer не сводится исключительно к написанию автотестов по предварительно разработанным сценариям. Важная задача — интеграция автоматизации в общий процесс тестирования. Это требует глубокого понимания функциональности продукта и процессов тестирования. Так, QA Automation Engineer — это не просто специалист по автоматизации, а в первую очередь квалифицированный QA-инженер, способный применять автоматизацию для повышения эффективности тестирования.
Изучать автоматизацию с нуля, не имея представления о ручном тестировании, можно. Однако в дальнейшем будет сложнее без знания основ — как минимум, понимания техник тест-дизайна. Поэтому, предположим, основы вы уже знаете. А что дальше?
Что можно автоматизировать
Сначала определим, что можно автоматизировать. Самое распространённое — API, Web, мобильные приложения.
На второй позиции — Web. Относительно просто для автоматизации, но могут возникнуть сложности с элементами интерфейса (кнопочки, поля ввода, формы).
Самое сложное — автоматизация мобильных приложений. Они имеют сложные графические интерфейсы с различными элементами, например текстовыми полями, кнопками, изображениями. Взаимодействие с UI требует определения элементов и их состояний. Разнообразие платформ и устройств создаёт сложности при разработке универсальных тестов, которые будут работать на всех устройствах. Также есть и другие приложения и технологии, например десктопные, игры, VR, — всё это требует отдельных подходов.
Как сделать первый шаг
Прежде всего, важно освоить основы языка программирования — это будет фундаментом для эффективного написания автотестов. Знание синтаксиса и основных конструкций языка позволяет QA Automation Engineer создавать надёжные и читаемые тестовые сценарии. Без этого понимания сложно в полной мере использовать возможности автоматизации и адаптировать тесты под изменения в коде приложения.
На практике владение основами языка программирования обеспечивает более глубокое понимание внутреннего устройства приложения. Это ключевой аспект в разработке эффективных автотестов. Комбинирование навыков программирования с пониманием бизнес-логики приложения делает специалиста по автоматизации более конкурентоспособным на рынке.
Выбор языка
В области автоматизации тестирования и разработки программного обеспечения используют множество языков. Выбор конкретного языка зависит от различных факторов: типа проекта, требований, опыта команды и предпочтений.
Java — широко используется для написания автоматизированных тестов, особенно с использованием фреймворка Selenium WebDriver.
Python — популярен для автоматизации тестирования Web, API, мобильных приложений. Имеет разнообразные библиотеки, такие как PyTest, Selenium, Appium.
JavaScript — чаще нужен для автоматизации веб-приложений с использованием фреймворков и библиотек, таких как WebDriverIO, Protractor.
Библиотеки и фреймворки
Когда речь идёт о разработке программ, ключевыми инструментами являются библиотеки и фреймворки. Они обеспечивают возможность повторного использования кода, и это делает их полезными для решения стандартных задач в области автоматизированного тестирования. Знание библиотек ускоряет процесс написания автотестов и избавляет от необходимости создавать новые решения с нуля.
Глобально и библиотеки, и фреймворки представляют собой код, созданный другими разработчиками. Принцип разработки DRY (Don’t Repeat Yourself — принцип предупреждает о дублировании кода. Если у вас есть повторяющийся код, лучше выделите его в отдельную функцию, класс или модуль) советует избегать дублирования кода, и для этого разработчики используют и библиотеки, и фреймворки.
Фреймворк — код, но его задача — определить структуру и выполнение программы. Это своего рода «каркас» приложения. Фреймворки определяют архитектуру приложения, и обычно их создают профессиональные команды разработчиков.
Библиотека — совокупность функций, решающих конкретные задачи. Её можно использовать многократно, и она включает в себя шаблоны сообщений, классы или подпрограммы. Библиотеки обычно являются частью стандартных языков программирования, но разработчик также может создать и собственную.
Например, в Python самые распространённые:
Pytest — самый популярный фреймворк для запуска тестов;
Selenium — библиотека для UI-тестирования;
Requests — библиотека для HTTP-запросов.
А для Kotlin и Java:
Selenium и Selenide — библиотеки, используемые для UI-тестирования;
JUnit5, TestNG — фреймворки для запуска тестов;
REST Assured — библиотека для тестирования Rest API;
Hamcrest — библиотека, используемая для ассертов;
Allure — просмотр красивых отчётов после запуска тестов.
Базовые навыки программирования
Знание основ конкретного языка необходимо, но для разработки эффективных тестов этого не хватит. Важно овладеть базовыми принципами, которые используют во многих языках программирования, делают код читабельным и быстрым.
Знание парадигм программирования помогает разработчику (да-да, автоматизатор является своего рода разработчиком) выбрать лучший стиль в зависимости от характера задачи. Например, для задачи, где важна модульность и повторное использование кода, подходит объектно-ориентированное программирование (ООП).
Помимо парадигм стоит задуматься и о принципах написания кода, таких как SOLID, KISS (Keep It Simple, Stupid — система должна быть максимально простой, лёгкой для понимания и обслуживания) и DRY.
Можно написать код, и он будет работать. А можно написать эффективный код, который будет одинаково быстро работать как с небольшими данными, так и выполняя долгие операции. Например, генерация новых пользователей, обработка изображений или работа со звуковыми файлами.
Шаблоны проектирования (Design Patterns) — повторно используемые решения для типичных проблем, возникающих в процессе проектирования программного обеспечения. Основная идея заключается в том, что шаблоны проектирования помогают создавать гибкий, расширяемый и поддерживаемый код.
Эти принципы и навыки позволяют QA Automation Engineer эффективно создавать автотесты, развиваться как специалисту — быть готовым к вызовам современной индустрии разработки ПО.
Инструменты
Один из основных навыков любого программиста — умение эффективно управлять кодом и сохранять полную историю всех изменений. Для этой цели часто используют систему контроля версий (VCS), которая записывает и хранит всю историю изменений в коде.
Непрерывная интеграция (CI) включает в себя создание автоматизированных процессов для развёртывания продукта в операционную среду (сюда относится и автоматизированный запуск тестов, и подготовка отчётов, и многое другое). Про CI/CD можно почитать подробнее в статье.
Переходим в автоматизацию из ручного тестирования
Все команды разные, поэтому давать советы по планированию и слишком подробно расписывать шаги мы не будем. А дадим рекомендации, которые пригодятся при начале разработки автотестов.
Продажа идеи о важности автоматизации
С переходом в автоматизацию на текущем проекте сложнее. Сначала определяют цели тестирования и формируют ответ на вопрос «Для чего это необходимо проекту?».
Представим большой проект и большое количество релизов — это потребовало бы больших человеческих и временных затрат. А автотесты позволяют обеспечить высокую скорость проверки. Цель бизнеса — получать информацию о качестве продукта как можно скорее, но такого уровня скорости невозможно достичь с использованием ручного тестирования.
Когда речь заходит об автоматизированном тестировании, часто используют следующий сценарий: есть команда автоматизаторов и задача автоматизировать тест-кейсы, которые использовали для проведения ручного регресса. В этот же момент ручных тестировщиков просят актуализировать ручные кейсы, а это часто происходит не быстро. Такой подход оторван от команды и процесса разработки. Автотесты должны стать неотъемлемой частью ежедневной работы команды.
Донести идею, что работать можно по-другому, тем, кто привык к ручному тестированию, — наиболее сложная задача в автоматизации. Эту концепцию необходимо «продать». Как показывает практика, новый подход с большим энтузиазмом воспринимают не все.
Изменение подходов в команде
Первоначально нужно время для написания автотестов. Его никогда не будет, но и автотесты сами себя не напишут. Поэтому есть три подхода:
уделять автотестам n% времени;
выделять определённые дни для автоматизации;
закладывать задачи в спринт, если команда работает по Scrum.
Первые два подхода малоэффективны. Задачи в разработке могут быть непредсказуемыми. В один период времени может потребоваться больше усилий на разработку нового функционала или устранение критических багов. Разработчики могут откладывать написание автотестов, а выделенные дни или процент времени для автотестов могут быть сорваны. Когда автоматизация рассматривается как отдельная задача, есть риск, что она станет второстепенной и автотесты не будут интегрированы в ежедневный процесс разработки.
Подход с выделением времени на автотесты может привести к тому, что автотесты будут восприняты «дополнительными» и «трудоемкими», уделять им достаточно внимания не захочется. В масштабах крупного проекта оба подхода не будут эффективно работать.
Для эффективной интеграции автотестов их важно рассматривать как неотъемлемую часть процесса разработки, внедряя в регулярные циклы разработки и интеграции нового функционала. Необходимо планировать задачи в спринт и рассматривать задачу на автоматизацию как продуктовую задачу.
Второе, над чем стоит поработать, — выделение критического функционала. Разрабатывать автотесты ради автотестов — плохой подход. Вы чётко должны понимать, какой функционал является критическим, а какой — второстепенным. А также сразу думать о подсчёте тестового покрытия.
Переход в автоматизацию внутри проекта
В разных компаниях и проектах существуют свои подходы к автоматизации тестирования. Некоторые компании приветствуют переход от ручного тестирования к автоматизированному, другие — наоборот.
Если вы специалист по ручному тестированию и решаете перейти к автоматизированному тестированию, стоит обсудить этот вопрос с вашим руководителем. Вместе вы сможете разработать план обучения, который, вероятно, уже существует в компании. Такие планы обычно обсуждаются и составляется ИПР на ближайший квартал.
Начните с азов языка программирования. Важно знать язык, на котором написаны автотесты в вашей команде. А позже подключайтесь к простым автотестам. Этот процесс поможет вам освоить базовые концепции автоматизации и научиться использовать инструменты.
Затем вы сможете принимать участие в улучшении и разработке фреймворка, который используют в вашей команде для автоматизированных тестов. Выбор фреймворков для автоматизации обычно уже сделан в проекте, поэтому изначально необходимо углубиться и изучить их.
Подводим итоги. Переход в автоматизацию не так сложен, как кажется, но он требует времени и немного усилий (как бы банально ни звучало). Автоматизация — это процесс, который требует постоянного совершенствования. Следите за новыми технологиями и возможностями, мониторьте вакансии и ходите на собеседования для поддержания тонуса.
