Development-process » History » Revision 18
Revision 17 (Alexey Khoroshilov, 03/21/2011 12:04 PM) → Revision 18/27 (Alexey Khoroshilov, 03/21/2011 12:05 PM)
h1. Процесс разработки * Используем SCRUM-подбный процесс. Инструментальная поддержка: redmine+backlogs plugin (закладка Backlogs). * Product Owner: "Алексей Хорошилов":http://forge.ispras.ru/users/7. * В трекере "User Story":http://forge.ispras.ru/projects/reqdb/issues?set_filter=1&tracker_id=5 накапливаются пользовательские истории + запросы разработчиков по архитектуре и другим необходимым изменениям, которые напрямую пользователям не видны. * В трекере "Bug":http://forge.ispras.ru/projects/reqdb/issues?set_filter=1&tracker_id=1 накапливаются найденные ошибки, из которых также получаются User Stories. * Product Owner расставляет приоритеты User Story, переупорядочивая backlog-списки на закладке Backlogs. * User Story оцениваются в Story Points. * В соответствии с трудоемкостью User Story выбираются на итерацию. * Выбранные User Story разбиваются на задачи, которые живут в трекере "Task":http://forge.ispras.ru/projects/reqdb/issues?set_filter=1&tracker_id=2 * Задачи реализуются и проверяются. Виды проверки могут быть разные. По возможности, это автоматические тесты, которые прогоняются при каждой сборке. Если тест создан * информация о нем должна появиться в задаче. Также используются code review: закладка Repository -> click on revision -> click on changed file -> click on line. * Ежедневные SCRUM-митинги в 14:00. * В конце итерации демонстрируется реализованная функциональность. * В конце итерации проводится ретроспектива. h1. Концепция тестирования * Основное направление - поиск новых ошибок. При появлении идеи новой фичи описываются требования к ней. Когда фича реализована, осуществляется ее тестирование вручную с целью нахождения ошибок. Делаются тесты на соответствие требованиям и на проверку потенциально-критических ситуаций. * Вторичное направление - автоматизация регрессионного тестирования. h2. Виды сборок системы # *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 и получает статус Internal Release только после успешного прохождения всех ручных и автоматических системных и advanced тестов. Если автоматические тесты не проходят из-за измений в интерфейсе, прогон проблемных тестов заменяется эквивалентным ручным тестированием.Собирается как Development Build и получает статус Internal Release только после успешного прохождения всех ручных и автоматических системных тестов. Если автоматические тесты не проходят из-за измений в интерфейсе, прогон проблемных тестов заменяется эквивалентным ручных тестированием. Публикуется в файлах на update site: http://forge.ispras.ru/repo/requality/site/ Статус: beta или stable. h2. Виды тестов в проекте # *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. resolved. +Когда дописываются+: Не записываются вовсе. В случае выявления неполноты системных тестов записываются, переходя в состав соответствующего тестового набора. # *Автоматические и ручные advanced тесты* +Описание+: Проверяют нестандартные и граничные варианты использования системы автоматизированным и ручным образом. +Когда прогоняются+: для перевода Development Build в статус Public Release. +Когда дописываются+: ... h2. Этапы тестирования в течение итерации # Анализ user-story и доработка требований (с расчетом на дальнейшее превращение в документацию). # Доработка ручных системных тестов. # Доработка автоматических системных тестов. +Workflow для task''а/user-story+: *Status Open* -> development -> *Status Resolved* -> ad-hoc testing -> *Status Verified* -> demo -> *Status Closed* *Status Release* -> выполняются автоматические и ручные системные тесты. *Status Resolved* -> выполняется ad-hoc тестирование тикетов.