Bug report даже в случае необходимости доработки функциональности после тестирования? Это же не обязательно должны быть ошибки

Согласен, просто bug report я видел раза три в жизни. Два раза на учебе)
Обычно баги просто фиксятся, а если что "Доработать" - то уже CR

BR можно как и CR выставлять между командами

Согласен 😊. Конечно, это зависит от целей тестирования (в широком смысле). Если это проверка гипотезы на живых пользователях или же какая-нить опытная эксплуатации, то как раз может родиться и список CR.

наверно, это зависит от процесса. Иногда bug report это отчётный документ. На практике же часто формируется просто отчётом из баг-трекера

Да, на страничку в conf выводилось из jira )
Но я это не о высокой кухне)

Так, ок. Была написана техническая спецификация на доработку существующего ПО. Разработчик реализовал и передал обратно. Я вместе с пользователями тестирую получившийся результат и выясняю, что нужно добавить ещё пару функций, информационных полей, бизнес-правил и тп. CR все таки?

Мне кажется да, если это изначально не было прописано.

Как мне кажется, в данном случае CR это или нет, это будет зависеть от того, на каких условиях вы работаете с разработчиками - если это T&M, но это не CR.😊, если это фиксированный объём работ, то да - CR

У нас в штате свои разработчики) ну ок! Допустим остановились на CR. А что делать все таки с ошибками? Отдельно формировать BR?

А цель всего этого какая?

А при Time & Material разве не оговаривается что ребята делают?

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

Или ещё вариант, что в организации есть процесс управления изменениями (например, вот такой https://en.wikipedia.org/wiki/Change_management_(engineering))

конечно, но опять же из моей практики (на всякий случай - не претендую на эталон 😊), просто создавалась новая таска и не важно почему - накидывали в топку, а команда переваривала в одном из релизов

ну вот и мне было интересно как у других))) Спасибо

Цель следовать основным правилами работы. Это как написать ТЗ или ТС вместо того, чтобы отправь электронку программисту с некорректном описанием того что нужно)

В смысле у вас есть регламент, где это описано? или вы как раз его пишете, чтобы следовать. Просто для разработчика какая разница CR это или обычная таска?

Регламента нет) просто мне казалось, что это как с техническим заданием: есть задача - пишет подробно ТЗ, а не на словах объясняй программиста где и какую кнопку добавить. Если есть необходимость в доработке, то формируется какой-то документ типа ТЗ или дополнение к нему

Вставлю свои пять копеек.
Change Request включает в себя новые требования (чаще всего верхнего уровня).
Если новых требований нет, а есть информация о том, что кто-то не допилил старые - это bug report. Если новых требований нет, а есть хотелки - это feature request, и адресат его - не разработчик, а аналитик.

Компания существует более 20 лет и является одним из крупнейших игроков в своем сегменте. Почти с основания все работает на IBM notes. В штате всегда есть несколько программистов. Пол года назад я стал первым в компании, кто написал техническую спецификацию на доработку) и это моя первая практика написания таких документов. Написание ТЗ - процесс общепринятый. После тестирования у меня есть необходимости в доработке функциональности. Какой общепринятый думает формируется в таком случае? Вот мой вопрос)