Компаниям, занимающимся разработкой ПО, необходимо обеспечивать высокое качество продукта, соблюдая установленные сроки. При этом для растущего объема задач и сложности проектов методов ручного тестирования становится недостаточно. Автоматизация тестирования позволяет запускать тесты быстрее, к тому же такие тесты могут выполняться в фоновом режиме, что позволяет командам сосредоточиться на более сложных задачах и улучшить свою эффективность. Тем не менее в некоторых компаниях еще сомневаются в необходимости автоматизации, считая ее или просто излишеством, или дорогостоящим и трудоемким процессом, который можно отложить. В этой статье Денис Исангулов, руководитель отдела тестирования NGR Softlab, расскажет, когда и как стоит начать движение в сторону автоматизации, а также даст рекомендации по ее интеграции в текущие проекты компании.
Неважно, идет ли речь о молодом и амбициозном проекте, который выбирает между наймом ручных тестировщиков и автоматизаторов, или о зрелом продукте с большим количеством тестовых сценариев, которые регулярно проверяются вручную. С ростом объема тестов увеличивается и число ручных тестировщиков. И как понять, на каком этапе стоит начинать автоматизацию? В этом поможет пирамида тестирования.
На нижнем уровне пирамиды находятся юнит-тесты, которые разработчики создают для своего кода. Я настоятельно рекомендую не упускать этот этап и как можно тщательнее покрывать код программы тестами. Чем раньше будет выявлена ошибка, тем дешевле обойдется ее исправление. Баг может разрастись как снежный ком, и, если упустить ситуацию из-под контроля, небольшой недочет в кодировании может привести к серьезным проблемам в продакшене. Именно поэтому автоматизацию тестирования лучше всего начинать с момента разработки кода. Также стоит отметить, что создание модульных тестов в собственных ПО является обязательным пунктом для сертификации ПО во ФСТЭК.
Следующий уровень пирамиды — это API-тесты. Писать их несложно — обычно с этим могут справиться даже начинающие разработчики тестов под руководством более опытного наставника, который продумает архитектуру, будет проводить код-ревью и следить за актуальностью кода. Скорость написания API-тестов обычно выше, чем у тестов для пользовательского интерфейса (UI), что может стать хорошим подспорьем: API-тесты проходят быстрее, и их можно запускать чаще, реагируя на каждое изменение в коде и получая своевременный фидбэк.
Автоматизированные API-тесты можно писать как по готовой Swagger-документации, что, безусловно, проще, так и во время разработки API. Второй вариант также помогает выявить ошибки и архитектурные проблемы на ранних этапах создания продукта. В NGR Softlab для новых модулей мы используем именно такой подход, что позволяет при минимальных изначальных затратах заложить крепкий фундамент для дальнейшего качества нашего ПО. Безусловно, единожды написанные автотесты нельзя просто забыть, они требуют постоянной поддержки и актуализации. Однако такие затраты будут значительно меньше, чем наем штата ручных специалистов, которые раз за разом будут выполнять одну и ту же работу.
На следующем уровне пирамиды находятся UI-тесты. К их разработке следует приступать в последнюю очередь, так как UI часто подвергается изменениям, а писать тесты для него сложнее и дороже. Поэтому стоит начинать описание UI автотестами только тогда, когда есть четкое понимание того, что какой-то участок интерфейса зафиксирован на продолжительное время или изменения в нем будут незначительными.
Конечно, пирамида может включать и другие уровни, но общий подход остается таким: чем ближе к фундаменту пирамиды, тем больше ресурсов требуется на написание автотестов.
Таким образом, чем раньше начнется автоматизация, тем значительнее польза, которую она принесет в дальнейшем. Если проект уже находится в активной фазе, а автотестов на него еще нет, необходимо начинать разработку снизу пирамиды. При этом написание юнит-тестов и API-тестов можно организовать как параллельный процесс. Готовность к автоматизации проявляется в открытости к новым технологиям и желании улучшить процессы. Если руководство понимает, что это может повысить качество продукта, а также сэкономить время и ресурсы, значит, компания движется в правильном направлении.
Допустим, бизнес пришел к выводу, что автоматизация тестирования необходима, и тут возникает вопрос: «С чего начать?»
Первым делом нужно определить человеческие ресурсы и выбрать стратегию. Один из вариантов — переквалификация функциональных тестировщиков в автоматизаторов. Такой путь имеет свои сложности: не всем это может быть интересно, но, скорее всего, найдутся сотрудники, которые увлекутся идеей и начнут углубляться в процесс через курсы или самообучение. Плюс этого подхода в том, что функциональные тестировщики хорошо знают продукт и смогут определить, какие участки нужно покрыть тестами в первую очередь. Однако минус заключается в том, что они могут столкнуться с трудностями на этапе построения автоматизации, и такие эксперименты иногда заканчиваются неудачами, что может привести к прекращению автоматизации как неэффективного процесса.
Другой, более очевидный путь — это наем опытных автоматизаторов с рынка. Они смогут строить проекты автотестов, опираясь на лучшие практики и свой опыт. С ними будет проще погружать остальных членов команды в автоматизацию. Несмотря на то что этот подход может оказаться дороже на начальных этапах, со временем он приведет к повышению качества ПО и снижению затрат на тестирование.
Следующий вопрос: какой стек технологий выбрать для автоматизации? Хорошая практика предполагает использовать тот же язык, на котором разрабатывается программа. Это упростит взаимодействие между разработчиками и тестировщиками. Также целесообразно использовать один язык для написания тестов как для бэкенда, так и для фронтенда, чтобы избежать сложности с поддержкой различных технологий. Если нет возможности использовать язык разработки, стоит обратить внимание на популярные языки и фреймворки, такие как Java, JavaScript, Python или C#, Selenium и Playwright.
В NGR Softlab для автоматизации мы используем Python с библиотекой Pytest, а также вспомогательные инструменты, такие как Requests для API и Playwright для UI. Python имеет понятный синтаксис и большое сообщество разработчиков автотестов. Выбор технологий должен основываться на задачах, стоящих перед автоматизаторами. Также не стоит забывать, что чем популярнее язык программирования, тем проще будет найти специалиста.
Когда команда сформирована и технологии выбраны, можно приступить к отбору тестов-кандидатов для автоматизации. Автоматизировать можно практически все, но для быстрого получения результатов следует сосредоточиться на приоритетных тестах. Выбор можно осуществлять по критериям автоматизации, основываясь на частоте выполнения тестов, функционале, который часто меняется, или трудоемких тестах. Критерии также могут определяться в зависимости от приоритетов проекта.
Интеграция процессов написания автотестов в текущие проекты компании — важный шаг к улучшению качества программного обеспечения и ускорению процесса разработки. Я бы хотел обратить внимание на несколько ключевых моментов, которые должны быть взяты за основу для успешного и плавного внедрения:
Хочется подчеркнуть, что внедрение автоматизации тестирования — это комплексный процесс, который требует внимания, планирования и инвестиций. Внедрение автотестов — не просто технологический тренд, а необходимый шаг для любой компании, стремящейся к повышению качества ПО и ускорению разработки. Надеюсь, рекомендации, изложенные в этой статье, помогут коллегам, еще не принявшим решение об автоматизации тестирования, сделать правильный выбор и облегчат их путь в сторону эффективного развития.
Нажимая на кнопку, я даю Согласие на обработку персональных данных в соответствии с Политикой обработки.
Зарегистрироваться