Actions
Development-process » History » Revision 24
« Previous |
Revision 24/27
(diff)
| Next »
Alexey Khoroshilov, 04/07/2011 01:53 PM
Процесс разработки¶
- Используем SCRUM-подбный процесс. Инструментальная поддержка: redmine+выборка задач backlog.
- Product Owner: Алексей Хорошилов.
- В трекере User Story накапливаются пользовательские истории + запросы разработчиков по архитектуре и другим необходимым изменениям, которые напрямую пользователям не видны.
- В трекере Bug накапливаются найденные ошибки, из которых также получаются User Stories.
- Product Owner расставляет приоритеты User Story, переупорядочивая backlog при помощи приоритетов задач.
- User Story оцениваются в Story Points.
- В соответствии с трудоемкостью User Story выбираются на итерацию.
- Выбранные User Story разбиваются на задачи, которые живут в трекере Task
- Задачи реализуются и проверяются. Виды проверки могут быть разные. По возможности, это автоматические тесты, которые прогоняются при каждой сборке. Если тест создан информация о нем должна появиться в задаче. Также используются 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 |
Концепция тестирования¶
- Основное направление - поиск новых ошибок.
При появлении идеи новой фичи описываются требования к ней.
Когда фича реализована, осуществляется ее тестирование вручную с целью нахождения ошибок. Делаются тесты на соответствие требованиям и на проверку потенциально-критических ситуаций. - Вторичное направление - автоматизация регрессионного тестирования.
Виды сборок системы¶
- 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.
Виды тестов в проекте¶
- 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.
Когда дописываются: ...
Этапы тестирования в течение итерации¶
- Анализ user-story и доработка требований (с расчетом на дальнейшее превращение в документацию).
- Доработка ручных системных тестов.
- Доработка автоматических системных тестов.
Workflow для task''а/user-story:
Status Open -> development -> Status Resolved -> ad-hoc testing -> Status Verified -> demo -> Status Closed
Updated by Alexey Khoroshilov over 13 years ago · 27 revisions