Автоматизация в agile. Правильный подход ?!

Сегодня перечитывал хорошие слайды о тестировании и в том числе автомтизации в agile проектах. Cлайд по ATDD говорит следующее:

Acceptance test driven development

Т.е. договариваемся - на нас выделают время в том числе,
уточняем - что мы должны покрыть
разрабатываем - по хорошему, сначала пишутся тесты или прототипы, а потом код
показываем.

Только вот в реальной жизни так не получается. Я работаю на удаленном проекте. Разрабатываем сайт. Как-то по этой схеме работа вообще не идет.

Получается так: прибежал главный и сказал делаем, обсуждаем, делаем, обсуждаем, делаем, а иногда меня как тестера (конечно же такой роли нет в agile) могут и не включить в разговор, а потом раз и код уже на продакшине без моего ведома :). Есть главный программист, который юнит тесты с принципе отказывается делать, даже немогу понять почему.

Собственно вопрос, совпадает ли схема указанная выше с реальной жизнью у вас?

В добавок, припоминается мне фраза: "Automating chaos just gives faster chaos." Что переводиться как "автоматизация хаоса просто дает более быстрый хаос".

Я так понял, что эта схема описывает BDD (Behavior Driven Development) подход к написанию ?

На проекте, где я сейчас, отказались от BDD, но работаем по TDD. Но наслышан от друзей, которые на проектах, где вначале пишутся тесты на "геркине" (Gherkin) бизнес аналитиками, а дальше дело за разработчиками.

В целом ничего критично отличного от TDD, главное чтобы заказчик был заинтересован в подобного рода тестировании. 

Вот с теми программистами, которые не понимают смысла юнит-тестов, очень тяжело. Даже если они и начнут их писать, то толку от таких тестов будет мало.

 

Очень похоже, но это не BDD, а Acceptance TDD. Различия только в том, что в БДД, код уже представляет выполняемые требования, посредством описания системы человечиским языком. В АТТД, просто оговаривается, что важно и нужно для заказчика и дальше пишутся оговариваются, какие тесты нужно будет прогнат для того, чтобы функционал был принят заказчиками в конце.

А по поводу, юнит тестов, да тут действительно очень тяжело, сам это почувствовал. Просто, если нет юнит тестов, то и гибкости никакой нет, т.е. вносить изменения в код просто не получается.
Проблема, отчасти, что это удаленный проект и делать изменения "умов" очень тяжело через почту или коммуникатор. 

Спасибо, понял. 

 

Надеюсь, вы не будете долго работать на этом проекте Smile

Ну даже не знаю, при всем несовершенстве проекта и процессов, деньги нормальные. Потому как всегда, либо одно либо другое :)

Executable Specification

Читал недавно Тестинг Планет и увидел отображение правильных процессов в Agile и автоматизации на основании спецификаций с примерами. Захотелось показать. Автор -  Gojko Adzi (http://gojko.net/)