Все зависит от того, какой у вас процесс в автоматизации: кто и как пишет сценарии, кто реализуем шаги, что идет сначала — реализация или сценарий (правильно написал crowCcrow в ответе к предыдущему комменту про проблему забивания на идею проверки).
Имхо, BDD действительно не всегда нужен, не всем он подходит. Но если проблема в удобстве именно использования инструмента (aka сложно поддерживать, много путаницы со сценариями), а не подхода в целом, то сам BDD-подход, стало быть, тут не при чем. Возможно, стоит поискать проблемы в том, как именно используется инструмент :)
Кто ревьюирует их — другие тестировщики только?( как разработчики узнают об изменениях или аналитики)
У нас изначально использование Cucumber планировалось как часть BDD-подхода, но потом свелось к инструменту для ведения документации, поэтому ревьюят в основном автоматизаторы и тестировщики
Как оценить что эти «анипаттерны» помогают? улучшилось ли после рефакторинга легаси что-то? Скорость написания, ревью или только стали читабельнее?
Улучшенная читабельность — уже немало :) от нее все идет: проще ориентироваться в собственных сценариях > проще увидеть узкие места в них, отсеять лишнее, добавить недостающее.
Скорость написания самих сценариев по началу может даже немного просесть, так как, очевидно, первоначально потребуется больше времени на ревью. Да и более вдумчивое составление сценариев — в целом задача не из быстрых, но оно окупается.
Меньше мусора и больше осмысленности помогли нам сократить время на последующую поддержку и актуализацию и, конечно же, облегчили использование авто-сценариев, чтение и анализ результатов прогонов (в том числе другими членами команды).
Как справляетесь с такой проблемой, что автотесты становятся вещью в себе? Например, есть где-то группа автотестеров/один аатотестер и пишет себе сценарии, вроде есть автотесты, а вроде их и нет.
Автотесты не превращаются в вещь в себе, если их актуализировать по мере развития продукта. Делают ли это автоматизаторы, общаясь с разработчиками и аналитиками непосредственно, или же обновляют авто-сценарии в соответствии с уже готовыми тест-кейсами тестировщиков, — главное, поддерживать автотесты актуальными. К этому можно много чего отнести — от соответствия текущему состоянию продукта до целесообразности конкретных проверок в принципе. В противном случае, да, автотесты будут нести больше вреда, чем пользы.
Bdd не только про выразительность, но и про понимание\участие в разработке тестов не только автоматизаторов, но и аналитиков/разработчиков/ представителей бизнеса.
Это точно. Но и надо ли говорить, что BDD в чистом виде — большая редкость. Намного чаще Cucumber как инструмент используют для ведения живой документации. Потому и стала актуальна эта проблема — потеря выразительности, которая по сути и является одним из ключевых условий составления хороших спеков.
В нашей компании подход к разработке осознанно не унифицирован, — он может разниться от проекта к проекту. В некоторых командах у нас внедряются практики DDD в данный момент, но это не стандарт, поскольку не все команды считают, что DDD позволит улучшить их процесс.
DDD хорошо работает в связке с BDD и призван скорее дополнить его, чем заменить. Гойко Аджич много занимался вопросами взаимопонимания внутри команды и утверждал, что без общепонятного языка «ubiquitous language» (который и есть часть DDD), его не достичь. Объединить эти 2 подхода в разработке — хорошая идея в целом. Ведь если есть общепонятный язык, то он как раз и должен использоваться для описания документации в BDD-стиле.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Имхо, BDD действительно не всегда нужен, не всем он подходит. Но если проблема в удобстве именно использования инструмента (aka сложно поддерживать, много путаницы со сценариями), а не подхода в целом, то сам BDD-подход, стало быть, тут не при чем. Возможно, стоит поискать проблемы в том, как именно используется инструмент :)
Кейсы, как правило, составляются до разработки, автоматизация — вместе с ней.
У нас изначально использование Cucumber планировалось как часть BDD-подхода, но потом свелось к инструменту для ведения документации, поэтому ревьюят в основном автоматизаторы и тестировщики
Улучшенная читабельность — уже немало :) от нее все идет: проще ориентироваться в собственных сценариях > проще увидеть узкие места в них, отсеять лишнее, добавить недостающее.
Скорость написания самих сценариев по началу может даже немного просесть, так как, очевидно, первоначально потребуется больше времени на ревью. Да и более вдумчивое составление сценариев — в целом задача не из быстрых, но оно окупается.
Меньше мусора и больше осмысленности помогли нам сократить время на последующую поддержку и актуализацию и, конечно же, облегчили использование авто-сценариев, чтение и анализ результатов прогонов (в том числе другими членами команды).
Автотесты не превращаются в вещь в себе, если их актуализировать по мере развития продукта. Делают ли это автоматизаторы, общаясь с разработчиками и аналитиками непосредственно, или же обновляют авто-сценарии в соответствии с уже готовыми тест-кейсами тестировщиков, — главное, поддерживать автотесты актуальными. К этому можно много чего отнести — от соответствия текущему состоянию продукта до целесообразности конкретных проверок в принципе. В противном случае, да, автотесты будут нести больше вреда, чем пользы.
Это точно. Но и надо ли говорить, что BDD в чистом виде — большая редкость. Намного чаще Cucumber как инструмент используют для ведения живой документации. Потому и стала актуальна эта проблема — потеря выразительности, которая по сути и является одним из ключевых условий составления хороших спеков.
В нашей компании подход к разработке осознанно не унифицирован, — он может разниться от проекта к проекту. В некоторых командах у нас внедряются практики DDD в данный момент, но это не стандарт, поскольку не все команды считают, что DDD позволит улучшить их процесс.
DDD хорошо работает в связке с BDD и призван скорее дополнить его, чем заменить. Гойко Аджич много занимался вопросами взаимопонимания внутри команды и утверждал, что без общепонятного языка «ubiquitous language» (который и есть часть DDD), его не достичь. Объединить эти 2 подхода в разработке — хорошая идея в целом. Ведь если есть общепонятный язык, то он как раз и должен использоваться для описания документации в BDD-стиле.