Перейти к содержимому

Программирование на C# для тестировщиков
онлайн, начало 19 июля
SQL: Инструменты тестировщика
онлайн, начало 18 июля
Командная строка: инструменты тестировщика
онлайн, начало 18 июля
Chrome DevTools: Инструменты тестировщика
онлайн, начало 18 июля
Фотография

Практика ревью заведенных багов


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 22

#1 MrS

MrS

    Новый участник

  • Members
  • Pip
  • 7 сообщений

Отправлено 29 Апрель 2019 - 08:43

Привет всем. 

Так как я работаю в большом проекте, в котором масса задач и количество багов соответствующее. У нас постоянно растет бэклог минорных и тривиальных задач, до которых программисты редко когда добираются. Некоторые баги сложно повторить при обычном использовании ПО, но их заводят, так как нашли)).

От сюда вопрос, кто-то использовал в работе практику ревью заведенных багов. Если да, то как это было организовано? С какими трудностями столкнулись при организации процесса?

Я вижу это примерно так. Выделяется раз в неделю день (или n-е количество часов), когда ответственный разгребает бэклог по задачам. Ответственный - это вероятно более опытный тестировщик или лид команды тестирования, который проверяет именно баги и + аналитик, который разгребает заведенные таски. 

 


  • 0

#2 Spock

Spock

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 441 сообщений
  • ФИО:Роман

Отправлено 29 Апрель 2019 - 09:35

 

 

У нас постоянно растет бэклог минорных и тривиальных задач, до которых программисты редко когда добираются.

у вас проблема не с ревью багов, баги заводят нормальные

 

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


  • 0

#3 MrS

MrS

    Новый участник

  • Members
  • Pip
  • 7 сообщений

Отправлено 29 Апрель 2019 - 09:40

 

 

 

У нас постоянно растет бэклог минорных и тривиальных задач, до которых программисты редко когда добираются.

у вас проблема не с ревью багов, баги заводят нормальные

 

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

 

Да, дело именно в том, что они никому не нужны. Но по мере расширения команды, сервисы распределяются и новые сотрудники открывают баги, которые были очень давно затрешены. Сидеть и изучать все закрытые баги времени не хватит, а постоянно отвлекаться или отвлекать кого-то, чтобы уточнить имеет ли баг место быть, тоже не самый лучший вариант. Поэтому и хочется что-то придумать с этим.


  • 0

#4 Spock

Spock

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 441 сообщений
  • ФИО:Роман

Отправлено 29 Апрель 2019 - 09:43

 

 

и новые сотрудники открывают баги, которые были очень давно затрешены

если баг известный и затрешенный - то и не надо его открывать

 

скажите этим сотрудникам что старые баги без разрешения лида пере-открывать запрещено


  • 0

#5 MrS

MrS

    Новый участник

  • Members
  • Pip
  • 7 сообщений

Отправлено 29 Апрель 2019 - 10:34

 

 

 

и новые сотрудники открывают баги, которые были очень давно затрешены

если баг известный и затрешенный - то и не надо его открывать

 

скажите этим сотрудникам что старые баги без разрешения лида пере-открывать запрещено

 

Не совсем верно выразился) под "переоткрывать" имел ввиду, открытие нового бага, который дублирует ранее затрешеный. 

То есть, приходит новый сотрудник, начинает знакомиться с сервисом. В процессе находит багу и фиксирует. Понятно, что сотрудник, может сделать выборку затрешеных задач по сервису, с которым работает и со всеми сидеть знакомиться, но задач может быть 1, а может и 1000 и даже если за сотрудником закреплен наставник на первом этапе, то и он может не помнить всех моментов + тест-кейса, повторяющего действие приводящее к ошибке, может и не быть и найти его в баг-трекере также не получится. Сотрудник всё сделал правильно, "пришел, увидел, победил", но итог, снова тривиальный баг в бэклоге. А при ревью баг трешится и всё ок. 

 


  • 0

#6 checo

checo

    Опытный участник

  • Members
  • PipPipPipPip
  • 366 сообщений
  • Город:Н.Новгород

Отправлено 29 Апрель 2019 - 11:12

 

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

Есть фильтр, не 100% точный, но позволяет избавиться от части лишней работы. Это групповой рабочий чат, куда каждый должен отправлять заголовки заведенных багов. И "старожилы" часто узнают, если такой баг уже был, или если им хорошо известно, что подобные ошибки никого не волнуют.

 

