Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 32
Прекрасная статья, спасибо большое.
Я знаю, но допускаю, что не все пользователи Хабра в курсе. Мне кажется, что аналогия со школой — простой способ объяснить на пальцах для чего это. Подробнее про Gherkin будет в следующей статье.
Безусловно, не все. Для того ссылки и придумали :-)
Спасибо, действительно можно было поставить такую ссылку. В следующий раз учту.
Учесть можно прямо сейчас, тут не запрещают редактировать статьи.
Просто для рубистов будет проще и понятнее, эта идеология растет из огуречного рассола, который настоен на идеологии руби. Человек, у которого в мозгу прописался UML — понимает такие вещи сложнее и неохотнее, чем неофит. По своему опыту говорю.
А вот неофитам — будет именно что полезно почитать про огурцы вообще и их сорт Геркин — в частности.
Просто для рубистов будет проще и понятнее, эта идеология растет из огуречного рассола, который настоен на идеологии руби. Человек, у которого в мозгу прописался UML — понимает такие вещи сложнее и неохотнее, чем неофит. По своему опыту говорю.
А вот неофитам — будет именно что полезно почитать про огурцы вообще и их сорт Геркин — в частности.
Если Википедия не врет, то все-таки это не совсем верно. en.wikipedia.org/wiki/Behavior-driven_development
Gherkin — реализация Given When Then под Огурец, а Dan North не назвал это ни как. Хотя в SpecFlow, да, тоже используется Gherkin, это верно. Но именно в этой части я говорю о форме записи стори, а не технологии, так что оставлю как есть, во избежании холиворов.
Dan North suggested a template for a textual format which has found wide following in different BDD software tools.
This format is sometimes (incorrectly) referred to as the Gherkin language, which is very close to the syntax shown above. Gherkin is however specific to the Cucumber software tool.
Gherkin — реализация Given When Then под Огурец, а Dan North не назвал это ни как. Хотя в SpecFlow, да, тоже используется Gherkin, это верно. Но именно в этой части я говорю о форме записи стори, а не технологии, так что оставлю как есть, во избежании холиворов.
Этот сорт по-русски называется «корнишон», ну уж никак не геркин :)
Отличная статья — просто, чисто и ясно. Т.е., по существу.
Спасибо, автор!
Если позволите, немного занудства — у вас там написано:
«Подавляющее меньшинство людей способно сформулировать...»
'подавляющее меньшинство', на мой взгляд, звучит нелепо. Подавляющим может быть только большинство. А меньшинство — незначительным, пренебрежительным и т.п.
Прощу прощения за замечание.
Спасибо, автор!
Если позволите, немного занудства — у вас там написано:
«Подавляющее меньшинство людей способно сформулировать...»
'подавляющее меньшинство', на мой взгляд, звучит нелепо. Подавляющим может быть только большинство. А меньшинство — незначительным, пренебрежительным и т.п.
Прощу прощения за замечание.
Gojko AdzicСудя по всему, "Гойко Аджич".
Мне приходилось работать с человеком, которого зовут Guillaume Schuermans. Даже его имя никто из команды, в который был русский, белорус и чех, не произнес правильно. С тех пор придерживаюсь правила «не уверен — не играй».
Выделение главного и максимальная автоматизация процесса отлично подходят не только для области тестирования.
Сейчас нахожусь на стадии осознания механизмов, описанных в статье. Некоторые пункты применяются в команде (не называя это BDD), о других и не догадываемся. Спасибо за труд, блаодаря статье я вгляну на некоторые пункты под новым углом.
Сейчас нахожусь на стадии осознания механизмов, описанных в статье. Некоторые пункты применяются в команде (не называя это BDD), о других и не догадываемся. Спасибо за труд, блаодаря статье я вгляну на некоторые пункты под новым углом.
Первая часть — это просто классика QA, даже удивительно, что для кого-то она стала открытием (анализ BRD, совместное написание спецификации). А вот способ описания спецификации мне не понравился, честно говоря (с точки зрения QA, для коллег-разработчиков такой формат, возможно, и правда удобен, но, подозреваю, избыточен). Данная спецификация не дает мне, как тестировщику, никакой новой информации, которой бы не было в BRD. А я в любом случае буду работать с «первоисточником». Примеры сценариев вряд ли так уж обрадуют QA — можно подумать, тестировщик поверить сценариям написанным разработчиком, и не полезет перепроверять BRD самостоятельно и составлять свои собственные сценарии :)
В спецификации мне важнее увидеть архитектуру того как приложение реализовано, возможно схему базы данных, чтобы понять, какие могут быть «узкие места» и каким образом выстраивать тест кейсы или сам процесс тестирования. Расписывать каждый алгоритм совершенно без надобности.
В спецификации мне важнее увидеть архитектуру того как приложение реализовано, возможно схему базы данных, чтобы понять, какие могут быть «узкие места» и каким образом выстраивать тест кейсы или сам процесс тестирования. Расписывать каждый алгоритм совершенно без надобности.
В этом подходе есть несколько преимуществ
- Не предполагается, что примеры пишет разработчик, когда мы работали по этой схеме сценарии писали как QA, так и разработчик. После этого мы оба их правили (QA добавлял правильные кейсы, я помогал с автоматизацией, мы вместе исправляли неточные места). Таким образом, разрушается стена между отделами QA и Dev. Мое личное мнение, что это — очень хорошо.
- Спецификация становится исполняемой, т.е. спецификация, приемочные критерии, приемочные тесты и тест-кейсы — все в одном месте. Документ, который вы составите и будет вашим BRD. (QA не кидайтесь помидорами, сначала посмотрите презентацию Алименкова).
- Избыточность вы должны будете удалить на этапе refining the specification.
- Схему базы данных вообще я предпочел бы не показывать в BRD — клиенту по барабану что у вас там SQLServr, MongoDB или ваш другой теплый ламповый способ хранения данных
- Алгоритмы в спецификации не расписываются — в ней расписываются сценарии. Если вы думаете, что это бесполезная информация, вы, вероятно, не работали с системами, которым по 5-6 лет, спецификацию которых никто не составлял/не поддерживал. Существует даже термин «Code Archiology» — выделение бизнес-логики из кода. Серьезно, такое бывает. В одной компании для составления плана работ мне пришлось опросить 5 человек (в т.ч. начальников всех отделов и ген.директора) и порыться в исходниках, чтобы построить диаграммы процессов.
Суть одна, разница, похоже, только в формулировках. Для меня BRD — это как раз уточненный вариант требований после беседы с Варварой, причем уточнения и/или любые изменения должны быть зафиксированы ее рукой, чтобы не было потом «а это вы сами придумали, мы не знаем с чего вы взяли, что в этом сценарии expected result — такой-то». В том числе и бизнес-логика, для описания которой в больших компаниях есть бизнес-аналитики. То есть на вопрос «что надо сделать» — отвечает только бизнес, Dev и QA лишь обязаны задавать правильные вопросы. Далее, в спецификации, разработчик отвечает на вопрос «как мы это будем делать». Говоря языком Rally, user story — пишется бизнесом, конкретные tasks к ней — разработчиком, test cases — тестировщиком.
Схему базы данных я и предлагаю хранить в спецификации, а не в BRD. Также как и информацию о том используем ли backend-сервис и api в данном случае или все обсчитываем фронтендом.
А в ситуации, где вам пришлось опросить 5 человек, только ли спецификации не было в наличии? Или BRD тоже отсутствовал как класс? Потому что часто проблема именно в этом — в большинстве случаев системы которые я тестировала, к сожалению, не имели спецификации или она была давно неактуальна. Сложности возникали когда даже бизнес-требований не было в наличии.
Схему базы данных я и предлагаю хранить в спецификации, а не в BRD. Также как и информацию о том используем ли backend-сервис и api в данном случае или все обсчитываем фронтендом.
А в ситуации, где вам пришлось опросить 5 человек, только ли спецификации не было в наличии? Или BRD тоже отсутствовал как класс? Потому что часто проблема именно в этом — в большинстве случаев системы которые я тестировала, к сожалению, не имели спецификации или она была давно неактуальна. Сложности возникали когда даже бизнес-требований не было в наличии.
Юлия, этот процесс призван решить следующие проблемы:
В ситуации, где я опрашивал народ, была документация и BRD. Неполная и outdated и без покрытия тестами, так что толку от этой спеки не было.
Попробуйте смотреть на проблему немного шире. Это как раз решение для реального мира, а не коней в вакууме.
- Необходимость дублирования данных — BRD, Test Cases, техническая спецификация. С помощью такой записи мы получаем это в одном файле с описание стори. В этот файл входит user-storiy, сценарии, примеры.
- Устаревание спецификации. Конечно это надо подписать. Никто не спорит, но дальше у Вас будут чейндж-реквесты. Вам придется внести их в BRD, поправить тест-кейсы и тест-план, исправить логику, определить, какие тесты более не актуальны. В данном случае все произойдет «автоматом». Пришел чейндж-реквест: не беда. Убираем лишнии сценарии или шаги из сценариев. Соответствующие тесты автоматически перестанут выполняться (как это происходит, я опишу вследующей статье)
- «Неправильные стори». Нельзя давать бизнесу диктовать стори. У клиента может быть слишком узкое видение. Есть пример с Бельгийской компанией, которая хотела разработать веб-приложение, вместо существующего десктопного из-за того, что они выросли и вместо 1 клиента стало много. Разработку оценили в 40.000 евро, кажется. Проблему решили тем, что вытащили десктопный-клиент на RDP и административными мерами разрешили заходить на RDP одним с 13:00 до 13:30, другим с 13:30 до 14:00 и т.д. Специфика системы была такова, что частое обновление данных не требовалось, а на чтение все работало отлично, через открытый порт. Решилось за 500 евро и 2 дня работы
- Далеко не в каждой компании есть аналитик, который, особенно, запишет требования в адекватном техническом виде, мы живем реальном мире
В ситуации, где я опрашивал народ, была документация и BRD. Неполная и outdated и без покрытия тестами, так что толку от этой спеки не было.
Попробуйте смотреть на проблему немного шире. Это как раз решение для реального мира, а не коней в вакууме.
Напишешь другие статьи из цикла, вопросы многие отпадут. По крайней мере сможешь ссылаться на них. Ну или хотя бы Опиши какие еще вопросы будут обсуждаться в след. статьях, чтобы люди четко понимали что следует спрашивать, а что подождать
Эта статья – первая в цикле «BDD для прагматиков». В ней описаны ключевые элементы наиболее эффективного, на мой взгляд, процесса разработки коммерческого ПО в современных условиях. Два продолжения будут посвящены работе со SpecFlow и автоматизации приемочного тестирования.
SpecFlow — плагин для Visual Studio — такой Cucumber для .NET. Будут рассмотрены базовые понятия и сложные сценарии.
Последний пост будет про то, как к этому привязать Selenium WD, встроить в CI и создавать автоматические отчеты.
Пункт три опять же некорректен. Вы приводит пример в комментарии с тем КАК требования были реализованы, разумеется это должно быть в спеке и писаться разработчиками. В посте же вы приводит пример уточнения непосредственно требований, и вот после всех заданных вопросов детали и раз'яснения должен внести именно бизнес.
Другое дело, если вы в ситуации, где у вас есть клиент, который с трудом может сформулировать что ему нужно, не говоря уж о том, чтобы написать нормальное тз. И со стороны исполнителя ни продаёт менеджера, ни аналитика нет. Тогда понятно, что нет смысла, совмещая две роли (аналитика и разработчика или аналитика и qa) создавать два отдельных документа. Но я бы предпочла, чтобы люди при этом осознавали, что это именно вариант совмещения двух функций, а не воспринимали это как «новую чудесную методологию, которая всех нас спасёт». А то получится как с эджайлом, который тащат даже в проекты, по сути водопадные.
Преимущество отдельной документации в том, что если требования не изменялись, то спектр может переписываться сколько угодно без привлечения заказчика («а теперь мы перепишем все заново, на другом языке, и со своей базой отдельной от не родственного нам проекта»).
Другое дело, если вы в ситуации, где у вас есть клиент, который с трудом может сформулировать что ему нужно, не говоря уж о том, чтобы написать нормальное тз. И со стороны исполнителя ни продаёт менеджера, ни аналитика нет. Тогда понятно, что нет смысла, совмещая две роли (аналитика и разработчика или аналитика и qa) создавать два отдельных документа. Но я бы предпочла, чтобы люди при этом осознавали, что это именно вариант совмещения двух функций, а не воспринимали это как «новую чудесную методологию, которая всех нас спасёт». А то получится как с эджайлом, который тащат даже в проекты, по сути водопадные.
Преимущество отдельной документации в том, что если требования не изменялись, то спектр может переписываться сколько угодно без привлечения заказчика («а теперь мы перепишем все заново, на другом языке, и со своей базой отдельной от не родственного нам проекта»).
Отличная статья. Спасибо.
Есть пара вопросов.
Насколько мне известно, в России, product owner чаще всего не участвует (не хочет или отказывается выделить от себя специалистов в предметной области) в проектировании (разработке) ПО.
Каков ваш опыт с точки зрения практики в вопросе привлечения стороны заказчика к проектированию\разработке ПО?
Насколько сложно это сделать и кто этим должен заниматься?
И ещё вопрос: нужны ли программисты на встречах с заказчиком? (наш тимлид считает, что не нужны).
Как я понял «составление спецификации» работа коллективная, верно? А кто этим (составлением спецификации) управляет? Тимлид?
Есть пара вопросов.
Насколько мне известно, в России, product owner чаще всего не участвует (не хочет или отказывается выделить от себя специалистов в предметной области) в проектировании (разработке) ПО.
Каков ваш опыт с точки зрения практики в вопросе привлечения стороны заказчика к проектированию\разработке ПО?
Насколько сложно это сделать и кто этим должен заниматься?
И ещё вопрос: нужны ли программисты на встречах с заказчиком? (наш тимлид считает, что не нужны).
Возьмите на себя ответственность и составьте спецификацию сами в том виде, в котором вам будет удобно работать.
Как я понял «составление спецификации» работа коллективная, верно? А кто этим (составлением спецификации) управляет? Тимлид?
Продукт оунер — не обязательно представитель клиента. Если клиент «вялый», то в роли продукт оунера может выступать тандем представитель клиента + аккаунт менеджер / PM.
Насколько мне известно, в России, product owner чаще всего не участвует (не хочет или отказывается выделить от себя специалистов в предметной области) в проектировании (разработке) ПО.Мой опыт таков, что последние два года я работаю в основном с иностранными клиентами. Таких проблем не возникает. Российские, на самом деле, тоже поддаются «воспитанию». Главное не грузить их своими BDD, Agile и прочими техническими штуками. Хорошо помогают прототипы и разговоры на уровне «какое поведение мы ожидаем от системы». Любой адекватный клиент хочет получить качественный продукт за разумные деньги. Главное донести, что, чем лучше будет фидбек с его стороны, тем выше вероятность успешного релиза.
Каков ваш опыт с точки зрения практики в вопросе привлечения стороны заказчика к проектированию\разработке ПО?Не сложно, PM/TL.
Насколько сложно это сделать и кто этим должен заниматься?
И ещё вопрос: нужны ли программисты на встречах с заказчиком? (наш тимлид считает, что не нужны).Смотря какие программисты, смотря на каких встречах. В общем случае junior'ы не нужны. Senior и Architect могут быть нужны, особенно на сложных встречах типа «сколько будет стоить написать систему для автоматизации стадиона».
Как я понял «составление спецификации» работа коллективная, верно? А кто этим (составлением спецификации) управляет? Тимлид?Классическая схема: стори пишут PO/BA + TL/PM. Тестовые сценарии PO/BA + QA/Dev. Вообще может быть по-разному. Agile же, кросс-функциональные команды, все такое.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Specification By Example – BDD для прагматиков