Development-process » History » Version 17
Alexey Khoroshilov, 03/21/2011 12:04 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 | Собирается как Development Build и получает статус Internal Release только после успешного прохождения всех ручных и автоматических системных и advanced тестов. Если автоматические тесты не проходят из-за измений в интерфейсе, прогон проблемных тестов заменяется эквивалентным ручным тестированием.Собирается как Development Build и получает статус Internal Release только после успешного прохождения всех ручных и автоматических системных тестов. Если автоматические тесты не проходят из-за измений в интерфейсе, прогон проблемных тестов заменяется эквивалентным ручных тестированием. |
||
38 | Публикуется в файлах на 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 | +Когда прогоняются+: после resolved. |
||
62 | +Когда дописываются+: Не записываются вовсе. В случае выявления неполноты системных тестов записываются, переходя в состав соответствующего тестового набора. |
||
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 тестирование тикетов. |