Процесс разработки¶

• Используем 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.
• В конце итерации демонстрируется реализованная функциональность.
• В конце итерации проводится ретроспектива.

Концепция тестирования¶

• Основное направление - поиск новых ошибок.
  При появлении идеи новой фичи описываются требования к ней.
  Когда фича реализована, осуществляется ее тестирование вручную с целью нахождения ошибок. Делаются тесты на соответствие требованиям и на проверку потенциально-критических ситуаций.
• Вторичное направление - автоматизация регрессионного тестирования.

Виды сборок системы¶

1. Automatic Build
   Собирается Hudson автоматически с целью бысторого выявления коммитов, ломающих сборку, и нарушающих approved unit-тесты.
2. Development Build
   Собирается для целей тестирования текущего среза системы в рамках итерации.
   Публикуется на update site: http://forge.ispras.ru/repo/requality/site_daily/
   Статус: devel.
3. Internal Release
   Собирается для целей демонстрации результатов очередной итерации. Включает реализацию завершенных user story.
   Собирается как Development Build и получает статус Internal Release только после успешного прохождения всех ручных и автоматических системных тестов. Если автоматические тесты не проходят из-за измений в интерфейсе, прогон проблемных тестов заменяется эквивалентным ручным тестированием. Также подразумевается выполнение ad-hoc тестирования всех завершенных user-story.
   Публикуется в файлах.
   Статус: alpha.
4. Public Release
   Собирается как Development Build и получает статус Public Release только после успешного прохождения всех ручных и автоматических системных и advanced тестов. Если автоматические тесты не проходят из-за измений в интерфейсе, прогон проблемных тестов заменяется эквивалентным ручным тестированием.
   Публикуется в файлах на update site: http://forge.ispras.ru/repo/requality/site/
   Статус: beta или stable.

Виды тестов в проекте¶

1. Internal Unit-тесты
   Описание: Unit-тесты на отдельные компоненты, которые пока не готовы быть отчужденными от разработчика.
   Когда прогоняются: на усмотрение разработчика.
   Когда дописываются: на усмотрение разработчика.
2. Approved Unit-тесты
   Описание: Отлаженные Unit-тесты на отдельные компоненты, которые позволяют развивать компонент, автоматически проверяя неизменность и его ключевых интерфейсов и работоспособность его основной функциональности.
   Когда прогоняются: во время сборки Hudson и любой другой версии системы.
   Когда дописываются: на усмотрение разработчика.
3. Автоматические системные тесты
   Описание: Проверяют основные варианты использования системы автоматизированным образом.
   Когда прогоняются: для перевода Development Build в статус Internal или Public Release. Во время сборки Hudson (???).
   Когда дописываются: ...
4. Ручные системные тесты
   Описание: Проверяют основные варианты использования системы, которые пока не удалось автоматизтировать.
   Когда прогоняются: для перевода Development Build в статус Internal или Public Release.
   Когда дописываются: ...
5. Ad-hoc тесты
   Описание: проверяют реализации task''ов и user-story, основываясь на фантазии тестировщика с целью выявления особенностей разработанного кода во всевозможных условиях.
   Когда прогоняются: после переведения task''а или user-story в статус resolved и выпуска соответствующего Development Build.
   Когда дописываются: Не записываются вовсе. В случае выявления неполноты системных тестов записываются, переходя в состав соответствующего тестового набора.
6. Автоматические и ручные advanced тесты
   Описание: Проверяют нестандартные и граничные варианты использования системы автоматизированным и ручным образом.
   Когда прогоняются: для перевода Development Build в статус Public Release.
   Когда дописываются: ...

Этапы тестирования в течение итерации¶

1. Анализ user-story и доработка требований (с расчетом на дальнейшее превращение в документацию).
2. Доработка ручных системных тестов.
3. Доработка автоматических системных тестов.

Workflow для task''а/user-story:
Status Open -> development -> Status Resolved -> ad-hoc testing -> Status Verified -> demo -> Status Closed

Правила оформления дефектов¶

1. Название дефекта должно максимально емко описывать его суть
   • Правильно: при создании ботинка появляется сообщение об ошибке "неверная нога: -1"
   • Неправильно: при создании ботинка появляется ошибка
   • Совсем неправильно: невозможно создать ботинок!!!
2. В атрибутах дефекта должна быть указана сборка, на которой он обнаружен, либо номер ревизии в svn
3. В атрибутах дефекта должна быть указана ОС, на которой он обнаружен (Linux/Windows, 32/64)
4. Описание дефекта должно содержать максимально полное описание предусловий для его повторения
   • Правильно: ботинок создан для как минимум одной ноги; ботинок имеет как минимум один шнурок;
   • Неправильно: ботинок создан;
   • Совсем неправильно: существует шнурок;
5. Описание дефекта должно содержать достаточно подробное и непротиворечивое описание шагов для его повторения
   • Правильно: 1. Создать ботинок; 2. Создать шнурки; 3. Завязать шнурки; 4. Развязать шнурки; 5. Снять ботинок
   • Неправильно: 1. Завязать шнурки; 2. Развязать шнурки; 3. Снять ботинок
   • Совсем неправильно: 1. Создать ботинок; 2. Развязать шнурки; 3. Снять ботинок
6. Описание дефекта должно содержать результат выполнения шагов
7. Описание дефекта должно содержать ожидаемый результат выполнения шагов
   • Правильно: ботинок снимается с той же ноги, на которой был создан
   • Неправильно: ботинок снимается
   • Совсем неправильно: корректное поведение
8. Если дефект описывает нарушение требования, он должен содержать ссылку на это требование
9. Если дефект может быть повторен только на специфических данных, эти данные должны быть приложены к дефекту
10. Если дефект не повторяется или повторяется не каждый раз, это должно быть указано в его описании
11. Описание шагов для повторения может быть заменено на скринкаст, при этом остальные пункты должны соблюдаться
12. Описание результата выполнения шагов может быть заменено на скриншот, при этом остальные пункты должны соблюдаться