Project

General

Profile

Development-process » History » Revision 12

Revision 11 (Viktoria Kopach, 03/02/2011 01:45 PM) → Revision 12/27 (Viktoria Kopach, 03/02/2011 02:01 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. 1.Unit-internal. Когда прогоняются: разрабатывается: на усмотрение разработчика. Когда дописываются: на усмотрение разработчика. 
 # Unit-approved. 2.Unit-approved. Когда прогоняются: разрабатывается: во время release-version и после release-version, во время сборки hudson. Когда дописываются: ... 
 # Автоматические 3.Автоматические - основные use-case''ы. Когда прогоняются: после release, но до publish, и после сборки hudson. разрабатывается: на усмотрение разработчика. Когда дописываются: ... 
 # Ручные - основные use-case''ы (которые пока не автоматизированы). Когда прогоняются: после release, но до publish, и после сборки hudson. Когда дописываются: ... на усмотрение разработчика.