Блог A1QA

О тестировании и качестве ПО

Как строить решение по автоматизации на проектах с BDD-подходом?

В предыдущей статье мы говорили о том, как описывать тестовые сценарии при помощи языка Gherkin, который используется на проектах с BDD-подходом.

Сегодня менеджер команды автоматизаторов A1QA Сергей Сенюк расскажет, как в компании строится решение по автоматизации на проектах с использованием BDD-подхода.

Автоматизация тестирования с применением BDD-подхода

Пошагово разработка решения по автоматизации, когда конечными пользователями такого решения являются не инженеры по автоматизации, а QA-команда заказчика, не обладающая знаниями написания автотестов, выглядит так:

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

Этап 2: На базе Page Object и иных шаблонов проектируем структуру решения. Мы пишем классы форм, включающие в себя поля, которые отвечают элементам UI приложения, и методы работы с ними, а также классы непосредственно тестов, в которых мы создаем объекты форм и реализуем объявленные в них методы.

Этап 3: Тестовые данные выносим во внешние файлы, абстрагируя тем самым их от программного кода.

Этап 4: Имплементируя BDD-подход, подключаем к проекту одну из библиотек, что позволяет нам работать с языком Gherkin, и программируем шаги. По сути, это дополнительный уровень абстракции, связанный как с программным кодом фреймворка и автотестов, так и с файлами спецификаций – текстовыми документами, содержащими в себе описание сценариев в лингвистическом шаблоне Gherkin (Given/When/Then).

Графически полученное решение можно представить следующим образом:

struktura-reshenia-po-avtomatizacii-testirovania

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

Отчет об успешном прохождении автотеста выглядит следующим образом:

primer-otcheta-ysheshogo-avtotesta

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

Если же автотест завершился неудачно, мы получим из отчета следующую информацию:

  • Шаг, на котором произошла ошибка, будет выделен красным.
  • Описание как фактического результата, так и ожидаемого.
  • Указание на строку программного кода, в которой прописана завершившаяся неудачно проверка.
  • Список действий, выполненных до возникновения ошибки.
  • Скриншот приложения.

Как построить эффективное взаимодействие между командами тестировщиков и автоматизаторов на проекте, на котором используется BDD-подход?

Взаимодействие автоматизаторов и тестировщиков 

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

На начальном этапе, будь то пилот или же Proof of Concept, тестировщики преобразуют начальный набор тестовых сценариев в Gherkin-формат или же составляют сценарии самостоятельно. После этого на базе BDD-подхода автоматизаторы программируют автотесты, основанные на предоставленных сценариях. Вместе с тем они выполняют конфигурацию окружения (CI — система непрерывной интеграции) для запуска автотестов и хранения отчетов об их прохождении.

По завершении пилота автоматизаторы предоставляют клиентам следующие артефакты:

  • Тестовые сценарии в Gherkin-формате;
  • Программный код автотестов и фреймворка;
  • Окружение для запуска автотестов (CI);
  • Документация по использованию решения (может содержать описание архитектуры решения, процесса запуска в CI системе и т.п.).

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

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

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

Тестировщики же выступают полноценными пользователями предоставленного решения по автоматизации и могут самостоятельно:

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

Следует отметить ряд фактов, которые могут повысить стоимость проекта, реализуемого на основе BDD-подхода:

  1. Обучение вовлеченных в использование решения сторон языку Gherkin.
  2. Увеличение продолжительности создания решения на 10-15% за счет программирования шагов, используемых тестовыми сценариями.
  3. Конвертация предоставленных стороной клиента тестовых сценариев в формат Gherkin для последующего создания автотестов на их основе.

Тем не менее, плюсов в конечном итоге от использования Behavior-Driven подхода на проекте неизмеримо больше:

  • Документация и автотесты хранятся в одном программном проекте, причем файлы с описанием сценариев одновременно являются и исполняемыми автотестами. Как альтернативный вариант, возможно задать конфигурацию решения по автоматизации так, что сценарии в формате Gherkin будут храниться в любой тест-трекинговой системе, а автотесты будут обращаться непосредственно к ней.
  • Использование подобного решения не требует навыков программирования, и тестировщик может осуществлять запуск, анализ автотестов, а также создавать новые сценарии.
  • За счет универсальности шагов возможно создавать новые сценарии на базе имеющегося словаря, комбинировать шаги, использовать различные наборы тестовых данных.
  • Описание поведения системы, представленное в формате Gherkin, будет едино для всех команд, вовлеченных в проект. Как следствие, понимание требований к системе будет одинаковым.

Подведем итог

Использование BDD-подхода и языка Gherkin имеет ряд весомых преимуществ на проектах, в которых задействована QA-команда, не обладающая навыками написания автотестов.

Для того чтобы с уверенностью гарантировать эффективность процесса, необходимо заранее рассчитать затраты на обучение команды языку Gherkin и конвертацию тестовых сценариев в формат Gherkin. Наш опыт говорит о том, что все выгоды от автоматизации тестирования с внедрением BDD-подхода значительно превосходят затраты.

Поделиться статьей: