Requality

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. Описания новых функций

h3. Редактор требований

На перспективе Requality есть view  Requirement editor. Если в Requality Explorer кликнуть на требовании 2 раза, его редактор открывается в этом view.

Заголовок редактора — это имя требования.

Редактор содержит вкладки:

параметры: id, имя, атрибуты.

Предикат (возможно стоит его перенести на вкладку параметры? Или он может быть слишком большой?).

базовые требования.

описание (может быть несколько).

альтернативное описание.

json.

Вкладка «описание».

При выборе одного из описаний документ пролистывается так, чтобы это описание оказалось вверху видимой области документа. Сам текст описания в документе размечается выделением. (Если документ был закрыт, то он сначала открывается.)

Вкладка «Базовые требования».

При нажатии на базовое требование (специальная кнопка? Ссылка?) происходит переход к редактору базового требования (если текущий редактор не закреплен кнопкой — см.ниже).

Окно редактора имеет кнопку «Канцелярская кнопка» для закрепления. 

Если эта кнопка не нажата, то при одинарном клике на другое требование в Requality explorer в том же окне редактора открывается это другое требование.

Если кнопка «Канцелярская кнопка» нажата, то при одинарном клике в Requality explorer на другое требование в окне редактора требований остается прежнее требование, новое не открывается.

При двойном клике в Requality explorer на другое требование всегда открывается новое окно редактора требований с этим требованием. Оно становится активно.

Если открыто несколько редакторов требований, то:

При клике на требование оно открывается в том окне редактора требований, которое   активно (выделено) и не закреплено кнопкой. Если ни одно окно редактора не активно или активно, но закреплено кнопкой, то ничего не происходит.

Если два раза кликнуть на требовании, которое уже открыто в одном из редакторов, то этот редактор становится активен и новый редактор не открывается.

Если один раз кликнуть на требовании, которое уже открыто в одном из редакторов (не активном в данный момент), то этот редактор становится активен, а в том редакторе, который был до этого активен, данное требование не открывается.