часть 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

Проблема: Как можно быть уверенным что разрабатываемый код работает правильно, при этом создавая регрессионные тесты для последующего рефакторинга кода?

Решение: Пишите тесты до создания кода. Они будут способствовать созданию правильного дизайна и мотивировать в процессе кодирования.

Контекст:

• Участники: Эту технику применяют программисты или автоматизаторы, которые разрабатывают код.
• Продукт: Обычно используется для тестирования интерфейсов, которые вызываются внутри разрабатываемого кода.
• Цели: Протестировать код до того, как он будет поставлен в использование. А также, предоставить автоматизированные тесты для разработанного кода.

Стратегия тестирования:

• Создание тестов: Тесты пишутся на том же языке/в том же окружении, на котором пишется продукт (для большей переиспользуемости).
• Выполнение тестов: Тесты выполняются в среде для модульного тестирования.
• Оценка результатов тестов: Ожидаемые результаты определены заблаговременно.

Атрибуты качества:

• Сопровождение и поддержка: Средняя. Тесты сопровождаются одновременно с основным кодом. Существование модульных тестов помогает проводить рефакторинг и другие изменения в коде.
• Проверка: Средняя. Тесты могут быть проанализированы другими программистами. 
• Целостность и зависимость: Средняя. Данная техника побуждает сначала разработать тесты, запустить, проверить ошибки, и только потом создавать код, который сможет пройти эти тесты. Это предупреждает возникновение серъезных проблем, которые могли случайно оказаться в коде.
• Возможность повторного использования: Низкая.

Следующий шаг:
Ограниченное использование графического интерфейса может быть использован для тестирования графического интерфейса пользователя.

Кто был на SQA Days, могут рассказать, что приходишь на конференцию, как в супермаркет. Всего много и везде, только ты один, а разорваться не можешь. Промышленные конференции - хорошая штука. Вот скоро будет очередная конференция Belgium Testing Days заграницой. По автоматизации будут рассмотрены следующие темы:

• Julian Harty: “Test Automation for Mobile Applications”
• Hans Schaefer: “A Minimal Test Method for Unit Testing”
• Jeroen Boydens, Piet Cordemans & Sillie Van Landschoot: “Test-Driven Development in the Embedded World”
• Bjorn Boisschot: “The A(utomation)-Team”
• Anderson dos Santos & Bruno de Paula Kinoshita: “How to Automate Tests Using TestLink and Hudson”
• Gojko Adzic: “Winning Big with Agile Acceptance Testing – Lessons Learned From 50 Successful Projects”