Project

General

Profile

Development-process » History » Revision 21

Revision 20 (Alexey Khoroshilov, 03/21/2011 01:46 PM) → Revision 21/27 (Alexey Khoroshilov, 04/07/2011 01:36 PM)

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

 * Используем SCRUM-подбный процесс. Инструментальная поддержка: redmine+"выборка задач backlog":http://forge.ispras.ru/projects/reqdb/issues?query_id=23. 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 при помощи приоритетов задач. 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. 
 * В конце итерации демонстрируется реализованная функциональность. 
 * В конце итерации проводится ретроспектива. 

 |_. Этап         |_. Статус в начале |_. Статус в процессе |_. Исполнители |_. Результат |_. Статус в конце | 
 | Прием заявки |                     |                       | User            | Более или менее подробное описание новой функциональности в задаче типа Feature | Feature:New | 
 | Оценка         | Feature:New         | Feature:Open, assigned | Product Owner | Одобрение запроса, возможно с его обощением, детализацией или переформулировкой в задаче типа UserStory или отказ, желательно мотивированный | UserStory:New или Feature:Rejected | 
 | Определение требований | UserStory:New | UserStory:Open, assigned | Analyst + Product Owner | Детально сформулированные требования к новой функциональности на Wiki. Проект GUI и т.п. | UserStory:Open | 
 | Верификация требований | UserStory:Open | UserStory:Open, assigned | Tester | Обратная связь от тестера о наборе требований. | UserStory:Open | 
 | Запуск в работу | UserStory:Open | UserStory:Open | Analyst -> Team | Демонстрация проекта функциональности. Обратная связь от команды. Оценка затрат на реализацию + разбиение на подзадачи для точности оценки. | UserStory:Open, store points | 
 | Реализация | Task(D):New | Task(D):Open, assigned | Developer | Разбиение на подзадачи и реализация. Юнит-тесты и код в svn. Юнит-тесты проходят. | Task(D):Resolved, time spent. UserStory:Resolved | 
 | Разработка тестов | Task(T):New | Task(T):Open, assigned | Tester | Разработка тестов. Тесты (код, описание и т.п.) в svn | Task(T):Open, time spent | 
 | Внутренний релиз | UserStory:Resolved | UserStory:Resolved | Release Manager | Внутренний релиз, опубликованный на daily update site | UserStory:Resolved, Published in Build | 
 | Прогон тестов | UserStory:Resolved, Published in Build, Task(T):Open | UserStory:Resolved, Published in Build, Task(T):Open | Tester | Прогон тестов | UserStory:Verified, Task(T):Closed, time spent | 
 | Внешний релиз | UserStory:Verified | UserStory:Verified | Analyst+Team -> ProductOwner | Демонстрация новой функциональности. Внешний релиз, опубликован на stable update site | UserStory:Closed, Task(D):Closed | 


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

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

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

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

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

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

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

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

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