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

Программирование на Python для тестировщиков
онлайн, начало 18 октября
Логи как инструмент тестировщика
онлайн, начало 21 октября
Тестирование REST API
онлайн, начало 21 октября
Организация автоматизированного тестирования
онлайн, начало 18 октября
Фотография

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


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

#1 MrS

MrS

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

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

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

Привет всем. 

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

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

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

 


  • 0

#2 Spock

Spock

    Гуру

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

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

 

 

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

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

 

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


  • 0

#3 MrS

MrS

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

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

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

 

 

 

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

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

 

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

 

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


  • 0

#4 Spock

Spock

    Гуру

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

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

 

 

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

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

 

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


  • 0

#5 MrS

MrS

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

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

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

 

 

 

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

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

 

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

 

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

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

 


  • 0

#6 checo

checo

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

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

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

 

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

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

 

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

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


  • 0

#7 Vasiliy

Vasiliy

    Гуру

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

Отправлено 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 608 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

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

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

#11 Spock

Spock

    Гуру

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

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

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

 

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

 

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


  • 0

#12 checo

checo

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

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

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

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

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

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


  • 0

#13 SALar

SALar

    Гуру

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


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

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

 

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

 

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


  • 0

-- 

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

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

 


#14 Vasiliy

Vasiliy

    Гуру

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

Отправлено 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 420 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


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

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

#17 SALar

SALar

    Гуру

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


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

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

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

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

 

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

 

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

 

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


  • 0

-- 

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

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

 


#18 Spock

Spock

    Гуру

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

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

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

 

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


  • 1

#19 Little_CJIOH

Little_CJIOH

    Гуру

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


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

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

 

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

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


  • 0

#20 MrS

MrS

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

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

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

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


  • 0


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



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

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

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