• Опыт использования BDD
    +1
    Изначально инициатива использования BDD шла от зарубежного заказчика, поэтому было немного проще. Сейчас мы пробуем использование на другом проекте, но тут уже есть интерес у наших аналитиков. Сложность заключается в том «как писать?», поэтому первая задача в данном случае правильно назвать шаги, что бы ими было удобно оперировать. Помимо этого очень большое значение дает понимание команды, в каких частях общей работы получится выгода. Если понимания нет, то и «заставить» никого не получится
  • Смок-тестирование релиз-кандидата автотестами за 15 минут
    0
    «но всё внезапно становится сложно когда нужно передавать состояние из шага в шаг или хочется прокидывать в тест сложные объекты». Скажу на примере фреймворка Gauge, но у Cucumber тоже есть такие механизмы — передача параметров между степами, они хранятся в рамках сьюта, их можно записывать и получать. Не скажу про «сложные объекты», т.к не указано, что именно нужно нужно передать.
  • Опыт использования BDD
    0
    BDD это дополнительный слой абстракции, тут согласен. С другой стороны это возможность написать автотест тестировщику, который пока никак не дружит с кодом.
    По поводу костыелей при имплементации: это проблема. Контролы могут быть разные, технологи разные. Но мы как раз и упомянули в статье о проблемах реализации BDD, в некоторой степени нам помогла библиотека Masquerade, в некотрой степени изменение процесса.
    Если стабильные степы (шаги) падают, то тут уже полет фантазии, если это связано с особенностью работы с новым функционалом, то возможно придется плодить несколько вариантов практически одного и того же, либо усложнять текущий.
  • Опыт использования BDD
    0
    Предположу, что варианты шагов нужно упростить, либо переписать в таком виде, как будет удобно воспринимать большинству. Имплементаций остается, а именование меняется, ну либо создается чуть больше частных случаев.
  • Опыт использования BDD
    0
    Про кукумбер скажу — есть знакомые, кто пишет без знания движка под капотом. Есстественно всему нужно некоторое время подучиться, как в случае с примером о «service._»
    По поводу сложности: действительно есть сложность в том случае, если аналитик не знает каким глоссарием оперировать. Если система разработки не подсказывает или не подсказывает утилита в которой есть список этих фраз, то шаги будут записаны в произвольной форме, и их нужно будет корректировать, но все же проще подкорректировать одну точку входа, чем синхронизировать тестовую документацию, описание требований и автотест.
  • Опыт использования BDD
    0
    Согласен с тем, что не каждый аналитик пишет тесты ) Для аналитика является хорошей практикой описывать юзер кейсы, т.е описывать как (и зачем) поведет себя пользователь и система, т.е. ожидаемый результат. И это является почти тем же самым что и описание сценария. Вопрос в том, ставилась ли задача работать по BDD, если да, то вся команда должна понимать, что мы делаем с требованиями, соответственно когда их записываем, кто отвечает за результат того что записали, а это результат всего взаимодействия заказчика и исполнителя.
  • Опыт использования BDD
    0
    Gennadii_M спасибо за первый комментарий )
    Суть BDD как раз в том, что бы точка входа была одна, т.е. что бы требования соответствовали тому, как будет тестироваться. В вашем же случае возникат вопрос, документация требований, тестовая документация у вас ведется отдельно? И сами тесты никто не смотрит, кроме службы QA? Описанный Вами пример больше соответствует TDD, хотя упомянули то, что не пишете тест до разработки, получается TLD. Написание тестов на фреймворке jUnit с поведенческой точки зрения это логично, у нас тоже использовалось раньше и используется сейчас, но там нет связи с материалом, который поймет заказчик. Если взять частный случай, на примере нашей компании, то для обхода этой ситуации у нас есть решение. Для того что бы связать jUnit и читаемое любым человеком языком описание есть инструмент QA Lens, который мапит jUnit тесты на документацию.
    Скажите, пожалуйста, если не серет, почему нежелательно писать текстовое описание, который поймет не технический специалист? И какой фреймворк использовался?