Spec Box TMS

Проект Spec Box TMS - система управления функциональными требованиями (рабочее называние УФТы!)

Задача проекта обеспечить инструментарием процессы разработки программного обеспечения:

• Проектирование требований к программному обеспечению
• Рецензирование требований
• Постановка задач на разработку ПО
• Подтверждение функциональности программного обеспечения
• Хранение истории тестовых запусков

Концепция системы

Цель проекта: объединить проектирование требований к программному обеспечению с задачей на разработку и с планами тестирования.

Главная идей проекта заключается в переходе к описанию функциональных требований в виде простых утверждений, которые легко поддаются автоматизации тестирования или ручному тестированию.

Такие спецификации должны храниться вместе с исходным кодом приложения в виде yaml файлов, подробнее о которых можно прочитать в документации �� репозиторию SpecBoxTMS.Sync.

Размещение спецификаций вместе с исходным кодом позволяет:

• Согласовать изменения кода и спецификаций
• Гарантировать сохранность спецификаций
• Хранить историю изменений спецификаций за счет системы контроля версий
• Производить сопоставлений имен утверждений с отчетом об автоматизированных тестах

Проект состоит из трех частей:

• Консольная утилита SpecBoxTMS.Sync - выполняет валидацию содержимого yaml файлов спецификаций, сопоставление с отчетом об автотестах и синхронизацию с сервером требований.
• Сервер требований SpecBoxTMS.Api - обеспечивает хранение требований и истории тестовых запусков.
• Пользовательский интерфейс SpecBoxTMS.Web - пользовательский интерфейс для взаимодействия с системой позволяет просматривать требования и объемы покрытия автоматизированными тестами, а так же выполнять тестовые запуски.
• Документация и Roadmap проекта SpecBoxTMS.Docs

Данный проект является ответвлением от оригинального SpecBox

Описание процесса

1. Разработка требований ведется в отдельной ветке репози��ория с синхронизацией с сервером
2. Рецензирование требований выполняется в систему путем тестового запуска, объектом тестирования при котором является не ПО, а требования
3. На основе рецензирования выполняется корректировка требований
4. Требование может быть скопировано, отформатированное в виде Markdown и добавлено в задачу на разработку в систему управления проектом
5. Требование копируется в рабочую ветку и выполняется разработка. В процессе разработки и написания автоматизированных тестов требование может быть откорректировано.
6. На CI выполняется синхронизация результатов тестов и спецификаций, в систему загружается alfa версия требований.
7. Выполняется ручной запуск тестов, собираются замечания к ПО или к требованиям.
8. Требования вновь корректируются в рабочей ветке, если это необходимо.
9. После стабилизации alfa версии - версия готова к релизу с актуальным набором требований. При необходимости выполняется синхронизация требований релиза с основной веткой требований.

Особенности процесса

В отличии от классических систем управления требованиями и систем управления тестированием в Spec Box TMS нет привычного редактора требований. По мнению создателей, спецификации должны разрабатываться как код, версионироваться как код и храниться вместе с кодом.

Спецификации хранятся в виде yaml файлов. Подробнее в проекте SpecBoxTMS.Sync

feature: Страница авторизации пользователя   # понятное для человека название фичи
code: authorization-page                     # уникальный (в пределах проекта) код фичи
description: |                               # описание фичи (опционально)
  Страница авторизации пользователя расположена по маршруту https://example.com/auth

# список функциональных требований (утверждений о продукте), объединенных в группы
specs-unit:
  Форма авторизации:
    - assert: Должен отображаться заголовок `Авторизация`
    - assert: Должен отображаться логотип
    - assert: Должно отображаться поле `Логин`
    - assert: Должно отображаться поле `Пароль`

  Поле Логин:
    - assert: Отображается плэйсхолдер `Введите логин`
    - assert: Если введен логин длине 20 символов, должно отображаться сообщение "Максимальная длина 20 символов"

  # И так далее

Возможно описание в виде тест кейсов:

feature: Авторизация пользователя с корректными учетными данными
code: authorization-success
description: |
  **Предварительные условия:** Пользователь должен быть зарегистрирован в системе с известными логином и паролем.

specs-unit:
  Шаги воспроизведения:
    - assert: Открыть страницу авторизации веб-приложения.
      description: https://example.com/auth
    - assert: Ввести корректный логин в поле ввода логина.
    - assert: Ввести корректный пароль в поле ввода пароля.
    - assert: Нажать кнопку "Войти" или аналогичную, инициирующую процесс авторизации.

  Ожидаемый результат:
    - assert: Пользователь успешно авторизован и перенаправлен на главную страницу или страницу профиля.

Roadmap

1. Авторизация пользователей и настройки доступа к проектам OAuth
2. Добавление функций описания и сбора метрик при тестовых запусках
3. Добавление поддержки отчетов об автотестах в формате JUnit
4. API для автоматизированного сбора метрик
5. Инструменты сравнения локальных спецификаций с сервером
6. Установочный пакет
7. Визуализация аналитики и метрик
8. Прогнозирование времени тестирования
9. Сравнение версий для вычисления инкремента
10. Создание тестовых запусков на основе инкремента
11. Внешние ссылки, ссылки на другие проекты, отображение внешних зависимостей