Если на вашем проекте есть автоматизация тестирования, наверняка вы не раз задавались вопросом об оптимальных способах поддержания автотестов и написания новых. Обычно команды расширяют штат, но что если предложить написание автотестов ручным тестировщикам? На одном из проектов в GS Labs тестировщики решили поэкспериментировать со вторым подходом, и упростить написание автотестов, применив Behavior Driven Development (BDD). 

Ниже приведена статья QA Automation Lead Александра Иванова из GS Labs о том, как на примере тестирования приставок цифрового ТВ на Python с использованием Behave применять BDD и прокачивать мануальных тестировщиков.

Более подробно с описанием тестового стенда можно ознакомиться в статье на Habr.

TDD и BDD — в чем разница?

Подход разработки через тестирование (Test-Driven Development, TDD) предполагает организацию автоматического тестирования перед написанием кода. Т.е. в первую очередь пишется тест, проверяющий корректность работы ещё не написанного кода. Тест, само собой, не проходит. Далее программист пишет код, где выполняются действия, необходимые для прохождения теста. Когда тест будет успешно пройден, возможна доработка имеющегося кода.

BDD (Behavior-Driven Development) является разновидностью, или расширением TDD. Однако эти подходы предназначены для разных целей, поэтому для их реализации используются разные инструменты. BDD — в первую очередь помогает улучшить сотрудничество заинтересованных лиц, т.е. выработать единое понимание поведения ПО. Именно эта формулировка определяет основное предназначение подхода.

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

Среди BDD фреймворков для Python было решено использовать BDD подход для написания автотестов. Для этого была выбрана библиотека behave. Подробнее и с простыми примерами можно прочитать тут. Behave — это фрейморк для программирования через поведение системы в python-стиле. Behave использует тесты, написанные на “естественном”, то есть, английском языке.

 Устанавливается библиотека через командную строку: pip install behave

Структура папок следующая:

features/test.feature
features/steps/steps.py

Файл steps.py содержит написанные на python «шаги». Файл test.feature содержит сами тесты на  «естественном» языке. Для запуска тестов нужно запустить команду: 

behave -i infocas.feature

Для запуска тестов с тегом нужно выполнить команду: 

behave -i infocas.feature --tags=short_term 

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

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

Далее у приёмника появляется API (вместо ИК переключателя), которое регулярно дорабатывается и улучшается. Это подарило надежду на повышение стабильности тестов. И мы начали внедрять автоматизацию. В качестве языка был выбран Python 3. В качестве тестовых данных использовали потоки.

Для примера посмотрим на тест по корректному отображению сообщений на приёмнике клиента. Запускаем нужный нам поток и ждём 60 секунд (именно на 60 секунде происходит отправка). Автотесты представляли из себя Python-код:

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

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

Что делают "ручники"? 

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

В процессе автоматизации количество автотестов по отношению к ручным тестам неуклонно растёт. Отсюда сразу две проблемы:

• Автотестов становится больше, их нужно поддерживать, ресурсов не хватает

• Ручных тестов становится меньше, ручным тестировщикам надо найти занятие, иначе заскучают

Но есть решение, которое позволит решить обе проблемы — привлечь ручных тестировщиков к автоматизации. Но как привлечь, если тестировщик не имеет необходимых навыков программирования? Здесь нам помощь приходит BDD.

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

Рассмотрим ранее написанный автотест по корректному отображению сообщения на экране, но уже написанный в BDD стиле:

@short_term 
Scenario: 01_01_Broadcast infocas
Given we switch to channel "12" on "server"
When we send "broadcast" infocas message "Broadcast Test Infocas" for test "01_01"
Then we "see" infocas message displayed for test "01_01"

Given — для описания системы, как это предусмотрено.

When — для описания действий пользователя.

Then — для описания реакции системы.

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

Больше не нужны тайминги для ожидания загрузки сервисов или прихода подписок. Написание тестов становится подобным сборке Lego. А какой тестировщик не любит конструкторы!

Оценка результатов тестирования

Результаты можно переносить сразу в тест план проекта. Если по каким-то причинам план не создан или нужно провести отладку тестов, то результаты переносятся в промежуточный тест-план. Потом результаты из него можно переносить в нужный нам план.

Несколько слов про анализ результатов: в случае, если тест не пройден, то необходимо понять в чём причина.

Причин может быть несколько:

• баг в ПО

• баг в сам автотесте

• проблема с настройкой тестового окружения

Поскольку мы работаем с изображением, которое получаем с приёмника, то для принятия правильного решения нужно смотреть скриншоты полученные во время выполнения теста. Для этого можно перейти в соответствующую папку на тестовом стенде и посмотреть вложение. А можно воспользоваться средствами системы управления тестированием Test IT. Для этого к каждому тестовому результату в поле комментарий мы прикладываем ссылку на локальный веб-сервер xampp.

Итоги

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

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

Автор: Александр Иванов