Много лет назад, в коридоре на одной конференции, мы с неким менеджером по тестированию сравнивали наши подходы. «Если мне не скажут, что должна делать программа, я не смогу ее протестировать, — хмурилась Франсина, моя собеседница. — Поэтому я им так и говорю — не начну тестировать, пока мне не дадут детальное ТЗ». Мои брови взлетели вверх.

В реестре требований добавлена возможность просмотра и быстрого добавления комментария.

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

На форме задачи добавлено редактируемое поле "Следующие задачи", которое позволяет быстро указать те задачи, которые должны быть выполнены после выполнения текущей задачи.

На карточках на досках пожеланий и задач реализовано отображение дат в сокращенном виде, например, 1 - Апр.

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

Один из методов, который становится всё популярнее в мире разработки ПО, - это непрерывная поставка. Однако до того, как реализовать непрерывную поставку, вам нужно сначала внедрить непрерывную интеграцию (НИ). Кто-то говорит, что НИ нужна лишь разработчикам, но они ошибаются.

Пользовательские истории - это, вероятно, наиболее широко распространенная техника в плане требований в мире Agile. Этот скромный шаблон «кто-что-почему» изначально был создан командой Connextra в Лондоне и быстро получил широкое распространение:

В трассировке требований (Реестр требований) добавлено отображение списка тестов, выполненных по сценариям, покрывающим требования, а также отображение коммитов исходного кода, реализующих требования.

В разделе "Контроль качества" добавлен отчет "Таблица ошибок", отображающий распределение ошибок по состояниям и приоритетам.

Для столбиковых диаграмм добавлено отображение таблицы данных.

Для требований, тестовой и технической документации добавлен атрибут "История состояний", отображающий кто, когда и в какие состояния переводил требование, сценарий или раздел документации. Например, можно использовать этот атрибур для контроля за тем, что с требованиями ознакомлены все ключевые участники проекта.

Исправлена ошибка при сохранении настроек отчета "Мои задачи" для всех участников проекта.