@anatoliyivanov

Заведение бага или возвращение стори?

У нас в команде сегодня был спор, по теме которого особо ничего не гуглится. Суть в том, как определить флоу у тестирования User Story: найденные недоработки оформлять как баги и включать в текущий спринт или возвращать сторю на доработку с комментарием от QA какие кейсы не прошли тестирование.

В пользу за заведение багов:
  • Проще ориентироваться в истории разработки фичи - не нужно скроллить ленту комментариев в фиче, проще ссылаться на конкретные баги
  • Дефекты в фиче, отданной в тестирование - такие же баги как баги в поставке
  • Баги можно приоритезировать, баги с низким приоритетом можно вынести в бэклог и включить сторю в поставку

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


А как считаете вы? Поделитесь, пожалуйста, вашим опытом.
  • Вопрос задан
  • 159 просмотров
Пригласить эксперта
Ответы на вопрос 2
freiman
@freiman
Тестировщик 12+
Однозначно заводить баги отдельно от стори, но линковать их с исходной задачей для трекинга статуса. Как вариант - делать подзадачи, если система такое позволяет, если вам не нравится идея закрывать сторю с непофикшенными багами :)

Если просто возвращать стори с комментариями, то сложно оценить беглым взглядом, насколько же там все плохо.
Сложно трекать, что пофикшено, а что - нет.
Информация по багам может теряться.
В принципе не очень ясен статус такой стори.

В общем, на борде очень скоро наступит неразбериха, а стендапы могут быть в стиле
- Почему стори не двигается?
- Баг все еще чиним!
- Который?
- Ну который там в 7 и 13 и 15 комментах был описан..
- Эээ.. (открывает комменты, читает, пытается понять).. Про что там?
- Ну про [вот эту ерунду]
- А, ок!

А если баги отдельно:
- Почему эту стори не подвинули?
- Чиним баг WTF-512
- Так, "Не работает [вот эта ерунда]".. а, понятно!
Ответ написан
@RomanQA
по мне так каждая команда должна решать как ей удобнее по текущему проекту и соответственно текущей фазе проекта. Иногда удобнее заносить отдельные баги если вторая половина разработки большого эпика, иногда удобнее комментарии в стори (если мало багов и сторя простая), иногда удобнее просто в электронный документ (когда разработка только в начале-середине и много чего не работает)
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы