testomat.io управление авто тестамиавторы Craig Larman и Bas Vodde
Автоматизация приемочного тестирования и разработки через приемочные тесты – один из важных методов, используемый успешными командами, работающими с Agile и Scrum. Он меняет цель тестирования, используя примеры / тесты для определения и документирования требований. Эта короткая статья – выдержка из главы о тестировании из книги Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum.
Вступление в автоматизацию приемочного тестирования и разработки через приемочные тесты
Автоматизация приемочного тестирования и разработки (A-TDD) (Автоматизация для приемочного тестирования и разработки также известна как agile приемочное тестирование (agile acceptance testing) или story test- driven development.) - подход совместного определения требований, где примеры и автоматические тесты используются для определения требований – создавая исполняемые спецификации. Они задаются командой, собственником продукта (Product Owner) и другими заинтересованными сторонами, принимающими участие в создании таких требований.
Тесты как требования, требования как тесты — по словам Мельника и Мартина, “С увеличением формализованности, тесты и требования становятся неразделимыми. У предела, тесты и требования являются эквивалентами”. Тесты должны быть точными для того, чтобы их можно было автоматизировать.
A-TDD использует эту формализованность и формулирует требования с помощью написания автоматических тестов.
Встречи для прояснения требований — определение требований лицом-к-лицу на таких встречах используется с момента изобретения Joint Application Design (JAD). Для ATDD также нужны личные встречи с Product Owner, где такие встречи используются для формулировки требований-как-тестов.
Параллельная разработка — наиболее часто используемая продолжительность итераций – две недели. Это очень быстро и именно поэтому команде необходимо найти способ работать параллельно – последовательная работа не работает при коротких итерациях. Мы видели как команды придумывали A-TDD снова и снова, просто потому, что им необходимо было ответить на вопрос : “Как нам выполнять нашу работу одновременно?”
Предотвращение, но не определение — когда люди, в том числе специализирующиеся в тестировании, принимают участие во встречах по определению требований, они могут задавать вопросы по тестированию story или использовать традиционные стратегии тест-дизайна, которые будут применены к story, например анализ граничных значений. Таким образом, они могут усовершенствовать требования и предотвратить дефекты.
Так как же работает A-TDD ? на рис. 1.1 показана схема
Рис. 1.1 схема A-TDD
Процесс A-TDD
Процесс A-TDD состоит из трех шагов:
- Обсуждение требований на встрече .
- Их параллельная разработка во время итерации .
- Подать результат для приемки заинтересованным лицам.
Обсуждение — требования определяются в ходе обсуждения на встречах для определения требований . Участниками такой встречи является кросс-функциональная команда, собственник продукта или его представитель и любые другие заинтересованные лица, которые потенциально имеют информацию относительно требований. Обычным вопросом, который задают на таких встречах, является следующий “Представьте себе эту систему законченной. Как бы вы использовали ее и что бы вы от нее ожидали?” В ответах на такой вопрос, появляются примеры использования, и такие примеры можно записать как тесты – требования.
В ходе такой встречи необходимо сфокусироваться больше на требованиях, чем на самих тестах.
Разработка — в конце такой встречи примеры выделяются в тесты . Все действия, необходимые для внедрения требований, выполняются параллельно. Этот шаг включает следующее:
- создание связующего кода между тестами и тестируемой системой (“test libraries” и “lower-level tables” в Robot Framework или ‘fixtures’ в Fit)
- реализация требований для того чтобы тесты проходили
- обновление архитектурной и другой внутренней документации в соответствии с рабочим соглашением группы
- написание клиентской документации для требования
- дополнительное исследовательское тестирование
Точный перечень зависит от продукта, контекста, рабочих соглашений и Definition of Done (Определение выполненного (“Definition of Done”) – термин Scrum, для определения соглашения между собственником продукта и командой относительно того, что включено в итерацию. Короткое вступление в Scrum — the Scrum Primer — можно прочитать на http://www.scrumprimer.org).
Поставка — когда тесты проходят, требования пересматриваются собственником продукта и другими заинтересованными лицами. Это может привести к выдвижению новых требований или изменению уже производимых тестов.
Более подробное описание A-TDD указано на Рис. 1.2.
Более подробный Рис. 1.2
Шаги A-TDD отлично накладываются на цикл Scrum итераций (Рис. 1.3).
Рис. 1.3 шаги A-TDD наложенные на итерацию Scrum
Обсуждение на встрече — до подробного планирования спринта , команда, собственник продукта и другие заинтересованные лица совместно определяют требования на встрече
Параллельная разработка — задачи для внедрения тестов /требований создаются в подробном плане спринта и выполняются в ходе итерации. Все активности “приблизительно происходят в одно время”
Предоставление для приемки — рост работающего продукта—прохождение тестов приемки —предоставляются заинтересованным лицам и обсуждаются вместе в ревью спринта.
Продолжение следует...