Автоматизаторы Шрёдингера

[@qwez]

Так что в итоге то с автотестерами стало? :)
Всех разогнали и автотесты разработчики пишут? А тест кейсы для конкретной фичи кто формирует?

И еще вопрос: зачем вам Specflow? Без сарказма, реально интересно. Просто во всех случаях, которые встречал, эти ваши кукумберы использовали только потому, что модно.

[@k_valiev]

Так что в итоге то с автотестерами стало?

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

… автотесты разработчики пишут? А тест кейсы для конкретной фичи кто формирует?

В компании каждая команда разработки состоит из 4 DEV и 2 QA. Тест кейсы формитуют QA, так же они формируют сценарий в SpecFlow. Если не хватает реализаций в автотестах внутри команды решают кому это будет сделать проще, чаще всего это DEV.

зачем вам Specflow?

SpecFlow из коробки предоставляет огромное количество фич, реализация их для framework задача очень трудозатратная. Мы в одном из проектов брали BddFy и доводили его до нужного состояния, на проработку основного функционала потребовалось 2 месяца dev (верхнеуровневая архитектура + DI + converter-ы + читабельный report), а это все еще и поддерживать надо самим.

Или вопрос про BDD подход?

[@qwez]

Или вопрос про BDD подход?

В целом, я про еще один слой абстракции, который позволяет писать тесты на псевдоязыке. Это сейчас уже синонимом BDD стало (по правде то — нет).
Ну, т.е. мне кажется проще немного подучить тестеров, чтобы они писали тесты кодом, сделать для них API удобный. Чем поддерживать этот псевдоязычный API.

[@k_valiev]

Уже упомянутый BddFy не имеет Gherkin syntax(псеводоязыка) при этом реализует BDD подход. Gherkin syntax определяет правила описания сценариев, которые совпадают с правилами написания тест кейсов, что позволяет определить однозначное соотвествие между автотестами и набором регрессионных тестов ручных тестировщиков, поэтому его использование это вполне логичный шаг, а не просто модно. BDD подход разделяет сценарии и реализации шагов, что позволяет без дублирования кода из шагов формировать сценарии, что так же является логичным шагом.

Если сомнение именно в псевдоязыке, то есть другие BDD Framework, реализующие правила Gherkin syntax, при этом без псеводоязыка. SpecFlow(cucumber) будет выигрывать за счет возможностей. По крайней мере в мире .Net это так, аналогов SpecFlow по возможностям нет. Для меня killer feature-ами в SpecFlow являются:
1. Встроенный DI контейнер;
2. Встроенная система расширения поведений за счет хуков. Она неявная — это минус, но то, что у меня чистые сценарии, без различных инфраструктурных настроек — это очень удобно;
3. Встроенная система плагинов;
4. У меня с самого начала понятные формулировки степов, поэтому после того, как произошел мапинг результатов во внешнюю систему, я без труда понимаю, что происходило в этом сценарии;

сделать для них API удобный

Это дорого. SpecFlow(cucmber) — определенный стандарт, а это значит, что есть множество third-party libraries, что инструмент активно развивается.