Development-process » History » Version 14
Viktoria Kopach, 03/03/2011 01:10 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 | Виды тестов в проекте: |
||
| 24 | 12 | Viktoria Kopach | # Unit-internal. Когда прогоняются: на усмотрение разработчика. Когда дописываются: на усмотрение разработчика. |
| 25 | # Unit-approved. Когда прогоняются: во время release-version и после сборки hudson. Когда дописываются: ... |
||
| 26 | # Автоматические - основные use-case''ы. Когда прогоняются: после release, но до publish, и после сборки hudson. Когда дописываются: ... |
||
| 27 | # Ручные - основные use-case''ы (которые пока не автоматизированы). Когда прогоняются: после release, но до publish, и после сборки hudson. Когда дописываются: ... |
||
| 28 | 14 | Viktoria Kopach | # Ad-hoc тесты, проверяют реализации user-story (task надо?). Когда прогоняются: после resolved. Не записываются. |
| 29 | 1 | Alexey Demakov | *Status Open* -> development -> *Status Resolved* -> ad-hoc testing -> *Status Verified* -> demo -> *Status Closed* |
| 30 | 14 | Viktoria Kopach | |
| 31 | Этапы тестирования в течение итерации: |
||
| 32 | # Анализ user-story и доработка требований (с расчетом на дальнейшее превращение в документацию). |
||
| 33 | # Доработка ручных системных тестов. |
||
| 34 | # Доработка автоматических системных тестов. |
||
| 35 | *Status Release* -> выполняются автоматические и ручные системные тесты. |
||
| 36 | *Status Resolved* -> выполняется ad-hoc тестирование тикетов. |