E
Size: a a a
2020 November 25
A
Не могу промолчать на такую дискуссию))) Всё от целей же зависит и от того, кто и как потом пользуется информацией из Джиры.
да)
A
А вообще часто проблема у QA в том что реальный начальник QA не QA)))) АСкрам мастер, менеджер, девелопер, PM
И у QA очень ограниченные ручки влияния
И у QA очень ограниченные ручки влияния
A
Сабтаски, например, удобнее и виднее разработчику, который допиливает фичу. Все списком в одном месте, можно делать по порядку.
у нас баги линкованные также видны списком)
E
А вообще часто проблема у QA в том что реальный начальник QA не QA)))) АСкрам мастер, менеджер, девелопер, PM
И у QA очень ограниченные ручки влияния
И у QA очень ограниченные ручки влияния
Часто проблема у менеджера, что все подчиненные - не менеджеры и не разговаривают с ним на менеджерском)))
АН
а вы отличали сабтаски от багов в таком случае?
Ну дак у них тип то разный. У нас тестирование фичи в подзадаче = sub-test, баги = sub-bug, есть "подзадача", есть Sub-Requirement. Типы разные поэтому ничего не смешивается)
A
Если список багов потом в какие-нибудь Релиз ноты попадает, то конечно, логичнее внутрирелизные баги сабтасками делать. А если потом кто-то внутреннюю статистику собирает, то надо смотреть что за статистика и как с этим жить.
Ага. Мы в релиз ноутсах пишем баги. Разумеется там не попадают баги разработки, только баги найденные после релиза. Для них у нас есть кейворд по которому собираются релиз ноутсы
E
у нас баги линкованные также видны списком)
Да, есть такое. Только там может быть помесь всего и надо еще уметь правильно линковать (блокеры всякие и т.п.)
EX
Сабтаски типа саб-баг это очень удобно т.к. такие сабтаски сразу ведут на задачу в которой были обнаружены. Раньше когда всё было в виде отдельных репортов, которые были свалены в общую кучу, было менее удобно. Может скрам мастер всё-таки это имел ввиду (хочется на это надеяться)
Ну у меня тоже баги не отдельно живут, а связаны с таской. Однако если это баг с прода, через месяц после релиза, то это баг другого вида, он живёт отдельно
E
Ага. Мы в релиз ноутсах пишем баги. Разумеется там не попадают баги разработки, только баги найденные после релиза. Для них у нас есть кейворд по которому собираются релиз ноутсы
Вот это вы заморочились... Такого ни разу не видела.
EX
мы линкуем в Jira баги к таске, и их тоже сразу видно
Но мне кажется что можно баг не заводить, если дефект был найден в процессе разработки и будет починен прямо тут.
Если он будет починен не сейчас, а завтра - то тогда обязательно баг. Хотя бы для того чтобы осталась информация о нём и не было бас фактора - чтобы починить и заверифить могли другие девелопер и куа.
Но мне кажется что можно баг не заводить, если дефект был найден в процессе разработки и будет починен прямо тут.
Если он будет починен не сейчас, а завтра - то тогда обязательно баг. Хотя бы для того чтобы осталась информация о нём и не было бас фактора - чтобы починить и заверифить могли другие девелопер и куа.
В таком случае сабтаск, или "на словах"?
A
В таком случае сабтаск, или "на словах"?
в чате. Так не протеряется
АН
Ну у меня тоже баги не отдельно живут, а связаны с таской. Однако если это баг с прода, через месяц после релиза, то это баг другого вида, он живёт отдельно
А если баг с прода через месяц вы его не линкуете к задаче?
A
А если баг с прода через месяц вы его не линкуете к задаче?
нет.
A
В таком случае сабтаск, или "на словах"?
ну или в комменте, да
АН
нет.
А вы с Женей как-то связаны или работаете вместе?😅
A
А вы с Женей как-то связаны или работаете вместе?😅
Кроме редкого совместного обжорства пироженным и электросамокатами почти никак)