Сообщений в теме: 7

[Pandora_]

Продукт на стадии разработки + тестирование. Первая интеграция с потенциальными пользователями запланированна на сентябрь. Руководство выдвинуло требования по мониторингу качества продукта, отслеживания багов и естественно ежемесячной отчетности ему же.

 

На данный момент используем Jira. Есть только Story и если тестер находит баг, то уведомление идет в комментарии, делается Reopen и Story отправляется обратно разработчику. 

 

Вопрос: 

 

1. можно ли в Story как-то по комментам или может другим показателям посмотреть, сколько раз Story туда-сюда отправлялось?

2. ну или посоветуйте, как лучше отслеживать баги. Как, вообще, лучше всего мониторить качество?

 

[ChitaevK]

В чем проблема заводить баги и их считать?)

[Pandora_]

В чем проблема заводить баги и их считать?)

Вы свои посчитали? :) Каков итог?

[Сергей]

Странный подход. Баги заводить не пробовали?

[ChitaevK]

 

В чем проблема заводить баги и их считать?)

Вы свои посчитали? :) Каков итог?

 

Опять же, в чем проблема? Вы же их не в тетрадке заводите, что бы руками считать

[Little_CJIOH]

Риторический вопрос позволю себе.

В чем проблема, когда руководство за месяц до "весны", которая "покажет кто где срал", просит предоставлять ему отчет о "качестве".

У человека неспособного прогуглить как в джире считать сколько раз таска была в заданном статусе. (ответ, с помощию одного из N плагинов, или выдергивать через API и считать самому.)

 

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

Категории качества ПО регламентированы ГОСТ 25010-2015

[Vasiliy]

Есть стойкое ощущение, что отслеживать баги и мониторить качество это две разные и не связанные между собой вещи.

У вас хватит силы воли выяснить зачем руководству мониторить баги?

[tjupka]

Jira - шикарный инструмент для визуализации работы команды. Странно, что вы зациклились лишь на возвратах головной задачи - Story.

Можно же определить набор критериев для приёмочного тестирования и помечать их оговоренным образом: зелёная галка - сделано и работает после теста, красный минус - не сделано, знак вопроса - требуется доработка. При этом головную задачу держать в статусе ТЕСТИРОВАНИЕ до полной реализации, а все баги и доработки оформлять линкованными блокерами к этой головной Story. В этом случае у вас не то что месячный, а ежедневный отчёт по состоянию задачи получится с количеством открытых проблем.

Если мой вариант вам не подходит, то почитайте инструкции к Jira - там много хороших решений уже есть для мониторинга процесса разработки ПО.