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 | # Описание результата выполнения шагов может быть заменено на скриншот, при этом остальные пункты должны соблюдаться |