Когда сценарии тестирования BDD должны быть записаны? [закрытый]
4 ответа
Как правило, в Scrum вам нужны пользовательские истории, которые также имеют условия удовлетворения, чтобы идти вместе с ними. Это означает, что если эти условия будут выполнены, то я, как владелец продукта, буду удовлетворен тем, что история завершена.
Лучше всего, если эти условия будут написаны владельцем продукта, а еще лучше, если они будут написаны в формате Given/When/Then. Таким образом, команда может создавать BDD-тесты на основе условий удовлетворения. Когда тесты пройдут, история будет завершена.
Условий удовлетворения должно быть столько, сколько владелец продукта считает необходимым для подтверждения того, что история была реализована, и эти условия должны быть подготовлены к встрече по планированию спринта. Их не обязательно кодировать, но они должны быть прописаны, чтобы команда имела представление о том, что ожидается для завершения истории.
Команда может добавлять свои собственные BDD-тесты в течение спринта по мере появления новых, но история не будет завершена, пока не пройдут первоначальные BDD-тесты.
Надеюсь, вы упомянули о поведенческой разработке. Если я прав, это процесс взаимодействия с разработчиками, QA и нетехническими или бизнес-участниками. Это также цель и польза кода разработчиков. Вы можете начать сценарий Скрама во время предварительного планирования.
Оценка и расстановка приоритетов не являются его частью.
, если вы ищете BDD (также известную как разработка на основе приемочного тестирования), вы можете желающие начать писать приемочные тесты достаточно рано, до того, как начнется планирование спринта. Некоторые другие «более гибкие» подходы, как правило, откладывают это до последнего ответственного момента, и я тренировал пару команд, где критерии приемлемости со временем уточняются также во время спринта.
«Тестировщики» группы разработки тесно сотрудничают с владельцем продукта во время подготовки бэклога к следующему спринту (это называется упреждающим), а также во время текущего спринта они обогащают критерии приемки, когда видят подходят в соответствии с ЗП.
Это в значительной степени зависит также от того, как вы выполняете эти тесты ... если вы умеете автоматизировать, то все гораздо яснее :-) Мы широко используем Cucumber или Fitnesse для автоматизации приемочных тестов, а также вы бы сделали с TDD (без A) вы бы попытались сделать это до того, как произойдет обязательство, по крайней мере, на базовом уровне (вам не нужно, чтобы все они были определены - помните, что это не должно выглядеть как контракт) .
Цель BDD - стимулировать разработку программного обеспечения с точки зрения поведения, что должно дать вам довольно четкий «способ» того, как и когда писать критерии приемлемости. Я нашел их очень полезными в сочетании с контрольным списком INVEST для пользовательских историй и определением «Готово для вас».
HTH ANdreaT
Если под BDD вы имеете в виду «разработку, управляемую поведением», то, возможно, вы сбиты с толку, добавив туда слово «тесты».
Это не тесты, хотя вы получите из них бесплатные тесты. Если вы думаете о них как о тестах, вы будете использовать их плохо.
Это спецификации. Если вы подойдете к ним таким образом, вы увидите, как они вписываются в ваш процесс.
Это зависит от вас, но вы получите наибольшую пользу, если заставите себя не думать о них как о тестах и вместо этого будете последовательно относиться к ним как к спецификациям. Ничто не может помешать вам использовать их не по назначению (в качестве тестов), но неправильное их использование гарантирует, что вы не получите выгоды от этого подхода - и это существенно.