Project

General

Profile

Actions
History

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

  • Используем 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.
  • В конце итерации демонстрируется реализованная функциональность.
  • В конце итерации проводится ретроспектива.
Этап Статус в начале Статус в процессе Исполнители Результат Статус в конце
Прием заявки User Более или менее подробное описание новой функциональности в задаче типа Feature Feature:New
Оценка Feature:New Feature:Open, assigned Product Owner Одобрение запроса, возможно с его обощением, детализацией или переформулировкой в задаче типа UserStory или отказ, желательно мотивированный UserStory:New или Feature:Rejected
Определение требований UserStory:New UserStory:Open, assigned Analyst + Product Owner Детально сформулированные требования к новой функциональности на Wiki. Проект GUI и т.п. UserStory:Open
Верификация требований UserStory:Open UserStory:Open, assigned Tester Обратная связь от тестера о наборе требований. UserStory:Open
Запуск в работу UserStory:Open UserStory:Open Analyst -> Team Демонстрация проекта функциональности. Обратная связь от команды. Оценка затрат на реализацию + разбиение на подзадачи для точности оценки. UserStory:Open, store points
Реализация Task(D):New Task(D):Open, assigned Developer Разбиение на подзадачи и реализация. Юнит-тесты и код в svn. Юнит-тесты проходят. Task(D):Resolved, time spent. UserStory:Resolved
Разработка тестов Task(T):New Task(T):Open, assigned Tester Разработка тестов. Тесты (код, описание и т.п.) в svn Task(T):Open, time spent
Внутренний релиз UserStory:Resolved UserStory:Resolved Release Manager Внутренний релиз, опубликованный на daily update site UserStory:Resolved, Published in Build
Прогон тестов UserStory:Resolved, Published in Build, Task(T):Open UserStory:Resolved, Published in Build, Task(T):Open Tester Прогон тестов UserStory:Verified, Task(T):Closed, time spent
Внешний релиз UserStory:Verified UserStory:Verified Analyst+Team -> ProductOwner Демонстрация новой функциональности. Внешний релиз, опубликован на stable update site UserStory:Closed, Task(D):Closed

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

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

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

  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. Описание результата выполнения шагов может быть заменено на скриншот, при этом остальные пункты должны соблюдаться

Updated by Андрей Третьяков over 12 years ago · 27 revisions