Project

General

Profile

Development-process » History » Version 27

Андрей Третьяков, 01/20/2012 06:19 PM
grammar fixes

1 1 Alexey Demakov
h1. Процесс разработки
2
3 21 Alexey Khoroshilov
* Используем SCRUM-подбный процесс. Инструментальная поддержка: redmine+"выборка задач backlog":http://forge.ispras.ru/projects/reqdb/issues?query_id=23.
4 1 Alexey Demakov
* 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 21 Alexey Khoroshilov
* Product Owner расставляет приоритеты User Story, переупорядочивая backlog при помощи приоритетов задач.
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 27 Андрей Третьяков
* Задачи реализуются и проверяются. Виды проверки могут быть разные. По возможности, это автоматические тесты, которые прогоняются при каждой сборке. Если тест создан, информация о нем должна появиться в задаче. Также используются code review: закладка Repository -> click on revision -> click on changed file -> click on line.
12 1 Alexey Demakov
* Ежедневные SCRUM-митинги в 14:00.
13
* В конце итерации демонстрируется реализованная функциональность.
14
* В конце итерации проводится ретроспектива.
15 21 Alexey Khoroshilov
16
|_. Этап       |_. Статус в начале |_. Статус в процессе |_. Исполнители |_. Результат |_. Статус в конце |
17
| Прием заявки |                   |                     | User          | Более или менее подробное описание новой функциональности в задаче типа Feature | Feature:New |
18
| Оценка       | Feature:New       | Feature:Open, assigned | Product Owner | Одобрение запроса, возможно с его обощением, детализацией или переформулировкой в задаче типа UserStory или отказ, желательно мотивированный | UserStory:New или Feature:Rejected |
19
| Определение требований | UserStory:New | UserStory:Open, assigned | Analyst + Product Owner | Детально сформулированные требования к новой функциональности на Wiki. Проект GUI и т.п. | UserStory:Open |
20
| Верификация требований | UserStory:Open | UserStory:Open, assigned | Tester | Обратная связь от тестера о наборе требований. | UserStory:Open |
21 23 Alexey Khoroshilov
| *Запуск в работу* | UserStory:Open | UserStory:Open | Analyst -> Team | Демонстрация проекта функциональности. Обратная связь от команды. Оценка затрат на реализацию + разбиение на подзадачи для точности оценки. | UserStory:Open, store points |
22 24 Alexey Khoroshilov
|||||||
23 21 Alexey Khoroshilov
| Реализация | Task(D):New | Task(D):Open, assigned | Developer | Разбиение на подзадачи и реализация. Юнит-тесты и код в svn. Юнит-тесты проходят. | Task(D):Resolved, time spent. UserStory:Resolved |
24
| Разработка тестов | Task(T):New | Task(T):Open, assigned | Tester | Разработка тестов. Тесты (код, описание и т.п.) в svn | Task(T):Open, time spent |
25
| Внутренний релиз | UserStory:Resolved | UserStory:Resolved | Release Manager | Внутренний релиз, опубликованный на daily update site | UserStory:Resolved, Published in Build |
26
| Прогон тестов | UserStory:Resolved, Published in Build, Task(T):Open | UserStory:Resolved, Published in Build, Task(T):Open | Tester | Прогон тестов | UserStory:Verified, Task(T):Closed, time spent |
27 23 Alexey Khoroshilov
| *Внешний релиз* | UserStory:Verified | UserStory:Verified | Analyst+Team -> ProductOwner | Демонстрация новой функциональности. Внешний релиз, опубликован на stable update site | UserStory:Closed, Task(D):Closed |
28 21 Alexey Khoroshilov
29 4 Yuriy Shekochihin
30 5 Viktoria Kopach
h1. Концепция тестирования
31
32
* Основное направление - поиск новых ошибок. 
33
При появлении идеи новой фичи описываются требования к ней. 
34
Когда фича реализована, осуществляется ее тестирование вручную с целью нахождения ошибок. Делаются тесты на соответствие требованиям и на проверку потенциально-критических ситуаций.
35 25 Viktoria Kopach
* Вторичное направление - автоматизация [[regr_tests|регрессионного тестирования]].
36 11 Viktoria Kopach
37 17 Alexey Khoroshilov
h2. Виды сборок системы
38 1 Alexey Demakov
39 17 Alexey Khoroshilov
# *Automatic Build* 
40 27 Андрей Третьяков
Собирается Hudson автоматически с целью бысторого выявления коммитов, ломающих сборку и нарушающих approved unit-тесты.
41 17 Alexey Khoroshilov
# *Development Build*
42
Собирается для целей тестирования текущего среза системы в рамках итерации.
43
Публикуется на update site: http://forge.ispras.ru/repo/requality/site_daily/
44
Статус: devel.
45
# *Internal Release*
46
Собирается для целей демонстрации результатов очередной итерации. Включает реализацию завершенных user story.
47 27 Андрей Третьяков
Собирается как Development Build и получает статус Internal Release только после успешного прохождения всех ручных и автоматических системных тестов. Если автоматические тесты не проходят из-за изменений в интерфейсе, прогон проблемных тестов заменяется эквивалентным ручным тестированием. Также подразумевается выполнение ad-hoc тестирования всех завершенных user-story.
48 17 Alexey Khoroshilov
Публикуется в файлах.
49
Статус: alpha.
50
# *Public Release*
51 27 Андрей Третьяков
Собирается как Development Build и получает статус Public Release только после успешного прохождения всех ручных и автоматических системных и advanced тестов. Если автоматические тесты не проходят из-за изменений в интерфейсе, прогон проблемных тестов заменяется эквивалентным ручным тестированием.
52 17 Alexey Khoroshilov
Публикуется в файлах на update site: http://forge.ispras.ru/repo/requality/site/
53
Статус: beta или stable.
54
55
h2. Виды тестов в проекте
56
57
# *Internal Unit-тесты* 
58
+Описание+: Unit-тесты на отдельные компоненты, которые пока не готовы быть отчужденными от разработчика.
59
+Когда прогоняются+: на усмотрение разработчика.
60
+Когда дописываются+: на усмотрение разработчика.
61
# *Approved Unit-тесты*
62
+Описание+: Отлаженные Unit-тесты на отдельные компоненты, которые позволяют развивать компонент, автоматически проверяя неизменность и его ключевых интерфейсов и работоспособность его основной функциональности.
63
+Когда прогоняются+: во время сборки Hudson и любой другой версии системы.
64
+Когда дописываются+: на усмотрение разработчика.
65
# *Автоматические системные тесты*
66
+Описание+: Проверяют основные варианты использования системы автоматизированным образом.
67
+Когда прогоняются+: для перевода Development Build в статус Internal или Public Release. Во время сборки Hudson (???).
68
+Когда дописываются+: ...
69
# *Ручные системные тесты*
70
+Описание+: Проверяют основные варианты использования системы, которые пока не удалось автоматизтировать.
71
+Когда прогоняются+: для перевода Development Build в статус Internal или Public Release.
72
+Когда дописываются+: ...
73
# *Ad-hoc тесты*
74
+Описание+: проверяют реализации task''ов и user-story, основываясь на фантазии тестировщика с целью выявления особенностей разработанного кода во всевозможных условиях.
75 18 Alexey Khoroshilov
+Когда прогоняются+: после переведения task''а или user-story в статус resolved и выпуска соответствующего Development Build.
76 17 Alexey Khoroshilov
+Когда дописываются+: Не записываются вовсе. В случае выявления неполноты системных тестов записываются, переходя в состав соответствующего тестового набора.
77
# *Автоматические и ручные advanced тесты*
78
+Описание+: Проверяют нестандартные и граничные варианты использования системы автоматизированным и ручным образом.
79
+Когда прогоняются+: для перевода Development Build в статус Public Release.
80
+Когда дописываются+: ...
81
82
h2. Этапы тестирования в течение итерации
83
84 1 Alexey Demakov
# Анализ user-story и доработка требований (с расчетом на дальнейшее превращение в документацию).
85 14 Viktoria Kopach
# Доработка ручных системных тестов.
86 16 Viktoria Kopach
# Доработка автоматических системных тестов.
87 17 Alexey Khoroshilov
88
+Workflow для task''а/user-story+:
89
*Status Open* -> development -> *Status Resolved* -> ad-hoc testing -> *Status Verified* -> demo -> *Status Closed*
90 26 Vladimir Fedotov
91
h2. Правила оформления дефектов
92
93
# Название дефекта должно максимально емко описывать его суть
94
** Правильно: при создании ботинка появляется сообщение об ошибке "неверная нога: -1"
95
** Неправильно: при создании ботинка появляется ошибка
96
** Совсем неправильно: невозможно создать ботинок!!!
97
# В атрибутах дефекта должна быть указана сборка, на которой он обнаружен, либо номер ревизии в svn
98
# В атрибутах дефекта должна быть указана ОС, на которой он обнаружен (Linux/Windows, 32/64)
99
# Описание дефекта должно содержать максимально полное описание предусловий для его повторения
100
** Правильно: ботинок создан для как минимум одной ноги; ботинок имеет как минимум один шнурок;
101
** Неправильно: ботинок создан;
102
** Совсем неправильно: существует шнурок;
103
# Описание дефекта должно содержать достаточно подробное и непротиворечивое описание шагов для его повторения
104
** Правильно: 1. Создать ботинок; 2. Создать шнурки; 3. Завязать шнурки; 4. Развязать шнурки; 5. Снять ботинок
105
** Неправильно: 1. Завязать шнурки; 2. Развязать шнурки; 3. Снять ботинок
106
** Совсем неправильно: 1. Создать ботинок; 2. Развязать шнурки; 3. Снять ботинок
107
# Описание дефекта должно содержать результат выполнения шагов
108
# Описание дефекта должно содержать ожидаемый результат выполнения шагов
109
** Правильно: ботинок снимается с той же ноги, на которой был создан
110
** Неправильно: ботинок снимается
111
** Совсем неправильно: корректное поведение
112
# Если дефект описывает нарушение требования, он должен содержать ссылку на это требование
113
# Если дефект может быть повторен только на специфических данных, эти данные должны быть приложены к дефекту
114
# Если дефект не повторяется или повторяется не каждый раз, это должно быть указано в его описании
115
# Описание шагов для повторения может быть заменено на скринкаст, при этом остальные пункты должны соблюдаться
116
# Описание результата выполнения шагов может быть заменено на скриншот, при этом остальные пункты должны соблюдаться