Project

General

Profile

Actions

Development-process » History » Revision 19

« Previous | Revision 19/27 (diff) | Next »
Alexey Khoroshilov, 03/21/2011 01:45 PM


Процесс разработки

  • Используем SCRUM-подбный процесс. Инструментальная поддержка: redmine+backlogs plugin (закладка Backlogs).
  • Product Owner: Алексей Хорошилов.
  • В трекере User Story накапливаются пользовательские истории + запросы разработчиков по архитектуре и другим необходимым изменениям, которые напрямую пользователям не видны.
  • В трекере Bug накапливаются найденные ошибки, из которых также получаются User Stories.
  • Product Owner расставляет приоритеты User Story, переупорядочивая backlog-списки на закладке Backlogs.
  • User Story оцениваются в Story Points.
  • В соответствии с трудоемкостью User Story выбираются на итерацию.
  • Выбранные User Story разбиваются на задачи, которые живут в трекере Task
  • Задачи реализуются и проверяются. Виды проверки могут быть разные. По возможности, это автоматические тесты, которые прогоняются при каждой сборке. Если тест создан * информация о нем должна появиться в задаче. Также используются code review: закладка Repository -> click on revision -> click on changed file -> click on line.
  • Ежедневные SCRUM-митинги в 14:00.
  • В конце итерации демонстрируется реализованная функциональность.
  • В конце итерации проводится ретроспектива.

Концепция тестирования

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

Виды сборок системы

  1. Automatic Build
    Собирается Hudson автоматически с целью бысторого выявления коммитов, ломающих сборку, и нарушающих approved unit-тесты.
  2. Development Build
    Собирается для целей тестирования текущего среза системы в рамках итерации.
    Публикуется на update site: http://forge.ispras.ru/repo/requality/site_daily/
    Статус: devel.
  3. Internal Release
    Собирается для целей демонстрации результатов очередной итерации. Включает реализацию завершенных user story.
    Собирается как Development Build и получает статус Internal Release только после успешного прохождения всех ручных и автоматических системных тестов. Если автоматические тесты не проходят из-за измений в интерфейсе, прогон проблемных тестов заменяется эквивалентным ручным тестированием. Также подразумевается выполнение ad-hoc тестирования всех завершенных user-story.
    Публикуется в файлах.
    Статус: alpha.
  4. Public Release
    Собирается как Development Build и получает статус Public Release только после успешного прохождения всех ручных и автоматических системных и advanced тестов. Если автоматические тесты не проходят из-за измений в интерфейсе, прогон проблемных тестов заменяется эквивалентным ручным тестированием.
    Публикуется в файлах на update site: http://forge.ispras.ru/repo/requality/site/
    Статус: beta или stable.

Виды тестов в проекте

  1. Internal Unit-тесты
    Описание: Unit-тесты на отдельные компоненты, которые пока не готовы быть отчужденными от разработчика.
    Когда прогоняются: на усмотрение разработчика.
    Когда дописываются: на усмотрение разработчика.
  2. Approved Unit-тесты
    Описание: Отлаженные Unit-тесты на отдельные компоненты, которые позволяют развивать компонент, автоматически проверяя неизменность и его ключевых интерфейсов и работоспособность его основной функциональности.
    Когда прогоняются: во время сборки Hudson и любой другой версии системы.
    Когда дописываются: на усмотрение разработчика.
  3. Автоматические системные тесты
    Описание: Проверяют основные варианты использования системы автоматизированным образом.
    Когда прогоняются: для перевода Development Build в статус Internal или Public Release. Во время сборки Hudson (???).
    Когда дописываются: ...
  4. Ручные системные тесты
    Описание: Проверяют основные варианты использования системы, которые пока не удалось автоматизтировать.
    Когда прогоняются: для перевода Development Build в статус Internal или Public Release.
    Когда дописываются: ...
  5. Ad-hoc тесты
    Описание: проверяют реализации task''ов и user-story, основываясь на фантазии тестировщика с целью выявления особенностей разработанного кода во всевозможных условиях.
    Когда прогоняются: после переведения task''а или user-story в статус resolved и выпуска соответствующего Development Build.
    Когда дописываются: Не записываются вовсе. В случае выявления неполноты системных тестов записываются, переходя в состав соответствующего тестового набора.
  6. Автоматические и ручные advanced тесты
    Описание: Проверяют нестандартные и граничные варианты использования системы автоматизированным и ручным образом.
    Когда прогоняются: для перевода Development Build в статус Public Release.
    Когда дописываются: ...

Этапы тестирования в течение итерации

  1. Анализ user-story и доработка требований (с расчетом на дальнейшее превращение в документацию).
  2. Доработка ручных системных тестов.
  3. Доработка автоматических системных тестов.

Workflow для task''а/user-story:
Status Open -> development -> Status Resolved -> ad-hoc testing -> Status Verified -> demo -> Status Closed

Status Release -> выполняются автоматические и ручные системные тесты.
Status Resolved -> выполняется ad-hoc тестирование тикетов.

Updated by Alexey Khoroshilov almost 14 years ago · 27 revisions