Development-process » History » Revision 13
Revision 12 (Viktoria Kopach, 03/02/2011 02:01 PM) → Revision 13/27 (Viktoria Kopach, 03/03/2011 12:50 PM)
h1. Процесс разработки
* Используем SCRUM-подбный процесс. Инструментальная поддержка: redmine+backlogs plugin (закладка Backlogs).
* Product Owner: "Алексей Хорошилов":http://forge.ispras.ru/users/7.
* В трекере "User Story":http://forge.ispras.ru/projects/reqdb/issues?set_filter=1&tracker_id=5 накапливаются пользовательские истории + запросы разработчиков по архитектуре и другим необходимым изменениям, которые напрямую пользователям не видны.
* В трекере "Bug":http://forge.ispras.ru/projects/reqdb/issues?set_filter=1&tracker_id=1 накапливаются найденные ошибки, из которых также получаются User Stories.
* Product Owner расставляет приоритеты User Story, переупорядочивая backlog-списки на закладке Backlogs.
* User Story оцениваются в Story Points.
* В соответствии с трудоемкостью User Story выбираются на итерацию.
* Выбранные User Story разбиваются на задачи, которые живут в трекере "Task":http://forge.ispras.ru/projects/reqdb/issues?set_filter=1&tracker_id=2
* Задачи реализуются и проверяются. Виды проверки могут быть разные. По возможности, это автоматические тесты, которые прогоняются при каждой сборке. Если тест создан * информация о нем должна появиться в задаче. Также используются code review: закладка Repository -> click on revision -> click on changed file -> click on line.
* Ежедневные SCRUM-митинги в 14:00.
* В конце итерации демонстрируется реализованная функциональность.
* В конце итерации проводится ретроспектива.
h1. Концепция тестирования
* Основное направление - поиск новых ошибок.
При появлении идеи новой фичи описываются требования к ней.
Когда фича реализована, осуществляется ее тестирование вручную с целью нахождения ошибок. Делаются тесты на соответствие требованиям и на проверку потенциально-критических ситуаций.
* Вторичное направление - автоматизация регрессионного тестирования.
Виды тестов в проекте:
# Unit-internal. Когда прогоняются: на усмотрение разработчика. Когда дописываются: на усмотрение разработчика.
# Unit-approved. Когда прогоняются: во время release-version и после сборки hudson. Когда дописываются: ...
# Автоматические - основные use-case''ы. Когда прогоняются: после release, но до publish, и после сборки hudson. Когда дописываются: ...
# Ручные - основные use-case''ы (которые пока не автоматизированы). Когда прогоняются: после release, но до publish, и после сборки hudson. Когда дописываются: ...
# Ad-hoc тесты, проверяют внесенные изменения. Когда прогоняются: после resolved. Не записываются.
*Status Open* -> development -> *Status Resolved* -> ad-hoc testing -> *Status Verified* -> demo -> *Status Closed*