Автор: Энди Найт (Andy Knight)

Оригинал статьи: http://automationpanda.com/2017/10/08/bdd-101-manual-testing/

Перевод: Ольга Алифанова

Философия разработки через реализацию поведения ставит во главу угла автоматизацию: спеки поведения должна превратиться в автоматизированные тесты. Однако BDD вполне может включать в себя и ручное тестирование. У ручного тестирования есть свое место и свои задачи, даже в BDD. Помните, поведенческие сценарии – это в первую очередь поведенческие спецификации, и их ценность выходит за рамки тестирования/автоматизации. Любой сценарий можно прогнать как ручной тест. Следовательно, встают вопросы, в каких случаях пользоваться ручным подходом, и как с ним управляться.

Когда следует подключать ручное тестирование?

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

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

Ручной подход также годится для исследовательского тестирования, при котором инженеры полагаются на опыт, а не на явно описанные тест-процедуры, и "исследуют" тестируемый проудкт на предмет багов и проблем качества. Оно дополняет автоматизацию, потому что оба эти стиля служат разным целям. Однако сами поведенческие сценарии несовместимы с исследовательским тестированием. Цель исследования – дать свободу действий инженерам, не сковывая их формальными тест-планами, и они находят проблемы, которые поймает только пользователь. Для исследовательского тестирования через реализацию поведения лучше не писать сценарии, а подойти к вопросу комплексно: тестировщики должны притвориться пользователями и обращаться с продуктом, как с коллекцией взаимодействующих поведенческих паттернов. Если исследование выявит пробелы в поведении, новые поведенческие сценарии должны быть добавлены в каталог.

Как организовать ручное тестирование?

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

Репозиторий

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

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

Тэги

Сценарии должны классифицироваться как ручные или автоматизированные. Когда фреймворк BDD прогоняет тесты, ему необходимо исключать неавтоматизированные. В противном случае отчеты о тестировании будут полны ошибок. В Gherkin сценарии классифицируются при помощи тэгов. К примеру, сценарий может быть отмечен или как @manual, или как @automated. Третий тэг, @automatable, можно применять, чтобы выделять сценарии, предназначенные для автоматизации, но еще не автоматизированные.

У некоторых фрейморков вопрос тэгов решен очень изящно. В Cucumber-JVM тэги можно создавать как классовые опции средства запуска. Это означает, что тэги можно установить как "~@manual", чтобы избежать ручных тестов. В SpecFlow любой сценарий со специальным "@ignore"-тэгом будет автоматически пропущен. В любом случае я рекомендую использовать специальные теги, чтобы выделять ручные тесты, потому что для игнорирования тестов может быть масса причин (к примеру, известные баги).

Дополнительные комментарии

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

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

Пример

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

Фича: поиск Google

@automated

Сценарий: Поиск в поисковой строке

Если веб-браузер находится на домашней странице Google

Когда пользователь вводит "панда" в поисковую строку

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

@manual

Сценарий: Поиск картинок

# Домашняя страница Google: http://www.google.com/

# Убедитесь, что среди картинок есть изображения поедающей бамбук панды

Если отображены результаты поиска Google для "панда"

Когда пользователь нажимает на ссылку "Изображения" на верху страницы с результатами

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

Не больно-то и много различий с другми поведенческими сценариями.

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

Обсудить в форуме