А вообще да, куратору продукта (product owner'у) имеет смысл регулярно просматривать, что заведено за прошедший цикл. Даже если это не скрам, какая-то цикличность в больших проектах обычно присутствует.

Если баги выбираются разработчиками не хаотично, а есть человек, который принимает решения о важности тех или иных фиксов, то этот человек уже занимается каким-никаким ревью, и может помечать неважные баги.


  • 0

#7 Vasiliy

Vasiliy

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 516 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 29 Апрель 2019 - 11:31

1. Новичкам полезно изучать историю. Если баги закрыты, то отфильтруйте их и пусть хоть по диагонали прочитают.
2. Что у вас за текучка, что столько новичков на проекте и нет времени на полноценное знакомство с проектом?
  • 0

#8 MrS

MrS

    Новый участник

  • Members
  • Pip
  • 7 сообщений

Отправлено 29 Апрель 2019 - 11:36

 

 

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

Есть фильтр, не 100% точный, но позволяет избавиться от части лишней работы. Это групповой рабочий чат, куда каждый должен отправлять заголовки заведенных багов. И "старожилы" часто узнают, если такой баг уже был, или если им хорошо известно, что подобные ошибки никого не волнуют.

 

А вообще да, куратору продукта (product owner'у) имеет смысл регулярно просматривать, что заведено за прошедший цикл. Даже если это не скрам, какая-то цикличность в больших проектах обычно присутствует.

Если баги выбираются разработчиками не хаотично, а есть человек, который принимает решения о важности тех или иных фиксов, то этот человек уже занимается каким-никаким ревью, и может помечать неважные баги.

 

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


  • 0

#9 MrS

MrS

    Новый участник

  • Members
  • Pip
  • 7 сообщений

Отправлено 29 Апрель 2019 - 11:39

1. Новичкам полезно изучать историю. Если баги закрыты, то отфильтруйте их и пусть хоть по диагонали прочитают.
2. Что у вас за текучка, что столько новичков на проекте и нет времени на полноценное знакомство с проектом?

На самом деле текучки особо нет, но сотрудники периодически прибавляются, меняются и т.д.


  • 0

#10 Vasiliy

Vasiliy

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 516 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 29 Апрель 2019 - 12:00

Раз текучки нет, то пусть бывалые отслеживают такие ошибки.
  • 0

#11 Spock

Spock

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 441 сообщений
  • ФИО:Роман

Отправлено 29 Апрель 2019 - 14:21

чат не нужен, так он будет просто дублировать баг-трекер

 

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

 

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


  • 0

#12 checo

checo

    Опытный участник

  • Members
  • PipPipPipPip
  • 366 сообщений
  • Город:Н.Новгород

Отправлено 29 Апрель 2019 - 14:56

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

Вы живете в идеальном мире с идеальными тестировщиками, которые умеют искать, и к тому же хорошо знают язык, на котором заводятся баги.

В реальности новички будут описывать баг совсем другими словами, чем опытные, и не будут понимать, что там вообще написано в трекере.


  • 0

#13 SALar

SALar

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 215 сообщений
  • Город:Москва


Отправлено 29 Апрель 2019 - 16:03

Есть "два вида списков задач"

 

Читайте. Надеюсь в этой статье дан ответ на ваш вопрос.

 

И учите теорию. Теорию вариаций и теорию систем.


  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней

 


#14 Vasiliy

Vasiliy

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 516 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 29 Апрель 2019 - 21:56

Сергей, это не то. Имхо. Проблема топикстартера не в том, что они балансируют цепочку, а в том, что они не могут новичкам рассказать какие баги уже есть и не дублировать их.
  • 0

#15 MissLeman

MissLeman

    Постоянный участник

  • Members
  • PipPipPip
  • 152 сообщений


Отправлено 03 Май 2019 - 08:44

А точно проблема ТС именно в большом количестве дубликатов? Если да, то новичка как раз очень полезно посадить разгребать баклог - и систему подучит, и заодно проверит, может быть, какие-то баги уже пофиксились indirectly и их можно закрыть. И примерно выучит, что там уже есть.

 

У нас пробовали внедрить практику: программист сделал таск по проекту - возьми починить один баг из баклога. Какое-то время работало.

Но вообще мы где-то раз в полгода просто берем и закрываем как Won't fix миноры, которые за эти полгода так и не пофиксили. Понятно, что до них руки вообще никогда не дойдут.

Я их иногда выкапываю и подкидываю программистам, если они что-то разрабатывают "рядышком": посмотри, мол, может заодно вот это поправишь.


  • 0

#16 Little_CJIOH

Little_CJIOH

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 394 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 04 Май 2019 - 14:25

А вы не пробовали сделать трассировку от багов до тесткейсов их выявивших и наоборот. Очень удобно, особенно если отображается статус дефекта и резолюшн.
  • 0

#17 SALar

SALar

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 215 сообщений
  • Город:Москва


Отправлено 04 Май 2019 - 16:16

А вы не пробовали сделать трассировку от багов до тесткейсов их выявивших и наоборот. Очень удобно, особенно если отображается статус дефекта и резолюшн.

Угу. А еще трассировку на требования и код. 

Это ж целый второй уровень CMMI ! Где в РФ такое видано?!

 

Но совет хороший.

 

PS. Практика отчитки лидом всех заведенных багов не просто хорошая, она по хорошему обязательная. 

 

PSS. А чтобы не плодить дубликаты нужно научить сотрудников описывать баги. Работа муторная. Два месяца работы наставника  примерно с каждым тестировщиком. Каждый день вечером отчитываем, что завели подопечные и вместе разбираем ошибки в описании.


  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней

 


#18 Spock

Spock

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 441 сообщений
  • ФИО:Роман

Отправлено 04 Май 2019 - 19:32

сказать что нормальное заведение багов (чтобы показатель "закрыт как дубликат" был невысоким) является необходимым условием для повышения зп/позиции

 

и проблемы больше нет


  • 1

#19 Little_CJIOH

Little_CJIOH

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 394 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 06 Май 2019 - 07:38

сказать что нормальное заведение багов (чтобы показатель "закрыт как дубликат" был невысоким) является необходимым условием для повышения зп/позиции

 

и проблемы больше нет

"Я выкрутился, теперь ваша очередь"


  • 0

#20 MrS

MrS

    Новый участник

  • Members
  • Pip
  • 7 сообщений

Отправлено 06 Май 2019 - 12:48

Всем спасибо за ответы. Приму к сведению информацию и поищу ещё доп. материалы.


  • 0


Инструменты тестировщика: Командная строка
онлайн
Практикум по тест-дизайну 2.0
онлайн
Программирование на Phyton для тестировщиков
онлайн
Тестирование производительности (JMeter)
онлайн



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале