t.me/atinfo_chat Telegram группа по автоматизации тестирования

Автоматизация приемочного тестирования с помощью Robot Framework: Процесс A-TDD


(Mykhailo Poliarush) #1

авторы 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 показана схема

Схема A-TDD

Рис. 1.1 схема A-TDD

Процесс A-TDD

Процесс A-TDD состоит из трех шагов:

  1. Обсуждение требований на встрече .
  2. Их параллельная разработка во время итерации .
  3. Подать результат для приемки заинтересованным лицам.

Обсуждение — требования определяются в ходе обсуждения на встречах для определения требований . Участниками такой встречи является кросс-функциональная команда, собственник продукта или его представитель и любые другие заинтересованные лица, которые потенциально имеют информацию относительно требований. Обычным вопросом, который задают на таких встречах, является следующий “Представьте себе эту систему законченной. Как бы вы использовали ее и что бы вы от нее ожидали?” В ответах на такой вопрос, появляются примеры использования, и такие примеры можно записать как тесты – требования.

В ходе такой встречи необходимо сфокусироваться больше на требованиях, чем на самих тестах. 

Разработка — в конце такой встречи примеры выделяются в тесты . Все действия, необходимые для внедрения требований, выполняются параллельно. Этот шаг включает следующее: 

  • создание связующего кода между тестами и тестируемой системой (“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.

A-TDD процесс

Более подробный Рис. 1.2

Шаги A-TDD отлично накладываются на цикл Scrum итераций (Рис. 1.3).

 

 Шаги A-TDD

Рис. 1.3 шаги A-TDD наложенные на итерацию Scrum

Обсуждение на встрече — до подробного планирования спринта , команда, собственник продукта и другие заинтересованные лица совместно определяют требования на встрече

Параллельная разработка — задачи для внедрения тестов /требований создаются в подробном плане спринта и выполняются в ходе итерации. Все активности “приблизительно происходят в одно время”

Предоставление для приемки — рост работающего продукта—прохождение тестов приемки —предоставляются заинтересованным лицам и обсуждаются вместе в ревью спринта.

 

Продолжение следует...