часть 1 | часть 2

Пример два: импорт файлов AutoCAD

Отдел экспозиции использует AutoCAD для создания плана конференций. Это включает в себя расположение стендов и всего остального,связанного с конференциями, включая непонятные символы и электрические розетки. Но, в любом случае, эти чертежи предназначались для того, чтобы их читали люди.

Требованием для этой информационной системы была демонстрация карты. Посетители могут выбрать расположение на карте, а система покажет им продавца. Для конференц-центра было необходимо импортировать в систему файлы DWG из AutoCAD, созданные отделом экспозиции. Чтение файлов AutoCAD довольно медленно, поэтому файлы конвертируются во внутренний формат, сохраняющий только необходимую информацию, удаляя ненужную, например электрические розетки.

Файлы DWG содержат линии, создающие формы. Форма с написанным номером скорее всего является стендом. Системе необходимо прочитать файл, создать форму, распознать стенд, отделить ненужную информацию. Это не слишком сложно … за исключением того, что данные непоследовательны — созданные не для компьютеров. Формы не всегда точно закрыты, номер не всегда точно на стенде, и так далее.

На встрече по определению требований мы обсуждали различные возможные исключения, которые система должна поддерживать. Мы начали с абстрактного описания и перешли далее к примерам, как показано в Рис. 1.8.

часть 1

Пример: ROBOT FRAMEWORK

В этом разделе представлен короткий пример Robot Framework, который использует систему, над которой мы работали много лет назад. При самой разработке не использовались A-TDD или Robot Framework, то есть пример – новый, система – старая. Это система среднего размера (большие продукты с более сложных или незнакомых доменов сложно использовать в качетсве примера на нескольких страницах.), но, все же, этот пример демонстрирует принципиальные моменты, которые будут актуальными и для среды большего размера.

Robot Framework –фреймворк для автоматизации, использующий keyword-driven подход, созданный Pekka Kl?rck (Ранее Pekka Laukkanen)  в Nokia Siemens Networks в 2005. Одной из его ранних целей была поддержка A-TDD. Он стал бесплатным в 2008 г. и доступен на www.robotframework.org.

Продукт, используемый в нашем случае – информационная система для конференций, разработанная для конференц-центра. Доступ к системе можно получить через «информационные стойки», расположенные по всему конференц-центру.

авторы 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