BDD как альтернатива исчерпывающей документации
“Работающий продукт важнее исчерпывающей документации”
- говорили они, и многие поняли их слишком буквально.
В 2001 году, когда создавался Agile Manifesto, мир разработки программного обеспечения был немного иным. Все устали от больших и долгих проектов, которыми сложно было управлять. Много сил и времени уходило на подготовку полноценных технических заданий, а еще больше сил - на их реализацию. Отсутствовала прозрачность, не ощущалась динамика, команды выгорали. В таких условиях, или, лучше сказать, благодаря этим условиям и зародился Agile.
Scrum, как полноправный представитель Agile, приходил на помощь в отчаявшиеся команды, которые были в шаге от провала, и творил чудеса. Если верить написанному в одноименной книге Scrum от Jeff Sutherland, Scrum улучшал эффективность работы команд на 400%. Оно и не удивительно, оттолкнувшись от самого дна, организовав процессы под руководством опытного тренера, улучшить результаты команды в 4 раза вполне возможно. Но, чтобы добиться такого, вероятно, нужно от чего-то отказаться, что отнимало много времени и сил и не давало особого результата. Как говорится, чтобы купить что-нибудь ненужное, нужно сначала продать что-нибудь ненужное. И в Agile так и происходит, о смене акцентов нам говорят 4 ценности:
1. Люди и взаимодействие важнее процессов и инструментов.
2. Работающий продукт важнее исчерпывающей документации.
3. Сотрудничество с заказчиком важнее согласования условий контракта.
4. Готовность к изменениям важнее следования первоначальному плану.
Многие поняли вторую ценность так: “Главное, чтобы продукт работал, а документацию можно и не делать/не поддерживать”. К счастью компаний, занимающихся разработкой мобильных приложений, там где жизненный цикл проекта относительно недолгий, им действительно можно обойтись без создания полноценной документации. Если проект длится не более 6 месяцев, все участники команды, да и клиент в том числе, в состоянии удержать в голове весь контекст проекта и создать продукт, которым клиент будет доволен. Но на этом лучше и закончить, ведь продолжать проект дальше: вносить мажорные изменения, погружать новых разработчиков в проект, обеспечивать должное качество продукта - все это в отсутствие документации будет чрезвычайно болезненно. Еще более везучими оказываются те, кто без документации делает оценку на fixed price проекты и укладывается в нее, либо им удается повесить все свои промахи на плечи клиента.
Но нам интересны компании, которые ведут честный бизнес, которые болеют за качество продукта, которые за долгосрочные отношения и объемные проекты. Таким компаниям заделать брешь в виде отсутствующей документации помогает ATDD (acceptance test-driven development), в который они пришли из TDD (test-driven development), или BDD (behaviour-driven development), или просто начали сразу с ATDD и у них все получилось.
Прошу не относить слово behaviour исключительно к поведению (взаимодействию) пользователя в системе. Behaviour здесь имеет более общий смысл, относящийся к поведению всей системы в целом. Это может быть какое-то событие или действие.
ATDD никоим образом не пытается соперничать с полноценной “исчерпывающей документацией”, которую создают опытные аналитики и архитекторы. Исчерпывающая документация - это своего рода меч катана от искусного мастера. Его сложно заполучить, он дорого стоит, служит одной конкретной цели, и пользоваться им могут только специально обученные люди. В то время как ATDD - это швейцарский нож, который стоит недорого, служит сразу нескольким целям, и пользоваться им может любой подросток. Какой из этих двух предметов полезней - зависит от решаемой задачи, однако опыт показывает, что чаще всего нас выручает швейцарский нож.
Благодаря ATDD создается контекст проекта, понятный всем действующим лицам: клиенту, менеджеру, разработчикам, тестировщикам. Обычно acceptance tests имеют следующую форму:
Given
Условие, описание устойчивого состояния системы
When
Триггер, какое-то событие или действие
Then
Контроль, состояние системы сменилось либо на выходе получился какой-то результат
и прекрасно дополняют user stories, показывая на конкретных примерах, как должна функционировать система. Вот довольно лаконичный пример их сочетания:
Returns and exchanges go to inventory.
As a store owner, I want to add items back to inventory when they are returned or exchanged, so that I can track inventory.
Scenario 1: Items returned for refund should be added to inventory. Given that a customer previously bought a black sweater from me and I have three black sweaters in inventory, when they return the black sweater for a refund, then I should have four black sweaters in inventory.
Scenario 2: Exchanged items should be returned to inventory. Given that a customer previously bought a blue garment from me and I have two blue garments in inventory and three black garments in inventory, when they exchange the blue garment for a black garment, then I should have three blue garments in inventory and two black garments in inventory.
Простой и понятный язык позволяет избавиться от расплывчатых определений и любой двойственности в понимании написанного.
Ведь как это обычно бывает, например, в разработке мобильных приложений на заказ: приходит клиент, приносит макеты дизайна и некое “техническое задание”, как он сам его называет. Для лихих компаний этого достаточно, чтобы пуститься с места в карьер. Но по факту этой информации крайне мало, чтобы дать точную оценку и синхронизировать ожидания клиента с планами команды. Дизайн часто бывает неполным, а про техническое задание лучше вообще не говорить. А если в игру вступает ATDD, то все тайное становится явным: ошибки сервера, отсутствие интернета, незаполненные поля, подтверждающие диалоги, зависимость одних элементов интерфейса от других, и многое другое…
Но, пожалуй, главный козырь ATDD заключается в том, что, при соблюдении должных требований к написанию, эти сценарии можно автоматизировать.
Таким образом, созданные сценарии помогают:
- клиенту и команде прийти к общему знаменателю в требованиях к функциональности проекта;
- команде лучше понять проект и дать точную оценку на его реализацию;
- команде в процессе реализации не упустить ни одну важную для клиента и проекта деталь;
- тестировщикам в ручном функциональном тестировании проекта, а также в регрессии;
- всем, когда сценарии автоматизированы, ведь это экономит время, деньги и дает уверенность в качестве результата;
- клиенту, который получает не просто исходный код, но и живую документацию к нему.
Почему “живую” документацию? Потому что она живет (если вы ей помогаете, конечно) и меняется вместе с проектом и с требованиями клиента. Документацию нужно поддерживать в актуальном состоянии во все времена, только тогда она сохранит свою пользу. Благо язык документации достаточно прост и вносить изменения не сложно.
Однако, за этой простотой стоит достаточно долгий процесс внутри компании-разработчика.
- Процесс начинается от понимания философии TDD: чтобы создать нужную вещь правильно, нужно не торопиться ее создавать, а сначала продумать, как ты убедишься в том, что создал ее правильно.
- Продолжается пониманием ценности и важности BDD, как процесса взаимодействия всей команды - без документации в виде конкретных примеров внутри команды каждый может понять требуемый результат по-разному.
- Завершается пониманием того, что без сформулированных критериев приемки ATDD невозможно сдать результат работ и убедиться в его качестве.
Но одного понимания, как мы знаем, недостаточно. Важна практика. Написание качественных сценариев - это не быстрый и эмоционально изматывающий процесс. Кажется, что во время работы над сценариями ты напрягаешь в голове те извилины, которые никогда раньше не напрягал. Сначала это причиняет боль, перетерпев которую начинает получаться лучше, а потом уже идет как по маслу, где-то даже вдохновляя и принося удовольствие.
Постепенно команда проникается идеей BDD и начинает предлагать рационализаторские улучшения:
- создание глоссария для сценариев;
- создание шаблонных сценариев, часто повторяющихся в разных проектах;
- кросс-платформенные инструменты для автоматизации тестирования;
- обучающие сессии для тех сотрудников, кто еще не писал сценарии сам.
Это есть явное подтверждение тому, что философия BDD прижилась и успешно развивается уже внутри самой команды.
Мое знакомство с BDD началось с прочтения книги BDD In Action by John Fergusson Smart. Теперь, спустя почти три года, как мы начали работать по ATDD, мне сложно представить себе, как оценивать новый проект без сценариев, как разрабатывать что-либо без сценариев, как это потом тестировать и гарантировать качество клиенту. Выходит, что ATDD, как подход, заполнил ту пустоту, которая раньше была заполнена “исчерпывающей документацией”, но в Agile ей места не нашлось.
Я не настаиваю на том, что ATDD единственный верный путь, каждая компания должна выбирать свой путь самостоятельно. Я лишь говорю, что когда-то мы этот подход попробовали, нам понравилось, и теперь мы не представляем, как можно без него обойтись. Этому действительно легко научиться, но крайне сложно овладеть.