Комментарии 23
Имхо, BDD было модным словом лет 7-8 назад…
А по отличиям всё просто: есть такая штука, функциональная спецификация называется, это документ, согласно которому составляется тест-план приёмочного тестирования. BDD призван автоматизировать этот процесс.
А TDD работает на уровне юнит-тестов, т.е. помогает продумывать детали реализации и отлавливать ошибки на этом уровне.
TDD — тесты вперед кода.
BDD — опиши чего ты хочешь, как пользователь, чтобы код понял даже не разработчик.
Чего тут путать то?
В разработку сценариев BDD вовлечены не только тестировщики, необходимость в автоматизаторах сохраняется?
Не очень понял вопроса, а следовательно и ответа. Разве текст behavior-тестов (по статье ощущение, что они прямо на русском пишутся, так?) не является артефактом работы автоматизатора тестирования? Вместо ручного прохождения сценария "по бумажке" автоматизатор пишет тест и настраивает/запускает его прогон? Или теперь написание автотестов не входит в основные обязанности автоматизаторов тестирования?
То есть по сути это ручные тестировщики начали заниматься азами автоматизации тестирования )
Вы тоже это заметили? (про вопрос)
Дело в том, что в Альфа-Лаборатории написанием BDD-историй (feature/story-файлов) занимается именно аналитик-тестировщик, но никак не автоматизатор. Автоматизатор может быть привлечен на стадии старта проекта, когда возникают сложные ошибки, когда требуется написать сложный шаг на Java, обучить тестировщика писать простые шаги на Java и все. Сам же тестировщик-аналитик является частью скрам-команды, поэтому он может смело обращаться за помощью к ней же и с учетом того, что многие команды у нас практикуют парное программирование, помощником может стать любой разработчик или же системный аналитик.
Автоматизатор же в свободное от помощи и обучения тестировщиков время занимается у нас задачами по инфраструктуре в тестировании, интеграцией со сторонними и собственными решениями, созданием и поддержкой инструмента автоматизации UI тестов.
получать новую документацию налету, хранить ее вместе с проектом, что позволило приблизить аналитиков и тестировщиков к коду
Подскажите пожалуйста, это пользовательская документация или набор given when then?
Смотря с какой стороны посмотреть. Да, это Given When Then, но если правильно структурировать, согласовать формат плюс добавить asciidoc, то и пользовательская документация тоже.
мне нравится проект picklesdoc.com. Там как раз таки идея в том чтобы использовать gherkin сценарии как способ ведения документации по проекту. Очень много плюсов в плане того что эта документация реже будет выходить из синхронизации с реализацией.
целью которого является удешевление реализации новых фич
ну вообще уменьшение издержек связанных со стоимостью перевода требований из языка бизнеса в язык понятный разработчику. Просто "удешевление" звучит слишком просто.
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-языка.
При этом, мануальные Тестировщики и Аналитики, как и раньше — не будут смотреть код, оперируя лишь сценариями.
упрется в ограничения фреймворков и устанет от еще одного DSL-языка.
на самом деле нет, он то не будет работать с этим DSL. Задача автоматизатора в этом плане реализовать стэпы. И да, их будет очень много. А все дублирование можно в реализации стэпов спрятать.
немного расширю свой комментарий...
TDD и BDD путают, потому что
потому что когда разработчики знакомятся с BDD слишком много внимания уделяется тестированию а не тому, ради чего BDD собственно задумывалось.
возможно не хватает примеров, но видимо их покажут только на конференции.
на главной странице сайта вполне себе неплохой пример.
Автоматизаторы общаются с Бизнесом, синхронизируют понятия, составляют сценарии
не совсем. Автоматизаторы уже реализуют стэпы, но в формировании сценариев участвовать должны все. Идея в том что бизнес тоже участвует в формировании сценариев. Как минимум читает эти сценарии и может приводить свои примеры требуемого поведения.
но в итоге их перегоняют в обычный код автотестов
в контексте реализаций стэпов — да. Сами сценарии от этого не должны сильно меняться. Они должны оставаться понятными всем членам команды и стэкхолдерам, и как и в любом способе описания требований, максимально абстрагироваться от конкретных деталей вроде деталей UI.
При этом, мануальные Тестировщики и Аналитики, как и раньше — не будут смотреть код, оперируя лишь сценариями.
а зачем аналитикам/мануальным тестировщикам код смотреть? Им как раз сценарии и нужны. Тестировщикам еще полезно знать как чего реализовано чтобы свою работу оптимизировать, но это уже реализация системы а не тесты.
BDD — рабочий метод или TDD в модной обертке?