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