Автоматизация тестирования: от выбора стратегии до выбора реализации

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

Стратегия автоматизации тестирования при разработке программного продукта тесно связана со стратегией тестирования в целом. На ее формирование влияют такие факторы, как цели тестирования, определяющие объекты и виды тестирования, оценка необходимой тестовой среды, определение необходимых процессов и инструментов автоматизации.

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

Разобраться в этих нюансах помогает ведущий специалист-тестировщик компании IT_One Алексей Антонов.

Алексей Антонов

Ведущий специалист-тестировщик компании IT_One

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

Какие цели мы преследуем?
Что именно мы будем тестировать?
Какие виды и уровни тестирования будем применять?
Какое тестовое окружение нам понадобится?
Кто будет этим заниматься?
Когда необходимо планировать мероприятие по тестированию?
Какие существуют ограничения на объем выполняемых работ?

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

Стратегия автоматизации тестирования

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

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

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

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

Автоматизировать или нет?

Теперь перед нами встает задача: какую часть процесса тестирования мы можем автоматизировать. При этом мы учитываем следующие факторы:

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

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

Можно выделить ряд проектов, в которых автоматизация всегда оправдана:

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

Наоборот, автоматизация окажется излишней в небольших коротких проектах без поддержки (PoC, демо) и в проектах с небольшим количеством итераций тестирования.

Тестирование десктопа: что учитывать перед введением автотестов

tproger.ru

Выбор инструментов тестирования

Определившись с задачами, объектами и форматом тестирования, мы можем построить решение по автоматизации, подобрав необходимые инструменты и сформировав фреймворк автоматизации. Я бы описал инструмент автоматизации как некий «черный ящик», обладающий функционалом написания и предоставления скриптов, умеющий воспроизводить эти скрипты, а также принимать некие тестовые данные и управлять объектами тестирования, проводить необходимые проверки и выдавать результаты в виде отчета.

Вернемся к нашему примеру с интернет-магазином и первому объекту тестирования: интерфейсу пользователя. Мы берем конечный интерфейс взаимодействия пользователя с нашей системой и начинаем подбирать наиболее подходящий инструмент, обращая особое внимание на то, насколько стабильно он распознает и умеет управлять элементами интерфейса. В итоге это могут быть такие программные продукты, как как Unified Functional Testing (UFT), Katalon Studio, Test Complete, Ranorex или программные библиотеки Selenium, Appium и аналогичные им.

Аналогично мы выбираем инструменты для других объектов с учетом их специфики. Например, для тестирования автоматизации API приоритет отдается поддержке нужных протоколов взаимодействия, а для тестирования хранилища данных – работе инструмента с СУБД.

Для более точного выбора мы смотрим на возможности самого инструмента: можно ли его запустить из консоли, насколько он расширяемый (и во сколько обойдется покупка дополнительных модулей, их интеграция), в какой среде может быть использован, имеет ли интеграцию с нужной системой управления тестированием и системой отслеживания ошибок.

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

Открытый код, проприетарный продукт или собственная разработка

Отдельно стоит упомянуть о разделении инструментов тестирования на категории по типу разработки:

решение на базе Open Source-элементов;
коммерческое (проприетарное) решение;
внутренняя разработка.

Каждая категория имеет свои преимущества и недостатки.

Так, продукты на базе Open Source, как правило, хорошо решают свои специализированные задачи, поддерживаются большим комьюнити (где можно найти ответы даже на те вопросы, которых нет в документации), обладают гибкостью разработки. Успешные Open Source проекты активно развиваются, при этом нам никто не мешает вам при наличии соответствующей экспертизы создать отдельную ветку и дописать в ней функционал, которого этому инструменту не хватает. В то же время такие инструменты требуют интеграции в комплексное решение по управлению тестированием, определенной квалификации ИТ-специалистов, а также имеют риск прекращения разработки или поддержки.

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

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

Так ли надо писать код

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

Менеджер продукта, аналитик, тестировщик – создают тесты, определяют наборы тестов с приоритетами, пишут некие скрипты для автоматизации, запускают автотесты, анализируют результаты. В целом они формируют требования к автоматизации тестирования, так как являются основными пользователями.

Автоматизатор функционального и регрессионного тестирования – на его плечи ложится поддержка и развитие фреймворка автоматизации, обучение и поддержка пользователей-тестировщиков\поддержка инфраструктуры тестирования.

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

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

Итак, писать код стоит:

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

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