Project

General

Profile

Development-process » History » Version 19

Alexey Khoroshilov, 03/21/2011 01:45 PM

1 1 Alexey Demakov
h1. Процесс разработки
2
3
* Используем SCRUM-подбный процесс. Инструментальная поддержка: redmine+backlogs plugin (закладка Backlogs).
4
* Product Owner: "Алексей Хорошилов":http://forge.ispras.ru/users/7.
5
* В трекере "User Story":http://forge.ispras.ru/projects/reqdb/issues?set_filter=1&tracker_id=5 накапливаются пользовательские истории + запросы разработчиков по архитектуре и другим необходимым изменениям, которые напрямую пользователям не видны.
6 2 Alexey Demakov
* В трекере "Bug":http://forge.ispras.ru/projects/reqdb/issues?set_filter=1&tracker_id=1 накапливаются найденные ошибки, из которых также получаются User Stories.
7 3 Alexey Demakov
* Product Owner расставляет приоритеты User Story, переупорядочивая backlog-списки на закладке Backlogs.
8 1 Alexey Demakov
* User Story оцениваются в Story Points.
9
* В соответствии с трудоемкостью User Story выбираются на итерацию.
10
* Выбранные User Story разбиваются на задачи, которые живут в трекере "Task":http://forge.ispras.ru/projects/reqdb/issues?set_filter=1&tracker_id=2
11
* Задачи реализуются и проверяются. Виды проверки могут быть разные. По возможности, это автоматические тесты, которые прогоняются при каждой сборке. Если тест создан * информация о нем должна появиться в задаче. Также используются code review: закладка Repository -> click on revision -> click on changed file -> click on line.
12
* Ежедневные SCRUM-митинги в 14:00.
13
* В конце итерации демонстрируется реализованная функциональность.
14
* В конце итерации проводится ретроспектива.
15 4 Yuriy Shekochihin
16 5 Viktoria Kopach
h1. Концепция тестирования
17
18
* Основное направление - поиск новых ошибок. 
19
При появлении идеи новой фичи описываются требования к ней. 
20
Когда фича реализована, осуществляется ее тестирование вручную с целью нахождения ошибок. Делаются тесты на соответствие требованиям и на проверку потенциально-критических ситуаций.
21
* Вторичное направление - автоматизация регрессионного тестирования.
22 11 Viktoria Kopach
23 17 Alexey Khoroshilov
h2. Виды сборок системы
24 1 Alexey Demakov
25 17 Alexey Khoroshilov
# *Automatic Build* 
26
Собирается Hudson автоматически с целью бысторого выявления коммитов, ломающих сборку, и нарушающих approved unit-тесты.
27
# *Development Build*
28
Собирается для целей тестирования текущего среза системы в рамках итерации.
29
Публикуется на update site: http://forge.ispras.ru/repo/requality/site_daily/
30
Статус: devel.
31
# *Internal Release*
32
Собирается для целей демонстрации результатов очередной итерации. Включает реализацию завершенных user story.
33
Собирается как Development Build и получает статус Internal Release только после успешного прохождения всех ручных и автоматических системных тестов. Если автоматические тесты не проходят из-за измений в интерфейсе, прогон проблемных тестов заменяется эквивалентным ручным тестированием. Также подразумевается выполнение ad-hoc тестирования всех завершенных user-story.
34
Публикуется в файлах.
35
Статус: alpha.
36
# *Public Release*
37 19 Alexey Khoroshilov
Собирается как Development Build и получает статус Public Release только после успешного прохождения всех ручных и автоматических системных и advanced тестов. Если автоматические тесты не проходят из-за измений в интерфейсе, прогон проблемных тестов заменяется эквивалентным ручным тестированием.
38 17 Alexey Khoroshilov
Публикуется в файлах на update site: http://forge.ispras.ru/repo/requality/site/
39
Статус: beta или stable.
40
41
h2. Виды тестов в проекте
42
43
# *Internal Unit-тесты* 
44
+Описание+: Unit-тесты на отдельные компоненты, которые пока не готовы быть отчужденными от разработчика.
45
+Когда прогоняются+: на усмотрение разработчика.
46
+Когда дописываются+: на усмотрение разработчика.
47
# *Approved Unit-тесты*
48
+Описание+: Отлаженные Unit-тесты на отдельные компоненты, которые позволяют развивать компонент, автоматически проверяя неизменность и его ключевых интерфейсов и работоспособность его основной функциональности.
49
+Когда прогоняются+: во время сборки Hudson и любой другой версии системы.
50
+Когда дописываются+: на усмотрение разработчика.
51
# *Автоматические системные тесты*
52
+Описание+: Проверяют основные варианты использования системы автоматизированным образом.
53
+Когда прогоняются+: для перевода Development Build в статус Internal или Public Release. Во время сборки Hudson (???).
54
+Когда дописываются+: ...
55
# *Ручные системные тесты*
56
+Описание+: Проверяют основные варианты использования системы, которые пока не удалось автоматизтировать.
57
+Когда прогоняются+: для перевода Development Build в статус Internal или Public Release.
58
+Когда дописываются+: ...
59
# *Ad-hoc тесты*
60
+Описание+: проверяют реализации task''ов и user-story, основываясь на фантазии тестировщика с целью выявления особенностей разработанного кода во всевозможных условиях.
61 18 Alexey Khoroshilov
+Когда прогоняются+: после переведения task''а или user-story в статус resolved и выпуска соответствующего Development Build.
62 17 Alexey Khoroshilov
+Когда дописываются+: Не записываются вовсе. В случае выявления неполноты системных тестов записываются, переходя в состав соответствующего тестового набора.
63
# *Автоматические и ручные advanced тесты*
64
+Описание+: Проверяют нестандартные и граничные варианты использования системы автоматизированным и ручным образом.
65
+Когда прогоняются+: для перевода Development Build в статус Public Release.
66
+Когда дописываются+: ...
67
68
h2. Этапы тестирования в течение итерации
69
70 1 Alexey Demakov
# Анализ user-story и доработка требований (с расчетом на дальнейшее превращение в документацию).
71 14 Viktoria Kopach
# Доработка ручных системных тестов.
72 16 Viktoria Kopach
# Доработка автоматических системных тестов.
73 17 Alexey Khoroshilov
74
+Workflow для task''а/user-story+:
75
*Status Open* -> development -> *Status Resolved* -> ad-hoc testing -> *Status Verified* -> demo -> *Status Closed*
76 15 Viktoria Kopach
77 14 Viktoria Kopach
*Status Release* -> выполняются автоматические и ручные системные тесты.
78
*Status Resolved* -> выполняется ad-hoc тестирование тикетов.