Юлия Ковалева, старший Java-разработчик автотестов в «Альфа-Лаборатории»Посвятила тестированию более 4 лет, сейчас разрабатывает библиотеку шагов для масштабирования автоматизации тестирования с использованием Cucumber и Selenide.
Анна Чернышева, старший Java-разработчик автотестов в «Альфа-Лаборатории»Работала в крупных e-commerce проектах, участвует в создании и поддержке нескольких BDD-фреймворков, а также занимается внедрением инженерных и DevOps-практик.
— В чем заключается основное различие методик TDD и BDD?
Анна Чернышева: Понимание методик TDD и BDD отличается в разных компаниях, мы расскажем о том, как все устроено в «Альфа-Лаборатории». Концепции обоих подходов похожи, сначала идут тесты и только потом начинается разработка, но предназначение у них совершенно разное. TDD — это больше о программировании и тестировании на уровне технической реализации продукта, когда тесты создают сами разработчики. BDD предполагает описание тестировщиком или аналитиком пользовательских сценариев на естественном языке — если можно так выразиться, на языке бизнеса.
— BDD — просто модное слово или принципиально новый подход к разработке через тестирование? От TDD его отличает только использование естественных языков для описания тестов?
Юлия Ковалева: BDD и в самом деле модное слово, но далеко не все умеют его правильно «готовить». В «Альфа-Лаборатории» нам пришлось комплексно подойти к решению задач и полностью изменить многие аспекты функционирования всей команды, что позволило существенно удешевить процесс тестирования. Нанять умеющего описывать тестовые сценарии на русском языке человека намного проще, чем найти специалиста, способного реализовать эти тесты, например, на Java.
BDD подход совместно с инженерными практиками позволил нам отказаться от legacy-документации, содержащей неактуальную информацию, и получать новую документацию налету, хранить ее вместе с проектом, что позволило приблизить аналитиков и тестировщиков к коду.
— В разработку сценариев BDD вовлечены не только тестировщики, необходимость в автоматизаторах сохраняется?
Юлия Ковалева: Разумеется, оставить в команде только тестировщиков без автоматизаторов — достаточно недальновидно. Потребуется некий инструментарий и владеющий им человек, чтобы реализовать ту техническую составляющую, которую тестировщик самостоятельно сделать не сможет.
Анна Чернышева: Потребность команды в количестве экспертов по автоматизации тестирования уменьшается, поскольку есть фреймворки, которыми могут пользоваться тестировщики. Автоматизатор добавляет новую функциональность в тестовый фреймворк, и она сразу становится доступна всем командам.
— Помимо традиционных для TDD unit-тестов при использовании BDD-подхода проводятся также behavior-тесты. На этом различия процессов тестирования заканчиваются или дело обстоит сложнее?
Анна Чернышева: Все гораздо сложнее, поскольку BDD — скорее процесс, целью которого является удешевление реализации новых фич. Еще на старте разработки мы получаем важные артефакты. Например, понятную для поддержки документацию. Эта документация дает возможность всем заинтересованным лицам сформировать свое представление о продукте и сценариях пользовательского поведения, которые должны быть реализованы в ходе итераций разработки. С BDD-подходом мы также снижаем порог входа в проект новых участников.
— Многие считают, что BDD можно рассматривать как переход от основанной на unit-тестах разработки к разработке, основанной на интеграционном тестировании. А как ситуация обстоит на самом деле?
Юлия Ковалева: Мы провели такой эксперимент. Попытка использовать BDD-инструменты для написания unit-тестов успехом не увенчалась, через какое-то время разработчик отказался писать поведенческие тесты. Когда мы говорим про автоматизацию, BDD идеально вливается в эту историю, но применять такой подход к модульному тестированию не стоило, пользы нам это не принесло. При интеграционном тестировании польза от BDD будет значительной — здесь мы смотрим на весь продукт в целом.
— В каких случаях для тестирования применяется BDD подход и чем он лучше более традиционного TDD?
Анна Чернышева: BDD в основном используется для проверки взаимодействия разных компонентов системы, это, как уже было сказано, уровень интеграционного тестирования — оно поведенческое и проверяет различные бизнес-кейсы. TDD используется для разработки через модульное тестирование непосредственно программистами, которые пишут код через этот подход. В общем, если по-простому, TDD проверяет исключительно модули, а BDD — пользовательские сценарии.
— Зачем потребовались новые BDD-фреймворки, не проще оформить BDD в набор рекомендаций по написанию TDD и использовать существующие?
Юлия Ковалева: BDD появился, чтобы сделать команду разработки ближе к бизнесу, организовать диалог между бизнесом, разработчиками и тестировщиками. При TDD-подходе нужно писать тесты на формальных языках программирования. Тесты и код лежат в одном месте, их достаточно сложно поддерживать, а уж тестировщик или бизнес-аналитик едва ли полезет смотреть, что мы там написали. Два наиболее популярных BDD фреймворка — JBehave и Cucumber. Как их правильно применять, мы расскажем на ближайшей конференции Гейзенбаг 2017 Piter.
Анна Чернышева: Эта путаница между TDD и BDD пошла от общей для разных подходов идеи: сначала пишутся тесты, а потом идет разработка. При всех сходствах они предназначены для разных целей и требуют применения различных инструментов.
— То есть BDD нельзя считать расширением TDD?
Анна Чернышева: Да, мы считаем именно так. Вместо тестовой модели у нас есть пользовательские сценарии, которые мы автоматизируем в одном спринте с разработкой. Более того, в «Альфа-Лаборатории» BDD-подход органично внедрен и в инженерные практики.
— QA считают женской профессией. Как вы полагаете, с чем это связано и насколько соответствует действительности? Есть ли вообще в IT понятие женской и мужской профессии?
Анна Чернышева: Сейчас от этого стараются уйти, но женское мышление более абстрактно, а мужчинам важны конкретные детали — это, конечно, все индивидуально, но если брать «Альфа-Лабораторию», то девушек-тестировщиков в процентном соотношении несколько больше. Может, тестирование требует творческого подхода, а девушки — более творческие натуры?
Юлия Ковалева: Можно провести эксперимент и подсчитать, сколько девушек и мужчин придут на Гейзенбаг.
На Гейзенбаг 2017 Юлия Ковалева и Анна Чернышева сравнят Cucumber и JBehave. У какого BDD-фреймворка больше возможностей? Как их правильно «готовить» и с какими трудностями придется столкнуться во время тестирования — состязание ведущих разработчиков автотестов «Альфа-Лаборатории» пройдет в лучших традициях Mortal Kombat.
BDD Girls Battle: Cucumber vs. JBehave
Полная программа конференции доступна на сайте.
Комментарии (23)
Source
29.05.2017 12:09Имхо, BDD было модным словом лет 7-8 назад…
А по отличиям всё просто: есть такая штука, функциональная спецификация называется, это документ, согласно которому составляется тест-план приёмочного тестирования. BDD призван автоматизировать этот процесс.
А TDD работает на уровне юнит-тестов, т.е. помогает продумывать детали реализации и отлавливать ошибки на этом уровне.
MonkAlex
29.05.2017 12:29Ээээ…
TDD — тесты вперед кода.
BDD — опиши чего ты хочешь, как пользователь, чтобы код понял даже не разработчик.
Чего тут путать то?
tundrawolf_kiba
29.05.2017 13:54+1А еще есть ATDD=TDD+BDD, и вот ATDD часто тоже называют BDD и вследствие этого путают BDD с TDD.
VolCh
29.05.2017 14:28В разработку сценариев BDD вовлечены не только тестировщики, необходимость в автоматизаторах сохраняется?
Не очень понял вопроса, а следовательно и ответа. Разве текст behavior-тестов (по статье ощущение, что они прямо на русском пишутся, так?) не является артефактом работы автоматизатора тестирования? Вместо ручного прохождения сценария "по бумажке" автоматизатор пишет тест и настраивает/запускает его прогон? Или теперь написание автотестов не входит в основные обязанности автоматизаторов тестирования?
tundrawolf_kiba
29.05.2017 14:44+1В случае с BDD обязанность писать автотесты переходит на ручных тестировщиков — они пишут сценарии, состоящие из шагов. Автоматизатору остается только имплементировать конкретные шаги, если их не существовало ранее. Количество работы для автоматизатора значительно сокращается. Во всяком случае у нас был именно такой опыт, и был он весьма успешным.
VolCh
29.05.2017 18:21+2То есть по сути это ручные тестировщики начали заниматься азами автоматизации тестирования )
oklyep
30.05.2017 12:12А разбор ошибок запуска? Особенно первого запуска?
tundrawolf_kiba
30.05.2017 12:50+1Понятное дело, что если шаг имплементируется в первый раз, то он отлаживается автоматизаторами. А вот если сценарий составляется из уже готовых шагов — то это задача только ручного тестировщика. К автоматизаторам в этом случае приходят только шаги начинают работать не так, как ожидается. А так — если в какой-то момент возникла ошибка — то если это просто фэйл теста — то сценарий воспроизведения можно после ревью ручными тестировщиками сразу отдавать разработчикам. Если же возник дефект самого теста — то автоматизаторам. У нас было как-то примерно так.
oklyep
02.06.2017 11:48Мануальные тестировщики пишут багрепорты на неправильные степы?
tundrawolf_kiba
02.06.2017 13:22Не совсем понял, что вы имеете ввиду под неправильным степом, можете уточнить? Это сам степ не работает так, как описано, или степы работают, но валится тест или как?
jukas_k
30.05.2017 12:12Вы тоже это заметили? (про вопрос)
Дело в том, что в Альфа-Лаборатории написанием BDD-историй (feature/story-файлов) занимается именно аналитик-тестировщик, но никак не автоматизатор. Автоматизатор может быть привлечен на стадии старта проекта, когда возникают сложные ошибки, когда требуется написать сложный шаг на Java, обучить тестировщика писать простые шаги на Java и все. Сам же тестировщик-аналитик является частью скрам-команды, поэтому он может смело обращаться за помощью к ней же и с учетом того, что многие команды у нас практикуют парное программирование, помощником может стать любой разработчик или же системный аналитик.
Автоматизатор же в свободное от помощи и обучения тестировщиков время занимается у нас задачами по инфраструктуре в тестировании, интеграцией со сторонними и собственными решениями, созданием и поддержкой инструмента автоматизации UI тестов.
grumegargler
29.05.2017 20:56получать новую документацию налету, хранить ее вместе с проектом, что позволило приблизить аналитиков и тестировщиков к коду
Подскажите пожалуйста, это пользовательская документация или набор given when then?anna-che
30.05.2017 12:12+2Смотря с какой стороны посмотреть. Да, это Given When Then, но если правильно структурировать, согласовать формат плюс добавить asciidoc, то и пользовательская документация тоже.
tundrawolf_kiba
30.05.2017 12:52+1Вообще по опыту — иногда качественно составленный и структурированный набор тестов помогает разобраться в программе лучше, чем оригинальная документация. Как на мой взгляд — тесты — это по сути еще один вид документации.
Fesor
30.05.2017 14:48мне нравится проект picklesdoc.com. Там как раз таки идея в том чтобы использовать gherkin сценарии как способ ведения документации по проекту. Очень много плюсов в плане того что эта документация реже будет выходить из синхронизации с реализацией.
grumegargler
30.05.2017 16:06понятно, а есть реальный опыт (положительный/отрицательный) в использовании такой документации конечными пользователями продукта? Или пока это больше для внутренних нужд.
Fesor
30.05.2017 10:45целью которого является удешевление реализации новых фич
ну вообще уменьшение издержек связанных со стоимостью перевода требований из языка бизнеса в язык понятный разработчику. Просто "удешевление" звучит слишком просто.
Nikita_Danilov
30.05.2017 12:12+2TDD и BDD путают, потому что BDD фреймворки так и норовят сказать что они является эволюционным шагом от TDD. Открываем JBehave:
JBehave is a framework for Behaviour-Driven Development (BDD). BDD is an evolution of test-driven development (TDD)
Не совсем понимаю роль BDD в данном описанном случае, возможно не хватает примеров, но видимо их покажут только на конференции. Автоматизаторы общаются с Бизнесом, синхронизируют понятия, составляют сценарии, а дальше садятся и пишут обычные такие автотесты. Автотесты содержат некоторый код, который что-то вызывает, что-то проверяет, но это код дописанный вручную.
Красивые примеры BDD описаний выглядят красиво в виде сценариев, но в итоге их перегоняют в обычный код автотестов (а иногда очень избыточный и многословный, как пример с Tooling examples).
Сама идея нормального структурированного описания сценариев — полезна, это самый адекватный способ прописать Acceptance Criteria для задачи.
НО перегонку в код всё равно будет выполнять Автоматизатор (с навыками программиста), который довольно быстро (на мой взгляд) упрется в ограничения фреймворков и устанет от еще одного DSL-языка.
При этом, мануальные Тестировщики и Аналитики, как и раньше — не будут смотреть код, оперируя лишь сценариями.Fesor
30.05.2017 12:46упрется в ограничения фреймворков и устанет от еще одного DSL-языка.
на самом деле нет, он то не будет работать с этим DSL. Задача автоматизатора в этом плане реализовать стэпы. И да, их будет очень много. А все дублирование можно в реализации стэпов спрятать.
Fesor
30.05.2017 14:45+1немного расширю свой комментарий...
TDD и BDD путают, потому что
потому что когда разработчики знакомятся с BDD слишком много внимания уделяется тестированию а не тому, ради чего BDD собственно задумывалось.
возможно не хватает примеров, но видимо их покажут только на конференции.
на главной странице сайта вполне себе неплохой пример.
Автоматизаторы общаются с Бизнесом, синхронизируют понятия, составляют сценарии
не совсем. Автоматизаторы уже реализуют стэпы, но в формировании сценариев участвовать должны все. Идея в том что бизнес тоже участвует в формировании сценариев. Как минимум читает эти сценарии и может приводить свои примеры требуемого поведения.
но в итоге их перегоняют в обычный код автотестов
в контексте реализаций стэпов — да. Сами сценарии от этого не должны сильно меняться. Они должны оставаться понятными всем членам команды и стэкхолдерам, и как и в любом способе описания требований, максимально абстрагироваться от конкретных деталей вроде деталей UI.
При этом, мануальные Тестировщики и Аналитики, как и раньше — не будут смотреть код, оперируя лишь сценариями.
а зачем аналитикам/мануальным тестировщикам код смотреть? Им как раз сценарии и нужны. Тестировщикам еще полезно знать как чего реализовано чтобы свою работу оптимизировать, но это уже реализация системы а не тесты.
chaetal
30.05.2017 14:23Классное название придумали: из него сразу следует, что TDD — это НЕрабочий метод… Мда…
dezconnect
Ухты, Юля на хабре :)