Тут вот какие возможны проблемы:

1. В студии не прописана строка подключения к БД, где будут храниться результаты нагрузочного тестирования ( Tests -> Manage Tests Controllers -> Load tests results store )
2. База для результатов нагрузочного тестирования не создана.

Описанные отчеты довольно специфичные, но вся информация для их построения имеется в системе http://devprom.ru и система эта а) бесплатная и б) повторяет в большей степени FogBugz.
Подробнее о возможностях можно почитать здесь

Роман, привет!

Могу поделиться возможностями инструмента, который не входит в исходный список

• Requirements storage (хранение требований)
• Test Plan storage (хранение тест плана)
• Traceability test cases and bug reports (трассировка тест кейсов с тест репортами)
• Traceability test cases and test plan (трассировка тест кейсов с планом)
• Traceability test cases and requirements (трассировка тест кейсов с требованиями)
• Traceability test plan and requirements (трассировка тест плана с требованиями)
• Tracking changes in test cases, test plan or requirements (трекинг изменений в тест кейсах, в тест плане или требованиях)
• Ability to create versions for test cases, test plan and requirements (возможность создать версионность для тест кейсов, тест плана и требовний)
• Ability to create platforms (возможность организации процесса под несколько платформ, кросс-платформеность)
• Ability to create assemblies (возможность отследить сборки)
• Estimation of testing coverage (оценка покрытия тестирования)
• Reports storage (хранение репортов)
• Limitation of storing information (ограничение на объем хранимой информации)
• Transferring test cases (импорт\експорт тест кейсов)
• Integration with bug tracking systems (интеграция с разл баг трекинг системами)
• Price (цена)

1. Встроенная поддержка автоматизации управления требованиями
2. Формирование тест планов из разделов тестовой документации
3. Все перечисленные виды трассируемости (на баги, на планы, на требования)
4. Аудит изменений всех объектов в системе, обсуждение по всем объектам системы
5. Поддержка различных платформ (через описание и использование перечня окружений), поддержка работы со сборками
6. Покрытие тестирования можно контролировать по списку фичей (эпиков), баклогу продукта, релиза или итерации.
7. Хранятся репорты выполненные вручную или сформированные автоматизированной тулой
8. Встроенный баг-трекер.
9. Бесплатно, без ограничений.

В текущей версии не поддерживается: версионность тест-кейсов, планов и требований. Но хорошая новость в том, что это фича следующей версии.
Импорт/экспорт можно выполнить через API, но можно и предложить разработчикам доработку.

Вы можете подробнее познакомиться с функциональными возможностями на сайте инструмента: http://devprom.ru
Там же есть описание вариантов решения типовых задач по организации тестирования или управления требованиями.

Критерием протестированности я бы называл условия, когда все тестовые сценарии (или критерии успешности) для данной фичи выполнены на требуемых конфигурациях и окружениях.
В Вашем случае скорее идет речь об уровне качества реализованной фичи: все ли сделали, шустро ли бегает, удобно ли использовать и т.п.

Поскольку сами по себе требования к качеству выражаются специфическим образом для каждого проекта или продукта, то вряд ли кто-то сообщит внятный их список и язык, на котором их формулировать.
Для начала исследования этой темы я бы предложил Вам начать с чего-то простого и почитать вот эту простенькую методологию тестирования:
http://code.google.c...ki/AccExplained

Она совсем прям в стиле Agile, как Вы и хотите.

В анонсе хорошо известного инструмента управления процессом разработки и тестированием, в частности, прозвучал термин "TestBoard".
Интересно, кто-то что-то подобное на практике использовал? Если да, то поделитесь опытом - как, зачем, почему?

Я бы донес проблему до лица, ответственного за принятие соответствующих решений: функциональное тестирование покрывает <50% требований, в этом я вижу серьезный риск для качества продукта.

Анализ причины: ресурсов для тестирования явно не достаточно (+ обоснование, что действительно недостаточно).

Предложение: снизить количество актов смоук-тестирования с X до 1, путем введения правила: тестировщики не принимают в работу релиз, который не проходит хотя бы один тест из набора смоук-тестов.

Уже проходили это - работает, а если не сработает, значит то качество, которого Вы добиваетесь, никому не нужно. А вот с этим что делать - решать Вам лично :)

Здравствуйте.
Встал вопрос о том, чтобы связать JIRA с какой-нибудь программой для управления тестированием. Основная задача, обмен дефектами между жирой и программой. Например: чтобы в баге можно было указать ссылку на тест-кейс, в котором он был найден. Или в тест-кейсе можно было бы просмотреть список найденых багов. Конечно все это можно сделать простыми ссылками, но хотелось бы видеть более менее адекватное решение. Посоветуйте, пожалуйста.

Скорее всего только если отказаться от JIRA, поскольку это просто трекер - таковым является и, видимо, останется. Вы же намекаете на часть ALM - то есть интеграцию как минимум двух дисциплин - разработки/поддержки и тестирования. Из платных продуктов, реализующих такие связки мне известны: VersionOne, Polarion, TargetProcess, из бесплатных - DEVPROM.

Анна, привет!

Скорее всего, та задача, о которой ты говоришь, называется impact analysis (анализ влияния изменений на требования, неважно в какой форме они выражены). Подобный анализ можно проводить только понимая как связаны исходные требования (use cases) и порождаемые требования (user stories). Такие связи обычно описывают матрицей трассировки, на которой видны связи между use cases и всеми поражденными требованиями или артефактами, например, тестовыми сценариями.

Что касается инструмента, то их довольно много и они платные: VersionOne, Axsoft OneTime, Polarion. Я, например, использую бесплатный - devprom, в котором есть возможность связывать требования между собой, связывать требования с тестовыми сценариями, отображать матрицу трассировки, а также автоматически отмечать неактуальные разделы.

Описанный тобой сценарий мог бы выглядеть так: при разработке use cases и user stories они должны быть связаны, затем, когда меняется use case, то автоматически становятся неактуальными связи с user stories; проходим по неактуальным связям, правим текст и помечаем связь как актуальную.

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

100% рецепта вы вряд ли найдете, поскольку отчетность - дело сугубо индивидуальное и зависит от типов проектов, команд, методологий и много чего другого, поэтому как и всем ее придется изобрести. Вопрос того, как в будущем автоматизировать построение нужных отчетов, предлагаю отложить на будущее, когда станет понятно, что же нужно автоматизировать.

То что у вас приведено на примере чаще всего называют health (здоровье) проекта, ну а в вашем случае - слишком все в куче, там и состояние продукта/проекта, и планируемые активности, и отчет по выполненным тестировщиками работам.

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

Далее, нужно эту систему показать руководству, договориться о форме отчетности, понять что им важно видеть. Ну а все остальное - дело техники.